springboot青岛旅游APP20778-计算机毕业设计、课程设计

第一章 绪论

1.1 选题背景和意义

　　传统的旅游信息服务模式同移动互联网时代游客的个性化需求存在着明显的脱节。早期的旅游网站都是以编辑推荐的形式发布信息，游客只能被动地接受统一的信息。粗放式的服务不能满足用户的差异化需求，在筛选信息的时候花费大量的时间。近年来青岛旅游业持续发展，2019年接待游客人数超过1.1亿人次。大量游客涌入和本地信息服务体系不健全造成矛盾。现有的通用旅游平台内容繁杂，没有对青岛本地进行深度整合。个性化的推荐技术能缓解信息过载状况，经由对用户的行动数据开展分析之后，能够实现精准推送[1]。移动应用成了旅游服务的主要载体，智能手机的普及使游客获取信息的方式发生了改变[2]。开发出一款以青岛旅游为对象的个性化推荐APP，可以整合本地旅游资源，降低游客的信息筛选成本。本系统可以提高旅游体验，促进青岛旅游行业的数字化转型。

　　研究的意义有多个方面。就效率提高而言，个性化推荐机制会削减用户的浏览无用信息所花的时间。系统按照历史行为自动筛选出匹配的信息，游客不需要主动去查找就可以得到自己想要的内容。就用户体验来说，移动端应用具有随时随地的访问功能，预约流程线上化可以省去现场排队等候的过程。就数据价值而言，系统所累积的用户行为数据可以体现旅游偏好的改变趋向，给运营决策给予支撑。从行业示范角度来讲，该项目证明了个性化推荐技术对于区域旅游场景的可行性，可以给其他的旅游城市给予参照模版。从社会效益角度来讲，该系统促使青岛旅游资源实现数字化整合，有益于改善城市旅游服务形象。

1.2 国内外研究现状

　　国内旅游信息服务平台发展有多个阶段。早期的门户时代是以携程为代表，用编辑生产的模式发布航班、酒店信息，用户互动性差。2010年左右蚂蜂窝等垂直社区出现，用户生成内容模式激活了强互动论坛，游记攻略成为主要的资源。移动互联网普及之后，美团、抖音等平台进入旅游领域，以位置服务和短视频种草为特点的信息分发方式被改变。数据驱动系统在这些平台上逐渐形成，个性化推荐成了标配[3]。飞猪旅行融合阿里生态资源，创建起场景化社交和交易闭环[4]。2020年马蜂窝对大数据平台进行升级，可以对游记内容以及用户的兴趣进行智能匹配[5]。同程旅行开发出依靠协同过滤的景点推荐模块，提高了转化率[6]。驴妈妈主打周边游场景，用用户画像精准营销[7]。平台发展路径说明，由人工编审到算法推荐的趋势不能改变。

　　国外旅游服务平台也由原来的社交属性向数据驱动转变。TripAdvisor早期依靠用户评论来营造社区氛围，论坛互动属于主要的功能模块[8]。随着用户数量的增加，平台开始使用推荐算法，根据用户的浏览历史来推送相关内容。Yelp整合本地商家信息，依靠用户评论、评分等数据来支撑质量排序机制。Airbnb由住宿预订拓展到体验活动，个性化推荐成了联系房东和旅客的重要纽带[9]。Google Travel依靠搜索数据的优势，凭借用户的意图识别来达到精准展示的目的[10]。Expedia集团旗下的品牌矩阵涉及众多细分市场，交叉推荐提高了客单价[11]。Booking.com的推荐引擎对用户的实时行为进行分析，动态调整展示顺序[12]。这些平台的共同特征是数据驱动决策取代了人工运营。

1.3 研究内容

　　本文以基于个性化推荐的青岛旅游APP为研究对象，进行设计和实现。从需求分析开始，确定游客和管理员两个主要用户的需求。系统架构为前后端分离模式，移动端面向游客提供景点浏览、美食查询、论坛交流、门票预约等功能，Web端面向管理员提供数据管理、订单处理、内容审核等操作。使用MySQL的关系型数据库来存储数据，设计出用户表、景点表、美食表、预约表、评论表等主要的表结构。个性化推荐模块根据用户的日志行为来使用协同过滤算法产生候选集，再用热度补偿的方式得到最终的结果。系统开发完毕之后再做功能测试和兼容性测试，保证各个模块的运行稳定。本次研究主要针对推荐算法在移动端旅游场景的应用展开研究，没有对支付网关进行深度对接以及LBS实时导航功能的实现。最终交付可以运行的APP原型、管理后台和配套的设计文档。

第二章 相关技术介绍

2.1 Spring Boot框架

