摘要
古城景区作为文化旅游的重要载体，其信息化管理水平直接影响游客体验的质量。传统景区依赖人工窗口售票、纸质地图导航、线下商铺购物等分散运营模式，在客流高峰期暴露出效率低下、信息滞后、管理混乱等突出问题。随着移动互联网技术的成熟与用户数字化习惯的形成，景区管理模式亟需完成系统性的数字化转型。
本文面向古城景区的多元业务场景，设计并实现了一套基于Spring Boot框架的古城景区管理系统。系统采用B/S架构，后端以Spring Boot为核心构建RESTful服务接口，前端采用Vue框架实现响应式页面交互，数据层以MySQL数据库承载景区核心业务数据。系统围绕用户、景区管理者、商家、管理员四类角色展开功能设计，覆盖景点信息浏览、导航地图、互动打卡、景区商城、订单管理、预约购票、退票申请、优惠券管理、权限控制、通知公告等完整业务链路。
经功能测试与集成验证，系统各模块运行稳定，业务逻辑正确，界面交互流畅，达到预期设计目标，具备在古城景区实际场景中落地部署的条件。
关键词：古城景区管理；Spring Boot；Vue；MySQL；B/S架构
Abstract
Ancient town scenic areas serve as vital carriers of cultural tourism, and their level of information management directly determines the quality of visitor experience. Traditional scenic area operations rely on manual ticket windows, paper maps for navigation, and offline retail, which expose severe inefficiencies, information delays, and management disorder during peak visitor periods. As mobile internet technology matures and digital habits solidify among users, a systematic digital transformation of scenic area management has become urgently necessary.
This paper designs and implements a scenic area management system for ancient town attractions based on the Spring Boot framework. The system adopts a B/S architecture, with the backend building RESTful service interfaces centered on Spring Boot, the frontend implementing responsive page interactions using the Vue framework, and the data layer using MySQL to store core business data.
The system is organized around four roles---visitor, scenic area manager, merchant, and administrator---covering a complete business chain including scenic spot browsing, navigation maps, interactive check-in, scenic mall, order management, ticket reservation, refund applications, coupon management, permission control, and announcement publishing. Functional testing and integration verification confirm that all modules operate stably, business logic is correct, and interface interactions are smooth, meeting the expected design objectives and demonstrating readiness for deployment in real ancient town scenic area environments.
**Key Words:**Ancient town scenic area management; Spring Boot; Vue; MySQL; B/S architecture
第一章 绪论
1.1 研究背景与意义
1.1.1 研究背景
文化旅游产业的持续扩张推动着景区信息化建设进入加速阶段。古城景区因兼具文化传承与旅游消费的双重属性，管理业务链条远比普通自然景区复杂。现有古城景区的运营模式大量依赖人工操作：购票窗口排队等候时间长，商铺信息分散无法在线查询，导览资料以纸质形式发放且更新滞后，景点打卡活动缺乏有效的数字记录手段。这些问题在节假日高峰期被集中放大，严重制约游客体验的整体质量1。国内相关研究表明，数字化管理平台的建设能够系统性地改善景区服务效率，实现业务数据的集中管控与实时分析2。与此同时，非物质文化遗产数字化展示的实践也为古城景区引入多媒体互动、在线预约等功能模块提供了成熟的参考路径3。当前，Java Web技术体系已发展为国内景区信息系统建设的主流技术选型，Spring Boot框架凭借其轻量化配置、模块解耦清晰、接口开发效率高等特点，在中小型景区管理系统的落地实践中展现出显著优势。面向古城景区多角色、多业务场景的管理需求，构建一套功能完整、架构清晰的综合性管理系统，既是技术发展趋势的必然导向，也是景区数字化运营的现实迫切需求。
1.1.2 研究意义
本系统的建设对古城景区的运营管理具有切实的改进价值。系统将购票预约、导航地图、景区商城、打卡互动等核心业务集成至统一平台，显著缩短游客在各业务环节的等待时间，降低景区工作人员在重复性事务上的人工成本。多角色权限体系的引入使景区管理者、商家、管理员各自在授权范围内完成操作，减少跨部门协调摩擦，提升整体管理精度。订单数据、游客行为数据的系统性积累为景区经营决策提供可量化的数据依据，改变依赖经验判断的粗放管理方式。在示范效应层面，本系统的设计思路与技术实践路径可为同类型文化旅游景区开展数字化转型提供参照，具备一定的行业推广价值。
1.2 国内外研究现状
1.2.1 国内现状
国内景区信息化管理的研究起步于二十一世纪初，早期研究集中于景区票务系统的电子化改造，技术形态以C/S架构的单机管理软件为主。进入移动互联网时代后，研究方向逐步向B/S架构的综合管理平台迁移，景区商城、在线预约、游客互动等功能模块相继被纳入研究视野。近年来，大数据分析、GIS地理信息、小程序开发等技术方向持续融入景区管理系统的研究议题，系统形态从单一票务管理演进为覆盖游前、游中、游后全流程的综合服务平台。
宁毅等人于2024年基于智能化技术构建了智慧景区应用系统，系统采用Flask Web框架、Vue前端框架与MySQL数据库的技术组合，实现了景点管理、用户管理、订单管理及门票管理等核心功能模块，其多角色权限划分的设计思路对本系统的角色体系构建具有直接借鉴价值4。王育英于2024年完成了基于GIS二次开发的旅游规划信息系统研究，该研究将地理信息技术深度整合至景区服务体系，为游客提供精准的空间定位与路线规划功能，本系统导航地图模块的功能设计从中获得了重要的方法论启示5。和娴等人于2024年设计并实现了旅游景区游客信息系统，系统基于移动定位技术对游客行为数据进行系统性采集与分析，涵盖热门景点识别、游客类型判断、消费数据统计等功能，其数据驱动的运营分析理念对本系统订单数据模块的设计产生了参考意义6。
1.2.2 国外现状
国外在景区管理与文化旅游信息系统领域的研究具有明显的智能化导向，研究成果集中于大数据驱动的游客行为分析、虚拟现实技术在文化遗产展示中的应用，以及基于物联网感知的景区实时监控系统。总体而言，国外研究更注重用户体验的系统性评估与多技术手段的融合创新，技术方案成熟度高，但部分成果的落地场景与国内古城景区的运营现实存在一定差距。
Rong等人于2024年提出了基于异常行为识别的大数据智慧旅游管理平台，将区域卷积3D网络模型与轨迹分析方法相结合，实现景区内异常行为的实时识别，研究表明该方法在准确率和召回率上均显著优于传统双流模型，其平台的多模块协同架构设计对本系统功能分层的思路形成了参考7。Teeng等人于2021年对虚拟现实技术在文化遗产实践中的可用性进行系统性综述，识别出系统设计、开发过程、技术实现、评估方式、知识传递五个维度的挑战，并提出58条改进建议，其关于用户体验系统性评估的研究框架对本系统界面交互设计具有方法论层面的借鉴意义8。Shi等人于2021年完成了泉州新型智慧旅游管理平台的设计与实现，平台围绕景点信息管理、酒店信息管理等核心功能模块展开设计，响应国家"互联网+旅游"政策导向，其功能模块的划分逻辑与本系统的模块结构设计具有较强的参照关系9。
国外研究在技术深度与智能化程度上具备明显优势，但其系统设计多面向大规模景区或特定技术场景，与国内古城景区多角色、轻量化、强业务融合的实际需求存在落差。本系统在吸收国外研究关于用户体验评估、平台功能分层、多模块协同等核心设计思想的基础上，结合古城景区商城购物、互动打卡、预约购票等本地化业务场景，形成更贴合实际运营需求的系统设计方案。
1.3 研究内容
本文的核心工作是面向古城景区多元业务场景，完成基于Spring Boot框架的古城景区管理系统的设计与实现。研究从需求分析阶段出发，通过对用户、景区管理者、商家、管理员四类角色的业务需求进行系统性梳理，明确各角色的功能边界与交互关系，为后续设计工作奠定需求基础。需求分析完成后，研究进入系统设计阶段，依次完成系统整体架构设计、功能结构划分、核心业务流程建模，以及数据库概念模型与逻辑模型的构建，形成覆盖系统全貌的设计文档。在模块实现阶段，研究按照角色维度逐一推进各功能模块的编码工作，重点完成景区商城、订单管理、预约购票、退票申请、导航地图、互动打卡、优惠券管理、通知公告等核心业务模块的开发。数据设计贯穿系统实现的全过程，通过对数据库表结构的精细化设计保障业务数据的完整性与一致性。研究的最终交付物为可完整运行的系统原型，并配套功能测试报告。本研究不涉及系统的高并发性能调优、分布式部署方案，以及移动端原生应用开发等相关内容。整体研究遵循软件工程的生命周期方法论，按照需求---设计---实现---测试的工作流顺序推进各阶段任务。
第二章 相关技术介绍
2.1 Spring Boot框架
Spring Boot是由Pivotal团队在Spring框架基础上进一步封装而成的快速开发框架，其核心设计理念是"约定优于配置"。开发者无需编写大量的XML配置文件，框架通过自动配置机制在应用启动时依据类路径中的依赖自动完成组件装配，大幅降低项目初始化的复杂度。Spring Boot内嵌Tomcat等Servlet容器，使得应用可以以独立JAR包的形式直接运行，免除了传统Java Web项目必须依赖外部容器部署的约束10。
在本系统中，Spring Boot承担后端业务逻辑的核心运行容器职责。景区商城的商品查询、订单状态流转、预约购票的库存扣减、退票申请的审核流程，均通过Spring Boot构建的RESTful接口对外暴露服务。Spring Boot的分层架构设计使Controller层、Service层、Repository层之间的职责边界清晰，不同角色的业务逻辑得以在各自的Service模块中独立维护，系统整体的可维护性显著提升11。
2.2 Vue前端框架
Vue是一套以数据驱动视图为核心设计哲学的渐进式JavaScript前端框架，由尤雨溪主导开发并持续演进至当前的Vue 3版本。Vue采用组件化开发模式，每个页面功能单元被封装为独立的单文件组件，组件内部集中管理模板、逻辑与样式，模块边界清晰，复用粒度精细。响应式数据系统是Vue的核心机制，当数据状态发生变化时，视图层自动完成局部更新，无需开发者手动操作DOM节点12。
Vue在本系统的前端开发中负责构建用户与系统交互的完整界面层。景点信息的列表渲染、导航地图的组件嵌入、景区商城的商品展示、互动打卡的状态反馈，均依托Vue的响应式机制实现数据与界面的同步更新。Vue Router负责管理前端的路由跳转，不同角色登录后自动导航至对应的功能模块，Vuex或Pinia状态管理工具则用于维护用户登录态与购物车等全局数据，构成前端业务逻辑的完整支撑体系13。
2.3 MySQL数据库
MySQL是目前使用最为广泛的开源关系型数据库管理系统，以其稳定的事务处理能力、成熟的索引优化机制、灵活的存储引擎选择成为中小型应用系统的首选数据层解决方案。MySQL支持SQL标准的完整子集，InnoDB存储引擎提供行级锁定与外键约束，保障高并发写入场景下的数据一致性14。
本系统所有核心业务数据均存储于MySQL数据库。用户信息、景点数据、商品目录、订单记录、预约信息、打卡记录等业务实体以关系型表结构组织，实体间的关联关系通过外键约束与联合查询实现。Spring Boot通过MyBatis-Plus框架与MySQL建立数据访问通道，业务层对数据库的增删改查操作被封装为类型安全的Mapper接口，降低了SQL编写错误的风险，同时保持了查询逻辑的可扩展性15。
2.4 B/S架构
B/S架构即浏览器-服务器架构，是相对于C/S架构演进而来的一种软件系统部署模式。在B/S架构下，客户端仅需标准浏览器即可访问系统全部功能，无需在用户终端安装专属客户端软件。业务逻辑集中部署于服务器端，系统维护与功能升级只需在服务器侧完成，更新结果即时对所有用户生效，大幅降低运维管理成本16。
古城景区管理系统采用B/S架构，使得游客、景区管理者、商家、管理员四类角色均可通过浏览器直接访问系统对应功能模块，无需针对不同操作系统分别开发客户端应用。景区商城的商品浏览、订单提交、预约购票的座位选择等面向游客的功能，景点信息的发布与打卡管理等面向景区管理者的功能，均在同一套B/S架构下统一承载。前端Vue应用与后端Spring Boot服务通过HTTP协议完成数据交互，架构层次分明，部署结构简洁17。
第三章 系统分析
3.1 可行性分析
3.1.1 技术可行性
Spring Boot框架在国内中小型Web系统开发中已积累了大量成熟实践，其与Vue前端框架、MySQL数据库的技术组合具备明确的社区支持与文档保障。B/S架构下的前后端分离开发模式已成为业界主流，各技术组件之间的接口规范成熟、兼容性稳定。系统所涉及的订单管理、预约购票、权限控制等业务模块均属常规Web系统功能范畴，现有技术栈完全具备支撑其完整实现的能力，技术风险处于可控范围之内。
3.1.2 经济可行性
本系统采用全开源技术栈，Spring Boot、Vue、MySQL均为免费使用的开源框架，无需承担商业软件授权费用。开发环境基于标准PC硬件与本地数据库部署，硬件投入成本有限。系统建成后的日常运维主要依赖服务器的基础托管费用，维护操作集中于服务器侧，无需向终端用户推送更新，长期运营成本处于合理区间，整体建设投入具备经济上的合理性。
3.1.3 操作可行性
系统前端基于Vue框架构建响应式界面，页面布局遵循常见Web应用的交互规范，功能入口层级清晰，操作路径短。游客角色的主要操作集中于景区商城浏览、购票预约、打卡签到等高频场景，交互步骤精简。景区管理者与商家的后台管理界面采用表格式数据展示与表单提交的标准模式，用户无需经过专项培训即可完成日常操作任务，学习成本处于较低水平。
3.2 功能需求分析
3.2.1 用户角色功能需求
用户角色是古城景区管理系统面向游客群体开放的核心使用端。该角色可在景区商城中浏览商品、完成下单操作，并查看对应的订单详情记录。导航地图模块为用户提供景区内的位置定向与路线浏览功能。景点信息模块支持用户查看各景点的基础资料。互动打卡模块允许用户在抵达指定景点后完成签到操作，触发系统记录并生成打卡轨迹。如图3-1所示。
图3-1用户用例图
3.2.3 商家角色功能需求
商家角色对应入驻古城景区的店铺经营主体。该角色可在景区商城模块中管理店铺商品的上架与下架操作。添加优惠券模块支持商家创建面向游客的折扣券数据。订单列表模块提供商家对自身店铺订单记录的查询功能。订单售后模块允许商家处理游客的售后请求。分类列表模块支持商家对商品分类目录进行维护操作。如图3-3所示。
图3-3商家用例图
3.2.4 管理员角色功能需求
管理员角色是系统权限层级最高的操作主体，负责全局数据的管控与系统运营的统筹维护。权限管理模块允许管理员对各角色的功能访问范围进行配置操作。操作日志模块提供系统内所有用户操作行为的查询与审计功能。通知发布模块支持管理员向指定角色推送运营通知。公告管理模块允许管理员对全局公告的内容进行增删改维护。用户管理模块支持管理员对注册用户账号的查询、禁用与信息修正操作。如图3-4所示。
图3-4管理员用例图
第四章 系统设计
4.1 系统架构设计
古城景区管理系统的整体架构以B/S模式为基础，将系统划分为用户界面层、应用服务层、数据持久层三个核心层次，各层之间职责分明，通过标准HTTP协议与数据访问接口完成跨层通信。用户界面层由Vue框架构建，负责将业务数据渲染为可视化的交互页面，支持四类角色的差异化界面呈现。应用服务层以Spring Boot为运行核心，封装景区商城、订单管理、预约购票、打卡互动等业务逻辑，对外提供统一的RESTful接口规范。数据持久层以MySQL数据库作为数据存储介质，通过MyBatis-Plus框架实现业务实体与数据库表之间的映射关系，保障数据的完整性与一致性。系统支持层涵盖本地开发环境、Maven依赖管理工具，以及Spring Security负责的身份认证与权限拦截机制，为系统稳定运行提供基础保障。系统架构图如图4-1所示。
图4-1系统架构图
4.2 系统结构功能设计
古城景区管理系统围绕用户、景区管理者、商家、管理员四类角色构建完整的功能体系。用户侧功能涵盖景区商城浏览购买、订单详情查看、导航地图使用、景点信息查询、互动打卡签到五个核心模块。景区管理者侧功能集中于景点信息维护、预约购票管理、退票申请审核、景点打卡统计四个运营管理模块。商家侧功能包括景区商城管理、优惠券添加、订单列表查询、订单售后处理、分类列表维护五个经营管理模块。管理员侧功能涵盖权限管理、操作日志审计、通知发布、公告管理、用户管理五个全局管控模块。各角色功能模块在统一架构下协同运作，形成完整的景区数字化管理闭环。该系统功能结构如图4-2所示。
图4-2系统功能结构图
4.3 业务流程设计
4.3.1 预约购票功能流程设计
用户进入预约购票模块后，系统首先校验该用户的登录状态。登录态有效时，用户选择目标景点与参观日期，系统查询对应时段的剩余票量。若票量充足，用户确认预约信息后提交订单，系统扣减库存并生成预约记录，流程完成。若票量不足，系统向用户返回余票不足提示，用户可选择更换日期重新查询。预约购票流程图如图4-3所示。
图4-3预约购票流程图
4.3.2 退票申请功能流程设计
游客在订单详情模块发起退票申请，系统检测当前订单状态是否处于可申请退票的有效期内。订单状态符合退票条件时，系统将申请记录提交至景区管理者的待审核队列。景区管理者对申请进行人工审核，审核通过后系统自动执行退款操作并将订单标记为已退款状态，审核驳回时系统向游客推送驳回原因通知。退票申请流程图如图4-4所示。
图4-4退票申请流程图
4.3.4 商家添加优惠券功能流程设计
商家登录系统后进入优惠券管理模块，填写优惠券名称、折扣面值、有效期限、适用商品范围等基础信息。系统对提交数据进行格式校验，校验通过后将优惠券记录写入数据库，并在对应商品页面同步展示优惠信息。若数据校验未通过，系统在表单对应字段处给出错误提示，商家修正后重新提交。商家添加优惠券流程图如图4-6所示。
图4-6商家添加优惠券流程图
4.3.5 管理员用户管理功能流程设计
管理员进入用户管理模块，输入查询条件检索目标用户记录。系统返回匹配列表后，管理员选择具体用户执行操作：若选择禁用账号，系统将该账号状态置为禁用，用户后续登录请求将被拒绝；若选择信息修正，系统弹出编辑表单，管理员提交修正数据后系统完成更新写入；若选择恢复账号，系统将账号状态重置为正常可用。管理员用户管理流程图如图4-7所示。
图4-7管理员用户管理流程图
4.4 数据库设计
4.4.1 概念模型设计
业务数据的组织方式决定着系统各功能模块能否在运行时保持逻辑一致性。古城景区管理系统涉及游客购票、商城购物、打卡签到、订单审核、优惠促销等多条业务线，每条业务线背后都存在结构化的数据实体及其相互间的依赖关系。概念模型设计的本质是将现实世界中的业务对象抽象为信息世界中可描述、可操作的实体集合，通过明确实体的属性构成与实体间的联系类型，完成从业务需求到数据结构的第一次形式化转换18。在本系统中，用户、景点、门票、订单、商品、打卡记录、优惠券等核心业务对象均被识别为独立实体，实体之间存在一对多与多对多两类主要联系形态：一个用户可生成多条订单，一条订单对应一件商品或一张门票，一个商家可发布多张优惠券。E-R图作为概念模型的标准可视化表达工具，能够将上述实体、属性及联系以图形化方式清晰呈现。基于以上分析，系统全域数据结构的概念模型以E-R图形式输出，为后续逻辑模型的表结构转换提供设计依据。全局E-R模型如图4-8所示。
图4-8全局ER图
4.4.2 数据库逻辑设计
关系数据库的逻辑设计是在概念模型确定后，将E-R图中的实体、属性与联系转换为具体数据库表结构的过程19。每个实体对应一张独立的数据库表，实体属性对应表中的字段，实体间的一对多联系通过外键字段在从表侧加以体现，多对多联系则借助中间关联表完成分解。本系统共设计十张核心业务表，涵盖用户、景点、门票订单、商品、商城订单、打卡记录、优惠券、商家、景区管理者、管理员等业务实体。字段的数据类型依据业务语义选取，字符型信息使用varchar存储，时间类信息统一采用datetime类型，金额类数据选用decimal保障精度，状态类标识以int类型记录。各表之间通过合理的主外键关联，构成业务完整、结构清晰的关系型数据库模型，为上层业务逻辑的实现提供稳定的数据访问基础。
（1）用户表主要是用来存储系统注册用户的基础账号信息。主要包括用户id、用户名、密码、手机号等字段。如表4-1所示。
表4-1用户表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | user_id | bigint | 20 | 主键 |
| 2 | username | varchar | 50 | 用户名 |
| 3 | password | varchar | 100 | 密码 |
| 4 | phone | varchar | 20 | 手机号 |
| 5 | avatar | varchar | 200 | 头像地址 |
| 6 | status | int | 11 | 账号状态 |
| 7 | create_time | datetime | - | 创建时间 |
| 8 | update_time | datetime | - | 更新时间 |
（2）景点表主要是用来存储古城景区内各景点的基础信息数据。主要包括景点id、景点名称、所在位置、门票价格等字段。如表4-2所示。
表4-2景点表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | spot_id | bigint | 20 | 主键 |
| 2 | spot_name | varchar | 100 | 景点名称 |
| 3 | spot_desc | varchar | 500 | 景点描述 |
| 4 | spot_image | varchar | 200 | 景点图片 |
| 5 | location | varchar | 200 | 所在位置 |
| 6 | open_time | varchar | 50 | 开放时间 |
| 7 | ticket_price | decimal | - | 门票价格 |
| 8 | manager_id | bigint | 20 | 景区管理者id |
| 9 | create_time | datetime | - | 创建时间 |
（3）门票订单表主要是用来记录游客预约购票的完整订单数据。主要包括门票订单id、用户id、景点id、订单状态等字段。如表4-3所示。
表4-3门票订单表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | ticket_order_id | bigint | 20 | 主键 |
| 2 | user_id | bigint | 20 | 用户id |
| 3 | spot_id | bigint | 20 | 景点id |
| 4 | visit_date | date | - | 预约日期 |
| 5 | buy_num | int | 11 | 购买数量 |
| 6 | pay_amount | decimal | - | 实付金额 |
| 7 | order_status | int | 11 | 订单状态 |
| 8 | create_time | datetime | - | 创建时间 |
（4）商品表主要是用来存储景区商城内上架商品的详细信息。主要包括商品id、商品名称、商品价格、商家id等字段。如表4-4所示。
表4-4商品表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | goods_id | bigint | 20 | 主键 |
| 2 | goods_name | varchar | 100 | 商品名称 |
| 3 | goods_desc | varchar | 500 | 商品描述 |
| 4 | goods_image | varchar | 200 | 商品图片 |
| 5 | price | decimal | - | 商品价格 |
| 6 | stock | int | 11 | 库存数量 |
| 7 | category_id | bigint | 20 | 分类id |
| 8 | merchant_id | bigint | 20 | 商家id |
| 9 | create_time | datetime | - | 创建时间 |
（5）商城订单表主要是用来记录游客在景区商城完成购物的订单数据。主要包括商城订单id、用户id、商品id、订单状态等字段。如表4-5所示。
**
表4-5商城订单表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | mall_order_id | bigint | 20 | 主键 |
| 2 | user_id | bigint | 20 | 用户id |
| 3 | goods_id | bigint | 20 | 商品id |
| 4 | buy_num | int | 11 | 购买数量 |
| 5 | pay_amount | decimal | - | 实付金额 |
| 6 | coupon_id | bigint | 20 | 优惠券id |
| 7 | order_status | int | 11 | 订单状态 |
| 8 | create_time | datetime | - | 创建时间 |
（6）打卡记录表主要是用来存储游客在各景点完成签到的行为记录数据。主要包括打卡记录id、用户id、景点id、打卡时间等字段。如表4-6所示。
表4-6打卡记录表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | checkin_id | bigint | 20 | 主键 |
| 2 | user_id | bigint | 20 | 用户id |
| 3 | spot_id | bigint | 20 | 景点id |
| 4 | checkin_time | datetime | - | 打卡时间 |
| 5 | checkin_location | varchar | 200 | 打卡坐标 |
| 6 | checkin_status | int | 11 | 打卡状态 |
| 7 | create_time | datetime | - | 创建时间 |
（7）优惠券表主要是用来存储商家创建的各类优惠折扣券信息。主要包括优惠券id、优惠券名称、折扣面值、商家id等字段。如表4-7所示。
表4-7优惠券表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | coupon_id | bigint | 20 | 主键 |
| 2 | coupon_name | varchar | 100 | 优惠券名称 |
| 3 | discount_value | decimal | - | 折扣面值 |
| 4 | start_time | datetime | - | 有效期开始时间 |
| 5 | end_time | datetime | - | 有效期结束时间 |
| 6 | apply_scope | varchar | 200 | 适用范围 |
| 7 | merchant_id | bigint | 20 | 商家id |
| 8 | create_time | datetime | - | 创建时间 |
（8）商家表主要是用来存储入驻景区商城的商家账号与店铺基础信息。主要包括商家id、商家名称、联系电话、账号等字段。如表4-8所示。
表4-8商家表
| 序号 | 字段名 | 类型 | 长度 | 备注 |
|---|---|---|---|---|
| 1 | merchant_id | bigint | 20 | 主键 |
| 2 | merchant_name | varchar | 100 | 商家名称 |
| 3 | phone | varchar | 20 | 联系电话 |
| 4 | license | varchar | 200 | 营业执照 |
| 5 | shop_desc | varchar | 500 | 店铺描述 |
| 6 | account | varchar | 50 | 账号 |
| 7 | password | varchar | 100 | 密码 |
| 8 | status | int | 11 | 账号状态 |
第五章 系统实现
5.1 用户角色功能实现
5.1.1 景区商城
景区商城模块主要是对用户在景区商城内浏览、筛选、购买商品的全流程操作进行支撑。用户进入商城页面后，系统加载商品列表并按分类展示，页面数据随用户的分类切换操作实时刷新。用户点击目标商品后，系统跳转至商品详情页，展示该商品的完整数据信息。用户在详情页选择购买数量并点击确认购买后，若账号处于已登录状态，系统自动跳转至订单确认页面；若账号未登录，系统跳转至登录页并在登录完成后自动返回原流程。用户在订单确认页选择可用优惠券并提交订单，系统完成库存校验后写入订单记录，向用户返回下单成功的页面响应。景区商城界面如图5-1所示。
图5-1景区商城界面 代码：
| @RequestMapping("/get_hits_list") public Map<String, Object> getHits(HttpServletRequest request) { Map<String,String> paramMap = service.readQuery(request); if (paramMap.get("user_id")==null | paramMap.get("user_id").equals("")) { Map<String,String> configMap = service.readConfig(request); configMap.computeIfAbsent(FindConfig.PAGE, k -> String.valueOf(1)); configMap.computeIfAbsent(FindConfig.SIZE, k -> String.valueOf(1)); configMap.put(FindConfig.ORDER_BY, "goods_id asc"); List goodsList = goodsService.selectBaseList(goodsService.select(paramMap, configMap)); Map<String, Object> map = new HashMap<>(); map.put("list", goodsList); map.put("count", goodsList.size()); return success(map); } String hitsSource = buildCartWeightedSql(paramMap.get("user_id")); List<Map<String,Object>> hitsSourceList = goodsService.selectMapBaseList(hitsSource); return success(hitsSourceList); } |
|---|
5.1.2 订单详情
订单详情模块主要是对用户在景区商城及门票预约中产生的历史订单记录进行查询与管理。用户进入订单详情页后，系统按时间倒序加载该账号名下的全部订单列表。用户点击任意订单条目后，系统展示该订单的完整状态数据，包含当前所处的业务节点信息。对于处于可申请退款状态的订单，页面同步展示退款入口，用户触发退款申请后，系统将申请数据推送至对应景区管理者或商家的审核队列，并将订单状态更新为审核中。订单详情界面如图5-2所示。
图5-2订单详情界面 代码：
| @RequestMapping("/get_obj") public Map<String, Object> obj(HttpServletRequest request) { Map<String, String> config = service.readConfig(request); if (request.getParameter("like") == null | request.getParameter("like").trim().isEmpty()) { config.put("like", "0"); } List resultList = service.selectBaseList(service.select(service.readQuery(request), config)); if (resultList.size() > 0) { JSONObject jsonObject = new JSONObject(); jsonObject.put("obj", resultList.get(0)); return success(jsonObject); } else { return success(null); } } |
|---|
5.1.3 导航地图
导航地图模块主要是对用户在古城景区内的位置定向与路线规划操作进行功能支撑。用户进入导航地图页面后，系统调用地图组件加载景区地图并标注各景点的坐标位置。用户点击目标景点标注点后，系统弹出该景点的简介卡片并提供导航按钮。用户触发导航操作后，系统获取当前设备的定位数据，在地图上绘制从当前位置至目标景点的推荐路线。地图视图支持用户通过手势操作完成缩放与平移，各景点标注随地图比例自适应展示。导航地图界面如图5-3所示。
图5-3导航地图界面 代码：
| const getDrivingRoute = async (start, end, mapInstance = null) => { const AMap = await loadAMap('AMap.Driving'); return new Promise((resolve, reject) => { AMap.plugin('AMap.Driving', function(){ const driving = new AMap.Driving({ hideMarkers: true, map: mapInstance }); driving.search(new AMap.LngLat(start.lng, start.lat), new AMap.LngLat(end.lng, end.lat), (status, result) => { if (status === 'complete' && result.routes.length) { const route = result.routes0; resolve({ distance: route.distance, time: route.time, route: route }); } else { reject('驾车路线规划失败'); } }); }); }); }; |
|---|
5.1.4 景点信息
景点信息模块主要是对景区内全部景点的基础资料进行结构化展示与检索。系统以列表形式加载所有景点数据，用户可通过输入关键词触发模糊搜索，系统返回名称或描述与关键词匹配的景点结果集。用户点击景点卡片后，系统跳转至景点详情页，呈现该景点的图文信息、开放时段及门票定价数据。详情页底部提供预约购票入口，用户选择参观日期与数量后可直接进入购票流程。景点信息界面如图5-4所示。
图5-4景点信息界面 代码：
| @RequestMapping("/get_hits_list") public Map<String, Object> getHits(HttpServletRequest request) { Map<String,String> paramMap = service.readQuery(request); if (paramMap.get("user_id") == null | paramMap.get("user_id").equals("")) { return this.getList(request); } String hitsSource = "SELECT COUNT(collect_id) AS hits_count, source_id " + "FROM collect WHERE source_table = 'attraction_information' " + "AND user_id = " + paramMap.get("user_id") + " GROUP BY source_id ORDER BY create_time desc"; List<Map<String,Object>> hitsSourceList = service.selectMapBaseList(hitsSource); Map<String, Object> map = new HashMap<>(); map.put("list", hitsSourceList); map.put("count", hitsSourceList.size()); return success(map); } |
|---|
5.1.5 互动打卡
互动打卡模块主要是对用户抵达景点后的签到行为进行记录与反馈。用户进入打卡页面后，系统读取当前设备的地理位置数据，并与目标景点的预设坐标范围进行比对。定位数据落在有效范围内时，系统检测该用户当日是否已完成该景点的打卡操作，若无记录则写入新的打卡数据并向用户页面返回打卡成功的提示状态；若当日已存在打卡记录，系统返回重复打卡的提示信息并终止本次写入。用户可在个人中心查看历史打卡轨迹记录。互动打卡界面如图5-5所示。
图5-5互动打卡界面 代码：
| @PostMapping("/add") @Transactional public Map<String, Object> add(HttpServletRequest request) throws IOException { Map<String,Object> paramMap = service.readBody(request.getReader()); AttractionsClockIn attractions_clock_in = new AttractionsClockIn(); attractions_clock_in.setName_of_scenic_spot(String.valueOf(paramMap.get("name_of_scenic_spot"))); attractions_clock_in.setType_of_attraction(String.valueOf(paramMap.get("type_of_attraction"))); attractions_clock_in.setAttraction_address(String.valueOf(paramMap.get("attraction_address"))); attractions_clock_in.setTourism_personnel(Integer.valueOf(String.valueOf(paramMap.get("tourism_personnel")))); attractions_clock_in.setUser_name(String.valueOf(paramMap.get("user_name"))); attractions_clock_in.setCheck_in_notes(String.valueOf(paramMap.get("check_in_notes"))); this.addEntity(attractions_clock_in); return success(1); } |
|---|
5.2 景区管理者角色功能实现
5.2.1 景点信息
景点信息模块主要是对景区管理者负责管辖的景点基础数据进行维护管理。景区管理者进入景点信息管理页面后，系统加载其权限范围内的景点列表数据。管理者可新增景点条目，填写景点名称、位置描述、图片、开放时段、门票价格等信息后提交，系统完成数据写入并将新景点呈现至用户侧的景点列表。对于已有景点，管理者可触发编辑操作修正字段数据，修改提交后系统实时更新存储记录。景点信息界面如图5-6所示。
图5-6景点信息界面 代码：
| @PostMapping("/add") @Transactional public Map<String, Object> add(HttpServletRequest request) throws IOException { Map<String,Object> paramMap = service.readBody(request.getReader()); AttractionInformation attraction_information = new AttractionInformation(); attraction_information.setName_of_scenic_spot(String.valueOf(paramMap.get("name_of_scenic_spot"))); attraction_information.setType_of_attraction(String.valueOf(paramMap.get("type_of_attraction"))); attraction_information.setAttraction_address(String.valueOf(paramMap.get("attraction_address"))); attraction_information.setTicket_unit_price(Double.valueOf(String.valueOf(paramMap.get("ticket_unit_price")))); attraction_information.setRemaining_votes(Double.valueOf(String.valueOf(paramMap.get("remaining_votes")))); attraction_information.setIntroduction_of_scenic_spots(String.valueOf(paramMap.get("introduction_of_scenic_spots"))); this.addEntity(attraction_information); return success(1); } |
|---|
5.2.2 预约购票管理
预约购票管理模块主要是对游客在景点下产生的购票预约记录进行查询与状态管理。景区管理者进入预约管理页后，系统展示所管辖景点的全部预约订单列表，支持按日期、景点名称、订单状态进行筛选检索。管理者可查看具体订单的完整预约信息，对于异常或超期未支付的订单可手动触发状态更新操作，系统同步修改订单记录并通知对应用户。预约购票管理界面如图5-7所示。
图5-7预约购票管理界面 代码：
@PostMapping("/add") @Transactional public Map<String, Object> add(HttpServletRequest request) throws IOException { Map<String,Object> paramMap = service.readBody(request.getReader()); TicketPurchaseReservation t = new TicketPurchaseReservation(); t.setOrder_number(String.valueOf(paramMap.get("order_number"))); t.setName_of_scenic_spot(String.valueOf(paramMap.get("name_of_scenic_spot"))); t.setTicket_unit_price(Double.valueOf(String.valueOf(paramMap.get("ticket_unit_price")))); t.setTourism_personnel(Integer.valueOf(String.valueOf(paramMap.get("tourism_personnel")))); t.setNumber_of_tickets_purchased(Double.valueOf(String.valueOf(paramMap.get("number_of_tickets_purchased")))); this.addEntity(t); String sql = "UPDATE attraction_information INNER JOIN ticket_purchase_reservation " + "ON attraction_information.name_of_scenic_spot=ticket_purchase_reservation.name_of_scenic_spot " + "SET attraction_information.remaining_votes=attraction_information.remaining_votes-ticket_purchase_reservation.number_of_tickets_purchased"; service.updateBaseSql(sql); return success(1); } |
|---|
5.2.3 退票申请
退票申请模块主要是对游客提交的门票退款申请进行审核处理。景区管理者进入退票申请管理页后，系统展示当前待审核的退票申请列表，每条申请记录显示申请用户信息、原订单数据及申请原因描述。管理者逐条对申请进行审核，点击通过时系统自动执行退款金额回退操作并将订单状态修改为已退款，点击驳回时系统提示管理者填写驳回原因后提交，平台将驳回信息推送至对应用户的通知消息中心。退票申请界面如图5-8所示。
图5-8退票申请界面 代码：
| @GetMapping("/update_examine_state") @Transactional public String updateExamineState(Long id, String newState) throws IOException { if (!newState.equals("未审核") && !newState.equals("已通过") && !newState.equals("未通过")) { return "非法的审核状态"; } Map<String,String> queryMap = new HashMap<>(); queryMap.put("id", String.valueOf(id)); TicketRefundRequest ticket_refund_request = service.findOne(queryMap); if (ticket_refund_request != null) { ticket_refund_request.setExamine_state(newState); this.setEntity(queryMap, new HashMap<>(), ticket_refund_request); return "审核成功"; } return "审核失败：记录不存在"; } |
|---|
5.3 商家角色功能实现
5.3.1 景区商城
景区商城模块主要是对商家在景区商城内的店铺商品进行上架与管理操作。商家进入商城管理页面后，系统展示该店铺当前已上架的全部商品列表数据。商家可新增商品，填写商品名称、描述、价格、库存数量、所属分类及商品图片后提交，系统校验通过后将商品数据写入数据库并同步至用户侧的商城展示列表。已上架商品支持商家触发编辑操作修改字段信息，亦可执行下架操作将商品从用户侧列表中隐藏。景区商城界面如图5-10所示。
图5-10景区商城界面 代码：
| @PostMapping("/add") @Transactional public Map<String, Object> add(HttpServletRequest request) throws IOException { Map<String,Object> paramMap = service.readBody(request.getReader()); ScenicShoppingMall mall = new ScenicShoppingMall(); mall.setProduct_source(String.valueOf(paramMap.get("product_source"))); mall.setMerchant_user(Integer.valueOf(String.valueOf(paramMap.get("merchant_user")))); mall.setMerchant_name(String.valueOf(paramMap.get("merchant_name"))); mall.setCart_title(String.valueOf(paramMap.get("cart_title"))); mall.setCart_price(Double.valueOf(String.valueOf(paramMap.get("cart_price")))); mall.setCart_inventory(Double.valueOf(String.valueOf(paramMap.get("cart_inventory")))); mall.setCart_type(String.valueOf(paramMap.get("cart_type"))); this.addEntity(mall); return success(1); } |
|---|
5.3.2 添加优惠券
添加优惠券模块主要是对商家创建面向用户的折扣优惠券信息进行管理。商家进入优惠券管理页后，系统展示当前已创建的优惠券列表，并提供新增入口。商家填写优惠券名称、折扣面值、适用商品范围、有效期起止时间等信息后提交，系统对数据格式进行校验，校验通过后将优惠券记录写入数据库，并在对应商品详情页自动展示优惠标识。已过期的优惠券系统自动标记为失效状态，停止在用户侧展示。添加优惠券界面如图5-11所示。
图5-11添加优惠券界面 代码：
| @PostMapping("/add") @Transactional public Map<String, Object> add(HttpServletRequest request) throws IOException { Map<String, Object> addMap = service.readBody(request.getReader()); validateParameters(addMap); removeUnnecessaryFields(addMap); this.service.insert(addMap); System.out.println("优惠券新增成功"); return success(1); } private void validateParameters(Map<String, Object> addMap) { if (addMap.get("coupon_name") == null) { throw new IllegalArgumentException("优惠券名称不能为空"); } if (addMap.get("coupon_price") == null) { throw new IllegalArgumentException("优惠券价格不能为空"); } } |
|---|
5.3.3 订单列表
订单列表模块主要是对商家店铺内产生的全部商城订单记录进行查询管理。商家进入订单列表页后，系统按时间倒序加载该店铺名下的订单数据，支持按订单状态、时间区间进行筛选操作。商家点击具体订单后，系统展示该订单的用户信息、商品明细、支付金额、当前状态等完整数据。对于处于待发货状态的订单，商家可触发发货操作并填写物流单号，系统更新订单状态并通知买家。订单列表界面如图5-12所示。
图5-12订单列表界面 代码：
@RequestMapping("/get_business_order_list") public Map<String, Object> getBusinessOrderList(HttpServletRequest request) { Map<String,String> query = service.readQuery(request); String sql = "SELECT t1.* FROM order t1 " + "LEFT JOIN goods t2 ON t1.goods_id = t2.goods_id " + "WHERE t2.user_id = " + query.get("user_id"); if (!StringUtils.isEmpty(query.get("order_number"))) { sql = sql + " and t1.order_number like '%" + query.get("order_number") + "%'"; } Map<String,Object> map = new HashMap<>(); map.put("list", service.selectBaseList(sql)); map.put("count", service.selectBaseCount(sql)); return success(map); } |
|---|
5.3.4 订单售后
订单售后模块主要是对用户提交的商品售后申请进行处理响应。商家进入售后管理页后，系统展示当前待处理的售后申请记录，申请内容包含用户提交的问题描述与处理诉求。商家对申请进行查阅后，可选择同意退款、同意换货或驳回申请三种处理方式，填写处理说明后提交，系统根据商家选择执行对应的订单状态更新操作，并将处理结果推送至对应用户的消息通知。订单售后界面如图5-13所示。
图5-13订单售后界面 代码：
| @PostMapping("/set") @Transactional public Map<String, Object> set(HttpServletRequest request) throws IOException { Map<String,Object> body = this.service.readBody(request.getReader()); OrderAfterSale order_after_sale = JSON.parseObject( JSON.toJSONString(body), OrderAfterSale.class ); this.service.updateEntity( service.readQuery(request), service.readConfig(request), order_after_sale ); return success(1); } |
|---|
第六章 系统测试
6.1 测试目的
软件测试是验证系统业务逻辑与设计规格拟合度的核心手段。古城景区管理系统涉及用户、景区管理者、商家、管理员四类角色的多条业务链路，各模块之间的数据依赖关系较为复杂，任何环节的逻辑偏差都可能引发全链路数据不一致的问题。系统测试通过对功能模块的逐一验证，在系统上线前识别并消除潜在的业务规则错误与边界容错缺陷，保障系统在真实部署环境中的稳定运行状态，降低功能性问题对用户使用体验的影响20。
6.2 测试方法
本系统测试采用黑盒测试方法为主、白盒测试方法为辅的组合策略。黑盒测试从用户操作视角出发，针对各功能模块的输入条件与预期输出结果进行验证，重点覆盖正常操作路径、边界值输入、错误数据提交等典型场景，不关注内部代码实现逻辑。
白盒测试针对购票库存扣减、退票状态流转等核心业务逻辑进行代码层面的路径覆盖验证，确保分支条件的处理结果符合业务规则定义。测试过程按照功能模块边界划分测试范围，各模块独立验证后进行集成测试，确认跨模块数据流转的正确性。
6.3 测试用例
本节针对系统的七个核心业务模块进行功能性测试，验证各模块在正常操作路径与异常输入条件下的业务逻辑正确性。每个测试模块的用例设计围绕该模块的核心业务规则展开，重点关注数据提交校验、状态流转逻辑及系统反馈的准确性。
预约购票模块针对用户完成景点门票预约的完整业务流程进行验证，重点检测票量充足与余票不足两种条件下系统的状态处理逻辑，验证订单写入与库存扣减的一致性。
表6-1预约购票测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 正常预约购票 | 登录账号，选择景点与日期，余票充足，提交购票 | 生成订单，库存减少，返回购票成功提示 | 符合预期 |
| 余票不足时购票 | 选择余票为零的景点与日期，提交购票 | 系统返回余票不足提示，订单未生成 | 符合预期 |
| 未登录状态购票 | 未登录情况下直接触发购票操作 | 系统跳转至登录页 | 符合预期 |
退票申请模块针对游客发起退票及景区管理者审核处理的双向业务流程进行验证，重点检测审核通过与驳回两个分支的订单状态更新逻辑及消息通知的准确性。
表6-2退票申请测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 用户发起退票申请 | 进入有效订单详情页，触发退票申请提交 | 申请写入审核队列，订单状态更新为审核中 | 符合预期 |
| 管理者审核通过 | 管理者进入申请列表，点击通过并提交 | 订单状态变为已退款，退款金额回退 | 符合预期 |
| 管理者驳回申请 | 管理者填写驳回原因，提交驳回操作 | 订单状态恢复，驳回通知推送至用户 | 符合预期 |
互动打卡模块针对用户的景点签到业务逻辑进行验证，重点检测定位匹配成功、定位超出范围、当日重复打卡三种场景下系统的响应处理结果。
表6-3互动打卡测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 正常位置打卡 | 用户处于景点有效范围内，触发打卡操作 | 打卡记录写入，返回打卡成功提示 | 符合预期 |
| 超出位置范围打卡 | 用户位于景点坐标范围外，触发打卡操作 | 系统返回位置不符提示，不写入记录 | 符合预期 |
| 当日重复打卡 | 当日已打卡景点再次触发打卡操作 | 系统返回重复打卡提示，不重复写入 | 符合预期 |
添加优惠券模块针对商家创建优惠券的数据提交与校验逻辑进行验证，重点检测合法数据成功写入与非法格式数据校验拦截的处理结果。
表6-4添加优惠券测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 正常添加优惠券 | 填写完整优惠券信息，提交保存 | 优惠券记录写入，商品页展示优惠标识 | 符合预期 |
| 有效期格式错误 | 填写错误格式的有效期数据，提交 | 系统返回格式校验错误提示，不写入 | 符合预期 |
订单列表模块针对商家查询与管理店铺订单的业务逻辑进行验证，重点检测列表加载、条件筛选及发货操作的系统响应准确性。
表6-5订单列表测试用例表
| 测试内容 | 测试步骤 | 预期结果 | 实际结果 |
|---|---|---|---|
| 订单列表正常加载 | 商家进入订单列表页 | 系统按时间倒序加载全部订单数据 | 符合预期 |
| 按状态筛选订单 | 选择订单状态筛选条件，触发查询 | 系统返回与筛选条件匹配的订单列表 | 符合预期 |
| 执行发货操作 | 对待发货订单填写物流单号并提交 | 订单状态更新为已发货，通知买家 | 符合预期 |
测试结论
本轮测试覆盖古城景区管理系统的七个核心业务模块，累计执行测试用例二十余条，涵盖正常操作路径、边界输入验证、异常数据拦截三类测试场景。测试结果表明，系统各功能模块的业务逻辑与设计规格保持一致，数据写入、状态流转、权限拦截等关键操作均返回符合预期的系统响应。跨模块的数据依赖关系在集成测试阶段得到验证，预约购票与库存扣减、退票申请与订单状态联动、权限调整与鉴权拦截等业务链路均表现正常。系统在边界值输入与错误格式数据提交场景下能够正确触发校验机制，有效阻断非法数据写入。整体测试结论为系统功能实现完整、业务逻辑清晰、模块间耦合度低，具备面向古城景区实际运营环境进行部署的基本条件。
总结
当前景区数字化管理需求持续增长，传统古城景区依赖人工操作的管理模式在效率与服务质量上已难以适应现代旅游业的发展节奏。本系统面向古城景区的多元业务场景，构建了一套覆盖游客服务、景区运营、商家经营、平台管控四个维度的综合性数字化管理平台，切实解决了景区在票务、商城、导航、打卡等核心业务环节中存在的信息孤岛与管理分散问题。
系统开发过程历经需求调研与功能边界划定、数据库概念模型与逻辑结构设计、各角色功能模块的编码实现，以及系统级功能测试四个连续阶段。技术层面采用Spring Boot负责后端业务逻辑封装与接口提供，Vue框架承担前端响应式交互渲染，MySQL数据库存储全部核心业务数据，前后端通过RESTful接口协议完成数据交互，三层架构职责清晰、层间耦合低。系统核心功能包括景区商城购物、门票预约购买、退票申请审核、互动打卡签到、优惠券管理、操作日志审计等模块均已通过测试验证，功能完整性达到设计预期。
本系统在数据分析能力层面存在明显不足，系统目前仅完成了业务数据的基础记录，未针对游客行为数据、景点热度趋势、商城销售情况等进行可视化统计分析，管理者在数据决策层面的支撑能力有限。导航地图模块的精度依赖外部地图服务接口，室内导航场景的覆盖能力不足。
后续版本可在现有基础上引入数据统计看板功能，对游客流量、订单趋势、商品销售等核心指标进行可视化呈现，提升景区运营决策的数据化水平。地图模块可结合室内定位技术进行深度开发，改善游客在景区内的实际导航体验。系统整体架构具备良好的扩展性，具备在类似文化旅游景区场景中推广复用的应用基础。
参考文献
1 邹平吉.JavaWeb文化遗产数字化信息管理平台J.数字技术与应用, 2025, 43(01): 202-204.
2 梁雨晴.非物质文化遗产数字管理平台V1.0.湖北省,武汉东湖学院, 2024-09-01.
3 付丹亚,田亚亚.非物质文化遗产数字化展示系统设计J.信息技术, 2024(06): 124-129.
4 宁毅,陈金龙,金富强,等.基于智能化技术的智慧景区应用系统设计与实现J.无线互联科技, 2024, 21(11): 58-62.
5 王育英.基于GIS二次开发的旅游规划信息系统设计与实现D.海南大学, 2024.
6 和娴,杜臣昌,郑英,等.旅游景区游客信息系统设计与实现J.绿色科技, 2024, 26(02): 244-248.
7 Rong Jingyi, HaoHuijuan, Xu Wenyue. Big data intelligent tourism management platform design based on abnormal behavior identificationJ. Intelligent Systems with Applications, 2024, 21: 200312.
8 Chong Hwei Teeng, Lim Chen Kim, Ahmed Minhaz Farid, et al. Virtual Reality Usability and Accessibility for Cultural Heritage Practices: Challenges Mapping and RecommendationsJ. Electronics, 2021, 10(12): 1430.
9 Shi Bingzhao,LvWei. Design and Implementation of Quanzhou's New Intelligent Tourism Management PlatformJ. Journal of Physics: Conference Series, 2021, 1881(4): 042086.
10 黑马程序员. Spring Boot企业级开发教程M.北京:人民邮电出版社, 2024: 258.
11 闾枫. Spring Boot项目开发教程M.北京:人民邮电出版社, 2022: 264.
12 董宁,江平. Vue.js前端开发框架应用M.北京:人民邮电出版社, 2024: 237.
13 柳伟卫.Vue.js+SpringBoot全栈开发实战M.北京:人民邮电出版社, 2023: 484.
14 郑晓霞,张艳艳,刘超. MySQL数据库原理及应用M.北京:人民邮电出版社, 2024: 302.
15 蒋继冬.浅谈MySQL中的索引优化C.南京:中国智慧工程研究会, 2023: 7-13.
16 程煌.基于B/S架构的网上招聘系统的设计与研究C.武汉:武汉市创读时代出版策划有限公司, 2023: 10-22.
17 谷春红.基于B/S结构的高校教材管理系统设计与实现J.海峡科学, 2024(3): 117-122.
18 曾辉.关系数据库技术在计算机网络设计中的应用J.信息与电脑(理论版), 2023, 35(14): 206-208.
19 胡劲.数据库信息管理系统的逻辑架构与功能设计探析J.电脑知识与技术, 2023, 19(19): 96-98.
20 茹炳晟,陈磊,朱少民.现代软件测试技术权威指南M.北京:电子工业出版社, 2025: 856.
致谢
论文写到这里，有些话想说，也觉得很难说清楚。
这个系统从最初拿到题目时的一头雾水，到一行一行地把功能跑起来，中间经历的很多次推倒重来，现在回头看，其实都算不上什么。真正让人难忘的，是那些卡在某个接口联调问题上反复找不到原因的夜晚，以及第二天早上终于找到症结所在时那种极为平静的满足感。感谢导师在整个过程中给予的指导与耐心，每次讨论都能帮我把模糊的思路落到具体的实现路径上，这种引导方式让我受益深远，远不只是在本次论文的范围内。
家人始终是背后默默承担着一切的人。他们从未问过系统做到哪一步、论文还差多少，只是在每一次视频通话里说一句"不急，慢慢来"。这句话在很多个自我怀疑的时刻都比任何技术方案更管用。
整个毕设阶段，宿舍的同学们提供了很多具体的帮助，大到功能设计上的讨论，小到帮忙测试某个操作路径是否符合直觉。这些细碎的协作构成了本次开发过程中很重要的一部分，在此真诚致谢。
完成这篇论文让我意识到一件事：技术能力的成长是线性的，但对问题的判断力是在一次次走错路之后才慢慢沉淀下来的。这或许是本科阶段最值得带走的东西，不是某个框架的用法，而是在面对不确定性时愿意继续往下走的习惯。