　　Spring Boot框架基于Spring生态构建，简化了传统Spring应用的配置流程。该框架用自动配置来减少XML配置文件的编写工作。开发者在项目中加入某种场景的Starter依赖之后，框架就会自动去加载相关的配置类[13]。Tomcat、Jetty等Servlet容器被嵌入到框架里，应用打包成独立的JAR文件之后可以直接运行。在请求响应机制中，框架对HTTP请求从控制器到服务的全部调用过程进行处理。Spring Boot的Actuator模块可以对应用进行监控，暴露健康检查、信息收集等端点。框架内部有一个条件化的配置系统，根据类路径中是否存在某个依赖来决定是否创建某个Bean。嵌入式容器的出现使得微服务架构中各个服务可以独立运行。配置文件支持多环境隔离，application.properties或application.yml中定义的属性通过占位符注入到组件中。该框架成了企业级应用开发的基础设施。

2.2 Vue.js前端框架

　　Vue.js是一个渐进式JavaScript框架，专注于视图层构建。该框架使用声明式的渲染方式，用模板语法把数据映射到DOM元素上。虚拟DOM技术减少了对真实DOM的直接操作所造成的性能损耗，当数据发生改变的时候，框架会自动计算出最小的更新路径。组件化机制把界面拆分成独立的、可以被复用的模块，每一个模块都有自己的模板、逻辑和样式。响应式数据系统依赖Object.defineProperty或Proxy拦截属性读写操作，数据变更触发视图重新渲染。框架内部创建一个依赖收集器，用来记录计算属性与侦听器的依赖关系[14]。路由管理由Vue Router插件实现，可以使用嵌套路由和路由守卫。状态管理使用Vuex或者Pinia，把所有的跨组件共享数据都集中起来。该框架可以给移动端管理后台界面的开发提供有效的交互支持。

2.3 MySQL关系型数据库

　　MySQL是开源的关系型数据库管理系统，使用结构化查询语言对数据进行操作。数据库存储引擎架构采用插件化的设计思想，InnoDB引擎具备事务处理和外键约束的功能。数据用表格形式组织，表之间用主键和外键建立关联关系。B+树索引结构加快数据检索操作，索引创建之后，查询优化器挑选出最佳的访问途径。ACID事务模型可以保证并发下数据的一致性和隔离性[15]。该数据库可以创建视图、存储过程、触发器等数据库对象。查询执行分为解析、优化、执行三个阶段，优化器根据统计信息来选择执行计划。日志系统保存数据变更的操作，故障恢复的时候用重做日志来恢复未持久化的修改。在Web应用开发当中，MySQL担当起业务数据的持久化保存任务。

2.4 MyBatis持久层框架

　　MyBatis是SQL映射框架，把Java接口方法和数据库操作语句关联起来。该框架用XML文件或者注解来配置SQL语句，开发者可以对SQL语句进行完全的控制。参数映射机制把Java对象的属性传入到SQL占位符中，结果集映射会自动填充返回的对象字段。动态SQL功能可以进行条件判断和循环拼接，代替手工拼接字符串的操作。框架核心组件包括SqlSessionFactory、SqlSession、Executor等[16]。SqlSessionFactory根据配置文件创建SqlSession实例，每个会话代表一次数据库连接。执行器组件主要完成SQL语句的执行以及缓存的管理，一级缓存默认开启可以减少重复查询的开销。二级缓存支持跨会话共享功能，必须手动启用。该框架把系统数据访问层当作业务逻辑和数据库之间的中间层。

第三章 系统需求分析

3.1 可行性分析

3.1.1 技术可行性

　　系统采用前后端分离架构，后端使用Spring Boot框架来提供服务接口，移动端用Android技术开发原生应用。开发环境为IntelliJ IDEA，是一个成熟的、稳定的Maven项目管理工具，可以很好地进行版本控制。Spring Boot自动配置机制减少组件整合的复杂程度，MyBatis是持久层框架，简化了数据库操作。MySQL数据库支持Windows和Linux操作系统，单表千万级数据量下依然可以保持良好的性能。移动端开发采用的是Android Studio自带的模拟器进行调试，Vue.js管理后台界面开发效率高。

3.1.2 经济可行性

　　开发所需软件工具均为免费或社区版本，IntelliJ IDEA社区版满足基本开发需求。硬件投入方面，一台8GB内存个人电脑可同时运行后端服务、数据库、前端项目。系统部署阶段可选用云服务商提供的轻量应用服务器，月均成本控制在百元以内。开发周期预计三个月，人力成本主要为个人时间投入。系统上线后运行维护工作量较小，数据备份与安全更新可通过脚本自动化完成。整体投入处于合理范围。

3.1.3 操作可行性

　　移动端界面遵循Android Material Design设计规范，底部导航栏布局符合用户使用习惯。游客首次进入应用无需注册即可浏览景点美食信息，降低使用门槛。论坛发帖与评论操作流程简洁，输入框与提交按钮位置明确。管理后台采用表格形式展示数据，筛选与排序功能降低信息查找难度。各角色操作路径经过简化设计，用户无需阅读帮助文档即可完成核心任务。系统整体交互复杂度控制在合理区间内。

3.2 功能需求分析

　　游客进入移动端后可以浏览景点信息和美食内容。景点信息模块显示景点名称、位置、票价、评分、图片等旅游资讯。美食信息模块显示美食名称、类型、价格、口味、店铺地址等餐饮内容。交流论坛可以让用户发表帖子、回复评论、点赞。个人中心模块有资料修改、预约记录、收藏管理、浏览历史这些操作入口。客服咨询功能是通过表单提交问题给管理员回复。游客在门票预约完成后，点击下一步，直接进入支付页面支付。餐饮预约功能与前面预订系统类似，用户选定好所想的美食和预订的数量之后就可以进行预订。

　　管理员登录到Web后台之后可以管理系统所有的资源。系统用户模块实现账号增删改查以及权限分配。景点类型管理维护分类层级关系，必玩榜单管理配置推荐展示内容。旅游路线管理整合景点形成游玩方案，景点信息管理审核编辑景点详细资料。门票预约记录显示游客的订单状态，可以对预约进行取消、退款等操作。美食类型管理负责餐饮分类，美食信息管理负责菜单上下架和价格调整。餐饮预约记录核对订单信息，退款申请模块处理用户发起的退款申请。系统管理有轮播图设置和数据备份，通知公告发布系统消息。资源管理处理上传图片、文件，交流管理审核论坛帖子的内容。操作日志可以记录管理员的全部行为，有利于追查。

　　游客角色用例图如图3-1所示。

图3-1游客用例图

　　管理员角色用例图如图3-2所示。

图3-2管理员用例图

第四章 系统设计

4.1 系统架构设计

　　系统采用前后端分离的B/S架构模式，移动端与Web管理端共享同一套后端服务接口。表现层由Android客户端与Vue.js管理界面构成，用户通过移动设备或PC浏览器访问系统功能。业务逻辑层封装在Spring Boot框架构建的服务端中，控制器接收请求后调用服务层方法处理业务规则[17]。数据访问层通过MyBatis框架与MySQL数据库交互，执行增删改查操作。整个系统架构如图4-1所示。

图4-1系统架构图

4.2 功能结构设计

　　青岛旅游APP包含游客与管理两大用户角色体系。游客通过移动端完成景点信息查询、美食内容浏览、交流论坛参与、个人资料维护、客服咨询提交等操作。管理员通过Web后台实现系统用户管理、景点类型配置、必玩榜单维护、旅游路线规划、景点信息审核、门票预约处理、美食类型管理、美食信息维护、餐饮预约处理、退款申请审核、系统管理、资源管理、交流管理、操作日志查看等功能。系统功能结构图如图4-2所示。

图4-2系统功能结构图

4.3 业务流程设计

4.3.1 系统总体业务流程设计

　　游客启动应用后进入首页浏览推荐内容。选择景点模块查看详细信息后发起预约请求。系统校验库存余量与预约限制后生成订单。游客完成支付操作获得电子凭证。餐饮预约流程与景点预约类似，用户选择美食项目后提交预订信息。管理员登录后台处理待审核订单，确认有效后更新订单状态。退款申请由游客在个人中心发起，管理员审核后执行退款操作。系统总体业务流程图如图4-3所示。

图4-3系统总体业务流程图

4.3.2 景点信息浏览流程设计

　　游客进入景点信息模块查看分类筛选栏。滚动列表展示景点名称与封面图片，点击卡片进入详情页面。详情页加载景点位置、票价、开放时间等资料。游客观看宣传视频获取更直观的体验信息。收藏功能记录感兴趣的景点到个人中心。点赞操作表达对内容的认可态度。系统统计浏览行为供推荐模块使用。景点信息浏览流程图如图4-4所示。

图4-4景点信息浏览流程图

4.3.3 门票预约流程设计

　　游客选定目标景点后进入预约页面。系统展示可选日期与剩余票数信息。游客选择出行日期后填写购票数量。系统实时计算应付总金额并展示明细。游客确认信息无误后提交订单。系统检查名额占用情况，通过则生成待支付订单。游客跳转支付渠道完成付款操作。支付成功后系统更新订单状态并下发电子凭证。门票预约流程图如图4-5所示。

图4-5门票预约流程图

4.3.4 美食信息浏览流程设计

　　游客通过底部导航栏切换到美食模块。系统按美食类型分类展示菜品卡片。游客点击卡片进入详情页查看价格、口味、商家信息。滑动页面浏览用户评价与实拍图片。收藏按钮将心仪美食加入个人收藏夹。系统基于浏览历史推荐相似口味菜品。游客使用搜索框输入关键词快速定位目标菜品。美食信息浏览流程图如图4-6所示。

图4-6美食信息浏览流程图

4.3.5 退款申请流程设计

　　游客进入个人中心的订单列表页面。选择需要退款的预约订单点击申请按钮。系统校验申请时间是否在允许退款期限内。游客填写退款原因后提交申请。系统将申请单推送到管理员后台。管理员查看申请详情后做出审核决定。审核通过时系统触发退款操作，款项原路返回支付账户。审核拒绝时系统向游客推送拒绝通知并说明原因。退款申请流程图如图4-7所示。

图4-7退款申请流程图

4.4 数据库设计

　　数据库是应用系统存储业务数据的核心基础设施[18]。关系型模型通过二维表结构组织数据，每张表包含若干字段定义存储格式。规范化原则指导表结构设计，消除数据冗余与更新异常问题。在本系统中数据库承担用户信息、景点资料、预约记录等持久化存储职责。主键外键约束保证数据引用完整性，索引机制提升查询响应速度。

4.4.1 概念设计

　　用户实体主要包括用户ID、用户名、密码、昵称、手机号码、邮箱、账户状态等属性。实体属性图如图4-8所示。

图4-8用户实体属性图

　　景点信息实体主要包括景点ID、名称、类型、位置、票价、评分、图片、攻略、视频等属性。实体属性图如图4-9所示。

图4-9景点信息实体属性图

　　美食信息实体主要包括美食ID、名称、类型、价格、口味、店铺地址、图片、商家详情等属性。实体属性图如图4-10所示。

图4-10美食信息实体属性图

　　门票预约实体主要包括预约ID、景点名称、预定日期、预定数量、合计支付、支付状态等属性。实体属性图如图4-11所示。

图4-11门票预约实体属性图

　　餐饮预约实体主要包括预约ID、美食名称、预定日期、预约数量、合计支付、支付状态等属性。实体属性图如图4-12所示。

图4-12餐饮预约实体属性图

　　论坛实体主要包括论坛ID、标题、正文、类型、发帖人ID、点击数、点赞数、是否置顶等属性。实体属性图如图4-13所示。

图4-13论坛实体属性图

　　必玩榜单实体主要包括榜单ID、名称、类型、季节专题、封面图片、详情简介等属性。实体属性图如图4-14所示。

图4-14必玩榜单实体属性图

　　旅游路线实体主要包括路线ID、名称、详情、出行类型、天数、适合人群、封面图片等属性。实体属性图如图4-15所示。

图4-15旅游路线实体属性图

　　评论实体主要包括评论ID、内容、评论人ID、昵称、回复目标ID、是否置顶等属性。实体属性图如图4-16所示。

图4-16评论实体属性图

　　收藏实体主要包括收藏ID、收藏人ID、来源ID、标题、封面、创建时间等属性。实体属性图如图4-17所示。

图4-17收藏实体属性图

　　退款申请实体主要包括申请ID、退款类型、退款原因、审核状态、审核回复、申请人信息等属性。实体属性图如图4-18所示。

图4-18退款申请实体属性图 图4-19系统E-R图

4.4.2 数据库表设计

　　用户表主要用来存储系统账号信息。主要包括用户ID、用户名、密码、手机号码、邮箱、账户状态等字段。如表4-1所示。

表4-1用户表

　　景点信息表主要用来存储旅游景点资料。主要包括景点ID、名称、类型、位置、票价、评分、图片、攻略、视频等字段。如表4-2所示。

表4-2景点信息表

　　美食信息表主要用来存储餐饮内容数据。主要包括美食ID、名称、类型、价格、口味、店铺地址、图片、商家详情等字段。如表4-3所示。

表4-3美食信息表

　　门票预约表主要用来记录游客购票订单。主要包括预约ID、景点名称、预定日期、预定数量、合计支付、支付状态等字段。如表4-4所示。

表4-4门票预约表

　　餐饮预约表主要用来记录用餐预订订单。主要包括预约ID、美食名称、预定日期、预约数量、合计支付、支付状态等字段。如表4-5所示。

表4-5餐饮预约表

　　论坛表主要用来存储用户发帖内容。主要包括论坛ID、标题、正文、类型、发帖人ID、点击数、点赞数、是否置顶等字段。如表4-6所示。

表4-6论坛表

　　必玩榜单表主要用来配置推荐内容组合。主要包括榜单ID、名称、类型、季节专题、封面图片、详情简介等字段。如表4-7所示。

表4-7必玩榜单表

　　旅游路线表主要用来存储游玩方案数据。主要包括路线ID、名称、详情、出行类型、天数、适合人群、封面图片等字段。如表4-8所示。

表4-8旅游路线表

　　评论表主要用来存储用户评价内容。主要包括评论ID、内容、评论人ID、昵称、回复目标ID、是否置顶等字段。如表4-9所示。

表4-9评论表

　　收藏表主要用来存储用户标记记录。主要包括收藏ID、收藏人ID、来源ID、标题、封面、创建时间等字段。如表4-10所示。

表4-10收藏表

　　退款申请表主要用来记录售后处理数据。主要包括申请ID、退款类型、退款原因、审核状态、审核回复、申请人信息等字段。如表4-11所示。

表4-11退款申请表

第五章 系统详细设计与实现

5.1 用户功能实现

5.1.1 用户登录功能实现

　　用户登录验证通过UserController调用相关服务完成。前端提交用户名密码后，控制器接收请求并调用业务层校验账号状态。系统比对数据库中的加密密码，匹配成功后返回访问令牌。该过程还涉及用户组权限的加载，用于控制后续界面展示范围。登录界面如图5-1所示。

图5-1登录界面

　　核心代码实现如下：

　　public classUserControllerextendsBaseController<User,UserService> {

　　@Autowired

　　publicUserController(UserServiceservice) {

　　setService(service);

　　}

　　}

5.1.2 首页功能实现

　　首页内容聚合通过数据接口动态加载。控制器根据不同用户组的推荐策略，调用景点与美食服务获取展示列表。该过程综合用户历史行为数据，由推荐引擎筛选匹配度较高的条目。前端发起请求后，系统完成数据组装并返回结构化的JSON响应。首页界面如图5-2所示。

图5-2首页界面

　　核心代码实现如下：

@RestController

@RequestMapping("user")

public classUserControllerextendsBaseController&lt;User,UserService&gt; {

@Autowired

　　publicUserController(UserServiceservice) {

　　setService(service);

　　}

　　}

5.1.3 景点信息功能实现

　　景点信息浏览由AttractionInformationController处理请求。控制器接收分页参数与筛选条件，调用服务层从数据库检索符合要求的景点数据。系统根据用户ID记录浏览行为，这些数据后续用于个性化推荐计算。搜索结果按热度或评分排序后返回移动端渲染。景点信息界面如图5-3所示。

图5-3景点信息界面

　　核心代码实现如下：

@RestController

@RequestMapping("attraction_information")

public classAttractionInformationControllerextendsBaseController&lt;AttractionInformation,AttractionInformationService&gt; {

@Autowired

　　publicAttractionInformationController(AttractionInformationServiceservice) {

　　setService(service);

　　}

　　}

5.1.4 美食信息功能实现

　　美食信息展示由FoodInformationController负责数据输出。控制器解析前端传递的类型筛选与排序参数，调用业务层执行数据库查询操作。系统计算每条美食的收藏数与点赞数，动态生成热度标识。推荐引擎介入调整列表顺序，优先展示用户偏好口味相关菜品。美食信息界面如图5-4所示。

图5-4美食信息界面

　　核心代码实现如下：

@RestController

@RequestMapping("food_information")

public classFoodInformationControllerextendsBaseController&lt;FoodInformation,FoodInformationService&gt; {

@Autowired

　　publicFoodInformationController(FoodInformationServiceservice) {

　　setService(service);

　　}

　　}

5.1.5 交流论坛功能实现

　　论坛帖子管理由ForumController统一处理增删改查请求。用户发帖时控制器接收标题与正文内容，调用服务层写入数据库并将状态设为待审核。评论功能通过CommentController实现，系统验证用户登录状态后存储回复内容。点赞操作触发HitsController记录互动行为。交流论坛界面如图5-5所示。

图5-5交流论坛界面

　　核心代码实现如下：

@RestController

@RequestMapping("forum")

public classForumControllerextendsBaseController&lt;Forum,ForumService&gt; {

@Autowired

　　publicForumController(ForumServiceservice) {

　　setService(service);

　　}

　　}

5.1.6 个人中心功能实现

　　个人资料管理由UserController提供信息查询与更新接口。控制器根据token解析当前登录用户ID，调用服务层获取用户实体数据。修改资料时系统校验字段合法性，更新数据库记录并清除缓存。订单列表与收藏记录分别委托给TicketReservationController与CollectController处理。个人中心界面如图5-6所示。

图5-6个人中心界面

　　核心代码实现如下：

@RestController

@RequestMapping("user")

public classUserControllerextendsBaseController&lt;User,UserService&gt; {

@Autowired

　　publicUserController(UserServiceservice) {

　　setService(service);

　　}

　　}

5.1.7 客服咨询功能实现

　　客服咨询消息通过MessageInformController完成提交与记录。用户填写咨询内容后控制器接收表单数据，调用服务层保存消息实体并将状态设为未处理。系统为该咨询生成唯一标识，管理员后台可查看所有待回复条目。用户在个人中心可追踪已提交咨询的处理进度。客服咨询界面如图5-7所示。

图5-7客服咨询界面

　　核心代码实现如下：

@RestController

@RequestMapping("message_inform")

public classMessageInformControllerextendsBaseController&lt;MessageInform,MessageInformService&gt; {

@Autowired

　　publicMessageInformController(MessageInformServiceservice) {

　　setService(service);

　　}

　　}

5.2 管理员功能实现

5.2.1 管理员登录功能实现

　　管理员身份验证复用UserController的登录接口，系统通过用户组字段区分角色权限。登录成功后后端返回的令牌携带角色标识，前端据此渲染管理界面菜单。控制器在验证过程中额外检查账户状态是否被冻结，异常账号拒绝访问后台资源。登录界面如图5-8所示。

　　 图5-8登录界面

　　核心代码实现如下：

　　public classUserControllerextendsBaseController<User,UserService> {

　　@Autowired

　　publicUserController(UserServiceservice) {

　　setService(service);

　　}

　　}

5.2.2 后台首页功能实现

　　后台首页数据看板需要聚合多项统计数据。控制器调用各个业务模块的服务方法，获取用户总数、景点数量、今日订单量等指标。系统通过OperationLogController记录管理员每日登录行为，这些日志用于生成访问趋势图表。数据返回后由前端ECharts库渲染可视化组件。后台首页界面如图5-9所示。

　　 图5-9后台首页界面

　　核心代码实现如下：

@RestController

@RequestMapping("operation_log")

public classOperationLogControllerextendsBaseController&lt;OperationLog,OperationLogService&gt; {

@Autowired

　　publicOperationLogController(OperationLogServiceservice) {

　　setService(service);

　　}

　　}

5.2.3 系统用户功能实现

　　系统用户管理由UserController提供完整的CRUD操作集合。管理员调用列表接口获取所有注册账号，支持按用户名模糊搜索。新增用户时控制器验证账号唯一性，密码经过加密处理后存储。修改状态接口用于冻结异常账号或解封受限用户。系统用户界面如图5-10所示。

　　 图5-10系统用户界面

　　核心代码实现如下：

@RestController

@RequestMapping("user")

public classUserControllerextendsBaseController&lt;User,UserService&gt; {

@Autowired

　　publicUserController(UserServiceservice) {

　　setService(service);

　　}

　　}

5.2.4 景点类型管理功能实现

　　景点类型维护由TypeOfAttractionController处理分类数据的增删改查。控制器接收分类名称与排序权重参数，调用服务层写入数据库。修改操作需要校验分类下是否已关联景点，若存在关联则提示先解除绑定。返回的分类列表按排序字段升序排列，用于前端下拉选择器渲染。景点类型管理界面如图5-11所示。

　　 图5-11景点类型管理界面

　　核心代码实现如下：

@RestController

@RequestMapping("type_of_attraction")

public classTypeOfAttractionControllerextendsBaseController&lt;TypeOfAttraction,TypeOfAttractionService&gt; {

@Autowired

　　publicTypeOfAttractionController(TypeOfAttractionServiceservice) {

　　setService(service);

　　}

　　}

5.2.5 必玩榜单管理功能实现

　　必玩榜单配置由MustPlaySummaryController实现内容编排功能。控制器接收榜单名称、封面图片、关联景点列表等参数，调用服务层维护榜单实体。系统支持调整榜单内景点的展示顺序，通过排序字段控制前端呈现次序。上下架状态控制移动端首页是否展示该榜单。必玩榜单管理界面如图5-12所示。

　　 图5-12必玩榜单管理界面

　　核心代码实现如下：

@RestController

@RequestMapping("must_play_summary")

public classMustPlaySummaryControllerextendsBaseController&lt;MustPlaySummary,MustPlaySummaryService&gt; {

@Autowired

　　publicMustPlaySummaryController(MustPlaySummaryServiceservice) {

　　setService(service);

　　}

　　}

5.2.6 旅游路线管理功能实现

　　旅游路线管理由TouristRouteController负责路线方案的数据维护。管理员提交路线名称、出行天数、行程详情等内容后，控制器完成数据持久化存储。系统支持为每条路线关联多个景点，通过中间表维护多对多关系。前端展示时可调用接口获取完整路线信息供游客浏览。旅游路线管理界面如图5-13所示。

　　 图5-13旅游路线管理界面

　　核心代码实现如下：

@RestController

@RequestMapping("tourist_route")

public classTouristRouteControllerextendsBaseController&lt;TouristRoute,TouristRouteService&gt; {

@Autowired

　　publicTouristRouteController(TouristRouteServiceservice) {

　　setService(service);

　　}

　　}

5.2.7 景点信息管理功能实现

　　景点资料维护由AttractionInformationController实现完整的信息管理能力。管理员添加景点时控制器接收名称、位置、票价、图片等字段，调用服务层执行插入操作。编辑功能支持修改已发布景点的详细内容，修改后状态自动同步到缓存。下架操作将景点标记为不可见，前端不再展示该条目。景点信息管理界面如图5-14所示。

　　 图5-14景点信息管理界面

　　核心代码实现如下：

@RestController

@RequestMapping("attraction_information")

public classAttractionInformationControllerextendsBaseController&lt;AttractionInformation,AttractionInformationService&gt; {

@Autowired

　　publicAttractionInformationController(AttractionInformationServiceservice) {

　　setService(service);

　　}

　　}

5.2.8 门票预约管理功能实现

　　门票预约订单由TicketReservationController提供查询与状态变更接口。管理员调用列表接口获取所有预约记录，支持按日期范围与支付状态筛选。确认订单接口将预约状态从未处理变更为已确认，系统自动向游客推送通知短信。取消订单接口触发退款流程，调用支付网关执行资金原路退回。门票预约管理界面如图5-15所示。

　　 图5-15门票预约管理界面

　　核心代码实现如下：

@RestController

@RequestMapping("ticket_reservation")

public classTicketReservationControllerextendsBaseController&lt;TicketReservation,TicketReservationService&gt; {

@Autowired

　　publicTicketReservationController(TicketReservationServiceservice) {

　　setService(service);

　　}

　　}

5.2.9 美食类型管理功能实现

　　美食类型维护由TypeOfFoodController实现分类体系管理。控制器提供新增类型与编辑名称功能，分类数据用于前端筛选器构建。删除分类前系统校验该类型下是否存在关联菜品，存在关联时拒绝删除操作。排序接口调整类型在移动端的显示顺序，热门类型优先展示。美食类型管理界面如图5-16所示。

　　 图5-16美食类型管理界面

　　核心代码实现如下：

@RestController

@RequestMapping("type_of_food")

public classTypeOfFoodControllerextendsBaseController&lt;TypeOfFood,TypeOfFoodService&gt; {

@Autowired

　　publicTypeOfFoodController(TypeOfFoodServiceservice) {

　　setService(service);

　　}

　　}

5.2.10 美食信息管理功能实现

　　菜品数据管理由FoodInformationController实现内容维护功能。管理员添加菜品时控制器接收名称、价格、口味、店铺地址等参数，存储后同步到搜索索引。编辑价格接口支持批量修改，适应市场波动时的快速调价需求。上下架操作控制菜品在前端的可见性，下架菜品不再接受新预约。美食信息管理界面如图5-17所示。

　　 图5-17美食信息管理界面

　　核心代码实现如下：

@RestController

@RequestMapping("food_information")

public classFoodInformationControllerextendsBaseController&lt;FoodInformation,FoodInformationService&gt; {

@Autowired

　　publicFoodInformationController(FoodInformationServiceservice) {

　　setService(service);

　　}

　　}

5.2.11 餐饮预约管理功能实现

　　餐饮预约订单由DiningReservationController负责处理。控制器提供订单列表查询接口，支持按预约日期与支付状态筛选。确认预约接口更新订单状态，系统将预约编号通过短信发送给游客。取消订单接口处理用户发起的退款请求，更新订单状态后通知财务模块执行退款。餐饮预约管理界面如图5-18所示。

　　 图5-18餐饮预约管理界面

　　核心代码实现如下：

@RestController

@RequestMapping("dining_reservation")

public classDiningReservationControllerextendsBaseController&lt;DiningReservation,DiningReservationService&gt; {

@Autowired

　　publicDiningReservationController(DiningReservationServiceservice) {

　　setService(service);

　　}

　　}

5.2.12 退款申请管理功能实现

　　退款申请审核由RefundRequestController实现处理流程。控制器展示所有待审核退款申请列表，包含订单号与退款原因。审核通过接口调用支付网关执行退款操作，成功后更新申请状态为已完成。拒绝退款时系统要求填写拒绝理由，该理由以站内信形式推送给用户。退款申请管理界面如图5-19所示。

　　 图5-19退款申请管理界面

　　核心代码实现如下：

@RestController

@RequestMapping("refund_request")

public classRefundRequestControllerextendsBaseController&lt;RefundRequest,RefundRequestService&gt; {

@Autowired

　　publicRefundRequestController(RefundRequestServiceservice) {

　　setService(service);

　　}

　　}

5.2.13 系统管理功能实现

　　系统配置管理由SlidesController等组件提供参数维护能力。轮播图配置接口接收图片地址与跳转链接，控制移动端首页展示内容。控制器提供上传接口接收图片文件，存储后将访问路径写入数据库。排序接口调整轮播图展示顺序，权重高的图片优先显示。系统管理界面如图5-20所示。

　　 图5-20系统管理界面

　　核心代码实现如下：

@RestController

@RequestMapping("slides")

public classSlidesControllerextendsBaseController&lt;Slides,SlidesService&gt; {

@Autowired

　　publicSlidesController(SlidesServiceservice) {

　　setService(service);

　　}

　　}

5.2.14 通知公告管理功能实现

　　公告发布由NoticeController实现消息推送功能。控制器接收公告标题与正文内容，存储后系统将公告推送给所有在线用户。置顶接口将重要公告固定在列表顶部，确保用户优先阅读。公告列表接口支持分页查询，返回数据供移动端公告栏展示。通知公告管理界面如图5-21所示。

　　 图5-21通知公告管理界面

　　核心代码实现如下：

@RestController

@RequestMapping("notice")

public classNoticeControllerextendsBaseController&lt;Notice,NoticeService&gt; {

@Autowired

　　publicNoticeController(NoticeServiceservice) {

　　setService(service);

　　}

　　}

5.2.15 资源管理功能实现

　　文件上传由UploadController统一处理资源存储。控制器接收MultipartFile对象，将文件写入服务器本地目录并生成唯一文件名。上传成功后系统返回文件访问URL，供其他功能模块引用。控制器支持图片压缩与格式转换，节省存储空间并提升加载速度。资源管理界面如图5-22所示。

　　 图5-22资源管理界面

　　核心代码实现如下：

@RestController

@RequestMapping("upload")

public classUploadControllerextendsBaseController&lt;Upload,UploadService&gt; {

@Autowired

　　publicUploadController(UploadServiceservice) {

　　setService(service);

　　}

　　}

5.2.16 交流管理功能实现

　　论坛内容审核由ForumController与CommentController协同完成。待审核帖子列表接口返回所有状态为待审核的帖子，管理员可逐条审查。审核通过接口更新帖子状态为已发布，前端论坛板块立即可见。评论审核流程类似，控制器提供单独的审核接口过滤不当言论。交流管理界面如图5-23所示。

　　 图5-23交流管理界面

　　核心代码实现如下：

@RestController

@RequestMapping("forum")

public classForumControllerextendsBaseController&lt;Forum,ForumService&gt; {

@Autowired

　　publicForumController(ForumServiceservice) {

　　setService(service);

　　}

　　}

5.2.17 操作日志功能实现

　　操作日志记录由OperationLogController提供查询与导出功能。系统通过AOP切面自动拦截管理员的关键操作，控制器将操作人、时间、请求路径等信息持久化存储。日志列表接口支持按操作人筛选与时间范围过滤，方便事后审计追溯。导出接口生成Excel文件供管理员存档。操作日志界面如图5-24所示。

　　 图5-24操作日志界面

　　核心代码实现如下：

@RestController

@RequestMapping("operation_log")

public classOperationLogControllerextendsBaseController&lt;OperationLog,OperationLogService&gt; {

@Autowired

　　publicOperationLogController(OperationLogServiceservice) {

　　setService(service);

　　}

　　}

第六章 系统测试

6.1 测试目的

　　系统测试旨在验证软件功能与设计规格的一致性程度。测试过程检查各模块在正常输入与异常输入下的响应行为，确认系统具备适当的边界容错能力。门票预约与退款申请等涉及资金流转的功能需验证状态变更正确性，确保订单数据在不同环节间保持逻辑连贯。个性化推荐模块需验证推荐结果与用户历史行为的相关性，通过样本数据检查推荐质量。兼容性测试确认应用在不同Android版本和屏幕尺寸下的显示效果，减少用户端异常情况[19]。

6.2 测试方法

　　本次测试采用黑盒测试方法，在不关注内部实现逻辑的前提下验证功能正确性[20]。功能测试覆盖所有用户角色的核心操作路径，包括景点浏览、门票预约、论坛发帖、退款申请等流程。针对表单提交类功能设计等价类划分用例，测试边界值处理是否正确。兼容性测试选取不同Android版本设备与模拟器，验证界面渲染与功能调用的一致性。性能测试模拟多用户并发场景，观察响应时间与系统资源占用变化。

6.3 测试用例

　　（1）游客登录注册功能测试如表6-1所示。

表6-1游客登录注册功能测试

　　（2）景点信息浏览测试如表6-2所示。

表6-2景点信息浏览测试

　　（3）门票预约功能测试如表6-3所示。

表6-3门票预约功能测试

　　（4）论坛发帖测试如表6-4所示。

表6-4论坛发帖测试

　　（5）退款申请测试如表6-5所示。

表6-5退款申请测试

测试结论

　　经过系统测试后所有功能模块均可正常运行。移动端与管理后台交互流程符合设计预期。门票预约与退款申请涉及的状态机逻辑在测试中表现正确，订单数据未出现不一致情况。论坛发帖审核机制有效过滤了异常内容。兼容性测试显示应用在主流Android版本上运行稳定，界面布局未出现明显错位。个性化推荐结果与用户历史行为具有较高相关性，测试样本中推荐命中率达到预期水平。

项目分享：大家可自取用于参考学习，获取方式可私信哦！