1. 项目画像：古城景区管理系统到底在管什么
1.1 为什么是“古城”景区，以及毕业设计的选题逻辑
先聊一个大实话：每年计算机毕业设计排行榜上，管理系统类是绝对的主力，而景区管理系统又是其中经久不衰的选题。但市面上大量类似题目都是“酒店管理系统”“图书馆管理系统”换个皮，数据表一改就完事。古城景区管理系统不一样，它有一个比较鲜明的业务背景——历史古城类景区往往存在多景点联动、门票分时段预约、游客流量管控、文化资源展示等复合需求，这决定了它不是一个简单的CRUD增删改查，而是带有真实业务逻辑的系统。
选这个题目的同学，通常有三个真实诉求：第一，技术栈要“主流”，Java后端加Vue前端在简历上说得出口；第二，业务复杂度要适中，既要能体现工作量，又不能做到一半做不下去；第三，素材要好看，古城景区的页面做出来天然有视觉优势，答辩时演示效果好。这个选题恰好三条都占。
从实际开发角度看，古城景区管理系统核心解决的是三个问题：游客怎么快速获取景区信息并按计划游览；景区运营方怎么管理景点、票务、公告和游客反馈；管理人员怎么通过数据了解景区运营状况。本质上，它是“面向游客的信息服务”和“面向运营者的管理工具”的结合体，比单纯的管理系统多了一层C端体验设计。
1.2 系统边界：做到了什么，没做什么
很多同学拿到题目喜欢“贪多”，恨不得把在线支付、AR导览、VR全景全部塞进去。但毕业设计的核心原则是“在一个清晰边界内把核心链路做扎实”。我见过太多案例，项目写了八千行代码，结果答辩时核心模块讲不清楚，代码被追问就慌。
合理的系统边界应该画在哪？我拆解一下：
第一层，游客端功能。包括景区介绍展示、景点列表与详情、门票在线预约、订单查询、游览攻略查看、留言评价。这个部分要做得“像产品”，界面要友好、交互要流畅。
第二层，管理端功能。包括景点信息维护、门票库存与价格管理、公告发布、订单审核与核销、用户管理、留言管理、数据统计。这部分要突出流程的完整性和数据的一致性。
第三层，公共基础能力。登录注册、权限控制、数据持久化、日志记录。这是所有管理系统的地基，不能漏，也不需要过度设计。
有意识地不做哪些功能？比如真实在线支付对接、多级分销、实时地图导航。支付接口涉及商户号和资质认证，个人毕设环境跑不通；实时导航需要第三方地图SDK，复杂度不可控。把这些内容放到“后续扩展方向”里讲，反而显得你有全局视野。
提示：在开题报告里明确画出系统边界，是一个加分操作。导师最怕的是“题目很大、实现很浅”，你主动把范围收窄，说明你对项目体量有清晰认知。
2. 技术选型与系统架构：Java + Vue 的双端协作
2.1 后端选型：为什么是 Spring Boot 而不是其他框架
“基于Java + Vue”这个标题直接把后端技术栈锁定了Java系。但Java后端有Spring MVC、Spring Boot、Spring Cloud等选型，毕业设计级别用Spring Boot是整个行业的主流共识。核心原因有三个：
第一，Spring Boot的自动配置机制极大减少了样板代码。传统的SSM框架需要写大量的XML配置文件，一个web.xml就能折腾半天，Spring Boot通过注解和自动配置，让开发者把精力放在业务代码上。以一个数据源配置为例，传统SSM要写dataSource、sqlSessionFactory、mapperScannerConfigurer三层配置，Spring Boot里一行spring.datasource.url就能解决。
第二，生态成熟度带来的问题解决方案丰富。无论是权限框架Spring Security还是MyBatis Plus持久层框架，都有大量现成代码和文档。毕业设计阶段遇到的90%的问题，在搜索社区都能找到解决方案，这很重要——你不是在解决前沿技术难题，而是在有限时间内完成一个完整项目。
第三，内嵌Tomcat意味着部署成本极低。一个java -jar命令就能启动整个后端服务，不用单独装Tomcat再配置数据源连接池的JNDI。对需要反复演示、可能换机器演示的毕设场景来说，这个优势是决定性的。
2.2 前端技术：Vue 带来的组件化开发体验
前端选Vue，核心原因是它的学习曲线在同量级框架里最平缓。如果你是第一次写前端项目，Vue的模板语法、响应式数据绑定、组件通信机制，基本两三天就能上手写页面。
具体到技术版本，建议选Vue 2 + Element UI的组合。我知道Vue 3已经是长期支持的主力版本，但在毕设语境下，Vue 2的资料量、现成组件库的稳定性、与大量教程的匹配度仍然是最高的，而且很多高校的课程体系还在讲Vue 2。当然，如果你对Composition API已经比较熟悉，选Vue 3加Element Plus也完全可行，只是遇到问题时能搜到的参考会少一些。
在项目结构上，我建议按模块组织Vue组件，而不是按页面平铺：
src/api：统一封装axios请求，所有接口调用集中管理，避免在页面里散落一堆this.$http.get。src/router：路由配置，使用路由守卫实现未登录跳转。src/store：Vuex或Pinia，用于保存用户登录态、全局信息。src/views：页面组件，按游客端/管理端分目录。src/components：可复用组件，比如轮播图、景点卡片、订单状态标签。
一个常见的误区是把所有逻辑都写在页面里。比如获取景点列表的请求，在页面A写了一次，在页面B又复制粘贴了一遍。正确做法是在api目录里定义getSpotList()函数，页面只负责调用。这样后续维护接口地址时，只需要改一处。
2.3 前后端分离的接口约定与数据交互
前后端分离架构下，接口约定是团队协作的“法律条文”。一个人做毕设时虽然不存在协作问题，但一份清晰的接口文档能让你自己的前端页面开发与后端接口开发解耦，不必等一个模块完全做完再测另一个。
我习惯的做法是先用文本工具把核心接口列出来，定义清楚请求方式、路径、参数、返回结构。返回结构统一封装一个Result对象：
public class Result<T> { private Integer code; // 状态码，200成功，400参数错误，401未登录，500服务器错误 private String message; // 提示信息 private T data; // 返回数据 }前端axios统一拦截这个结构，code不为200时直接弹出错误提示，页面里只需要处理成功分支。这个设计看似简单，但能避免大量重复的异常处理代码。
接口路径按资源命名，比如：
GET /api/spot/list：获取景点列表GET /api/spot/{id}：获取景点详情POST /api/order/create：创建订单GET /api/order/my：获取当前用户的订单列表POST /api/admin/login：管理员登录
这种RESTful风格的好处是，前端开发时能直观猜到接口语义，后端也能通过路径快速定位到对应的Controller方法。
3. 数据库设计：一张图看透古城景区的数据关系
3.1 核心业务表的拆解与字段规划
数据库设计是毕设答辩时导师最关注的部分之一，因为能从表设计看出你对业务的理解深度。古城景区管理系统核心需要六张业务表，外加三张基础表。我逐一说明设计思路。
用户表（user）：字段包括id、username、password（加密后）、nickname、phone、avatar、role、status、create_time。role区分游客和管理员，用int类型，0表示游客，1表示管理员。status字段是预留的用户禁用功能，防止出现被拉黑用户还能正常登录的尴尬情况。
景点表（spot）：这是景区系统的核心内容表。字段设计上要注意，除了id、name、description这些基础字段外，还要有cover_image（封面图）、images（详情图组）、category（分类，比如“古建筑”“文化展馆”“自然景观”）、open_time（开放时间）、ticket_price（门票价格）、stock（当日库存）、views_count（浏览量）、status（上下架状态）。
views_count这个字段容易被忽略，但对运营侧很有价值，也是后续做数据排序的基础数据。
门票订单表（order）：包含order_no（订单编号）、user_id、spot_id、visit_date（游览日期）、ticket_count（购票数量）、total_amount（总金额）、status（订单状态：待支付、已支付、已核销、已取消）、create_time。order_no用时间戳加随机数生成，避免使用自增id直接暴露订单量。
公告表（notice）：id、title、content、publish_time、status。用户端首页轮播公告栏展示的就是这张表的数据。
留言评论表（comment）：id、user_id、spot_id、content、rating（评分）、create_time。注意要建立user_id和spot_id的索引，因为页面查询留言时基本都按景点维度查。
操作日志表（log）：id、user_id、operation（操作内容）、create_time。这个表不是必需，但加上之后系统完整度明显提升，答辩时能讲出“可追溯性”这个亮点。
3.2 订单与库存的并发处理思路
毕设项目虽然不会遇到真实的高并发流量，但设计上仍然要考虑并发场景下的数据一致性。门票库存的扣减是典型问题：两个用户同时购买最后一张票，如果不加控制，会出现超卖。
最简单的方案是使用MySQL的行锁。在扣减库存的SQL中加上条件判断：
UPDATE spot SET stock = stock - #{count} WHERE id = #{spotId} AND stock >= #{count}通过stock >= #{count}条件，保证库存不足时更新影响行数为0，代码里判断受影响行数，为0则提示用户库存不足。这比先查询再更新安全得多，也不需要引入Redis分布式锁这种重量级方案。
订单状态流转也要在数据库层面做好约束。我的建议是：创建订单时状态默认为“待支付”，用户在演示环境直接点击“确认支付”完成支付动作，把状态改为“已支付”。这种简化处理绕开了真实支付网关，逻辑链路依然是完整的，而且你能在答辩时讲清楚“真实生产中这一步应接入支付回调”。
注意：在创建订单和扣减库存时，要加事务注解@Transactional。我曾经因为漏加事务，出现过订单创建成功但库存没扣减的情况，排查了很久才发现是两个独立提交导致的。
4. 核心模块的接口设计与代码实现
4.1 景点导览模块：前端展示与后端管理的配合
景点导览是游客进入系统后最先接触的模块，也是整个系统视觉层面的门面。前端页面设计上，我建议采用景区列表加筛选分类的组合：顶部是搜索框，下面按“全部”“古建筑”“文化展馆”“自然景观”分类展示景点卡片。每个卡片显示封面图、名称、简介和门票价格。
后端的列表接口要支持三个可选参数：keyword（模糊搜索）、category（分类筛选）、pageNum/pageSize（分页）。使用MyBatis Plus时，可以用LambdaQueryWrapper构造查询条件：
LambdaQueryWrapper<Spot> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(keyword), Spot::getName, keyword) .eq(StringUtils.isNotBlank(category), Spot::getCategory, category) .orderByDesc(Spot::getViewsCount); Page<Spot> page = spotMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);这里有个细节：StringUtils.isNotBlank(keyword)放在like条件第一参数位，表示当keyword为空时不拼接这个条件。这是MyBatis Plus的常见写法，能避免手动拼接SQL的繁杂。
景点详情页除了基本信息展示，还可以显示两个维度的内容：一个是攻略信息（也就是公告表里关联了景点的内容），一个是用户评论列表。这样景点详情页的信息密度就上来了，不再是干巴巴的介绍页，答辩演示时内容也更丰满。
4.2 门票预约与订单模块：核心业务链路的闭环
门票预约是整个系统业务逻辑最重的模块，值得花最多精力去打磨。游客端的操作链路是：选择景点 -> 选择游览日期 -> 填写购票数量 -> 提交订单 -> 确认支付 -> 查看订单状态。
日期选择这里有一个业务点——可预约日期应该从当前日期开始，未来7天内可选。这个限制在数据库层面体现在visit_date字段的校验上，后端接口里要检查传入的日期是否在有效范围内，不能只靠前端组件限制，否则通过接口直接调用就能绕过约束。
订单创建的核心代码如下：
@Transactional(rollbackFor = Exception.class) public Order createOrder(OrderCreateRequest request) { Spot spot = spotMapper.selectById(request.getSpotId()); if (spot == null || spot.getStatus() != 1) { throw new BusinessException("景点不存在或已下架"); } // 扣减库存，stock >= count 条件是防超卖的关键 int rows = spotMapper.deductStock(request.getSpotId(), request.getTicketCount()); if (rows == 0) { throw new BusinessException("余票不足"); } // 计算金额 BigDecimal totalAmount = spot.getTicketPrice() .multiply(new BigDecimal(request.getTicketCount())); // 生成订单号：时间戳 + 随机数 String orderNo = "GD" + System.currentTimeMillis() + String.format("%04d", new Random().nextInt(10000)); Order order = new Order(); order.setOrderNo(orderNo); order.setUserId(CurrentUserHolder.getUserId()); order.setSpotId(spot.getId()); order.setVisitDate(request.getVisitDate()); order.setTicketCount(request.getTicketCount()); order.setTotalAmount(totalAmount); order.setStatus(0); // 待支付 orderMapper.insert(order); return order; }代码里有两个容易被忽略但值得学习的点。第一是@Transactional(rollbackFor = Exception.class)，指定所有异常都回滚，不只是RuntimeException。第二是扣库存操作放在创建订单之前，保证“要么都成功、要么都失败”。
支付环节，我采用的是模拟支付页面——弹窗展示订单金额，点击确认后调用支付接口，将订单状态从待支付改为已支付。在真实项目中需要对接第三方支付，但毕设场景下模拟支付既规避了资质问题，又能完整展示业务流。
管理端的订单管理功能包括订单列表（支持按状态筛选、按订单号搜索）和核销操作。核销的设计逻辑是：景区工作人员扫描游客出示的订单二维码，将已支付状态的订单改为已核销，表示该票已入场使用。二维码的生成可以用前端插件完成，后台只需维护状态变更。
4.3 游客评论与留言管理：内容安全的实践
评论模块是游客与景点之间的内容连接。游客在景点详情页可以查看历史评论，也可以在游览完成后发布评价和评分。发布操作有两点校验：一是评论内容不能为空且长度限制在200字以内；二是需要登录状态，未登录用户点击发布时跳转登录页面。
这里有一个真实的坑要提醒大家：文本内容的合规性校验。如果允许游客无限制发布内容，可能出现广告或者不适宜内容。我采用的方案是把评论内容做一次敏感词过滤，用拦截器在接口调用前检查。毕设不要求覆盖所有敏感词，但至少要有这个意识，并且在答辩时可以把这个设计作为一个亮点来讲。
管理端对评论提供审核和删除能力。删除使用逻辑删除而不是物理删除，在表里加一个deleted字段，查询时过滤掉。为什么要逻辑删除？因为用户发布评论的时长、内容等数据本身是分析素材，物理删掉之后数据统计就不完整了。
4.4 数据统计看板：让管理端有“驾驶舱”感
很多管理系统做完就是“表格堆砌”，管理端就是几个列表页面。如果加一个数据统计看板，效果会提升一个档次。
统计看板需要展示的数据包括：今日订单数、今日销售额、总游客数、景点浏览量排行、近7日订单趋势。这些数据从已有表中聚合查询即可，不需要额外建表。
聚合查询用MyBatis Plus的selectMaps实现：
// 今日销售额 QueryWrapper<Order> wrapper = new QueryWrapper<>(); wrapper.select("IFNULL(SUM(total_amount), 0) as total") .eq("status", 1) .ge("create_time", DateUtil.beginOfDay(new Date())); List<Map<String, Object>> maps = orderMapper.selectMaps(wrapper);近7日订单趋势稍微麻烦一点，因为要处理日期连续性问题。我的做法是先用SQL查出近7天每天的订单数，然后在前端补齐没有订单的日期，补0展示。用ECharts画折线图，接口数据格式为[{date: "xx-xx", count: 12}, ...]，前端一次拿全量数据渲染。
看板页面还包含景点浏览量排行，这个用orderByDesc(Spot::getViewsCount)查前5条即可。整个看板不需要WebSocket推送实时数据，每次进入页面时请求接口获取最新数据就行，毕设场景足够用了。
5. 部署上线：从本地到服务器的完整路径
5.1 本地联调与开发环境搭建
开发环境搭建的顺序很关键，按以下顺序可以少踩坑：
第一步，安装JDK 8或JDK 11（版本不要太新，JDK 17在某些依赖上会有兼容问题，比如旧版Lombok不工作）。配好JAVA_HOME环境变量。
第二步，安装MySQL 5.7或8.0，导入项目提供的前端数据库脚本。注意数据库字符集要设置成utf8mb4，不然存储生僻字或特殊符号时会乱码。
第三步，安装Node.js 14或16版本。Vue项目需要npm安装依赖，Node版本太新可能与某些依赖不兼容。
第四步，后端启动。修改application.yml里的数据库连接信息（数据库地址、用户名、密码），直接运行主类。如果项目配置了Redis，还需要先在本地启动Redis服务。
第五步，前端启动。在Vue项目根目录执行npm install安装依赖，然后npm run serve启动开发服务器。默认端口8080，后端接口端口设为8081，前端通过proxy配置代理解决跨域问题。vue.config.js里的代理配置可以这样写：
devServer: { port: 8080, proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true } } }这里changeOrigin: true必须设置，否则后端接收到的请求头里Host还是8080，如果后端做了域名校验就会报错。
5.2 打包与服务器部署的注意事项
本地跑通之后，部署到服务器是毕设加分项。前端打包命令是npm run build，生成dist目录。后端打jar包，在pom.xml中配置好打包插件后执行mvn clean package。
在服务器上，我建议用Nginx做静态资源服务加反向代理。Nginx配置要点：
listen 80; server_name 你的域名或IP;
前端静态资源
location / { root /opt/guicheng/dist; index index.html; try_files $uri $uri/ /index.html; # 解决前端路由刷新404问题 }
后端接口反向代理
location /api/ { proxy_pass http://localhost:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }
try_files这一行必须写，否则在浏览器直接访问某个子路由（比如点击刷新按钮）时会因为找不到对应文件而报404。这个坑很多人踩过。
后端进程建议用nohup java -jar xxx.jar > log.log 2>&1 &启动，日志输出到文件方便排查问题。如果想要更完善的管理，可以用systemd配置开机自启，但这属于加分项，不强制。
注意：部署服务器时，数据库的初始数据一定要检查一遍。我在本地开发时插入的测试数据可能包含本地图片路径（如localhost:8081/upload/xxx.jpg），部署到服务器后这些图片路径全部失效。建议将图片改为相对路径，或者在上传图片时动态拼接服务器地址。
6. 毕业设计答辩常问问题与避坑经验
6.1 项目中的难点与亮点怎么讲
答辩时最忌讳照本宣科念PPT。整个项目中最值得展开讲的有四个点：库存防超卖设计、订单状态机流转、前后端分离的接口规范、数据统计看板的聚合查询。每个点都有一条清晰的技术链路，能展示你的思考深度。
比如讲库存防超卖，要按这个逻辑展开：用户提交订单时，前端先展示剩余库存，但前端展示的数据只做展示用，真正防止超卖的是后端的条件更新SQL，配合事务保证扣库存和建订单的一致性。进一步可以扩展：如果未来访问量增大，可以引入Redis预扣库存方案。这样从问题出发到分析再到实现，再到未来演进，逻辑闭环完整。
权限控制也是一个容易被追问的点。我的实现是后端用拦截器加JWT（JSON Web Token）验证，前端用路由守卫拦截未登录页面。完整流程是：用户登录成功后后端签发JWT，前端存储在localStorage中，每次请求在axios拦截器里添加Authorization头，后端拦截器校验Token并识别当前用户身份。管理员接口再额外校验角色的权限。这个方案能把登录、鉴权、会话保持三个知识点串起来讲。
6.2 答辩现场高频追问与应对思路
问题一：数据库为什么不用外键约束？这是一个很常见的追问。我的回答思路是：这道题的重点不在“用不用外键”，而在你是否理解两种方案的取舍。外键约束可以保证数据一致性，但会降低插入和更新性能，而且在分库分表场景下外键无法生效。现在主流开发更多在应用层保证业务逻辑的一致性。同时补充说明，在订单表的设计中，我加了索引来保证查询效率，并且在代码层校验用户和景点的存在性。
问题二：Sevlet容器为什么选Tomcat？因为Spring Boot内嵌了Tomcat作为默认容器，使用它不需要额外配置。如果你的项目用的外置Tomcat，就解释为了符合学校实验环境的部署要求。核心是要表明你理解Tomcat在Java Web运行中的作用是提供Servlet容器环境和HTTP服务支持。
问题三：项目的安全性考虑有哪些？从三个方面回答：密码加密存储（使用BCrypt加盐哈希）、JWT无状态认证、前端输入校验加后端二次校验。如果前面讲了敏感词过滤，这里也可以再提一次，展示系统设计中的合规意识。
问题四：为什么用MyBatis Plus而不是MyBatis？因为MyBatis Plus内置了常用CRUD方法和分页插件，开发效率更高。但它不是替代MyBatis，只是在其基础上做了增强，复杂的SQL还是要写XML。这个回答既说明了你了解工具的使用动机，又证明了你具备手写SQL的能力。
6.3 开发周期与时间分配经验
很多人问，这个项目从零开始做完需要多久。我的经验是：一个人全职做，三到四周比较合理。时间分配建议是：第一周做需求分析、数据库设计和后端基础框架搭建；第二周完成后端核心模块接口；第三周完成前端页面和接口联调；第四周用来测试、修Bug、准备答辩材料。
这个计划里最容易拖延的是联调阶段。前后端分离项目中，如果接口定义不清楚，联调时就会反复拉扯。解决办法是我之前在接口约定部分说的：动手开发前，先花半天时间把接口文档写清楚。这半天时间花得非常值。
时间不够的情况下，优先级怎么排？第一优先级是让核心业务流程跑通，即游客可以浏览景点、下单、支付、查看订单；第二优先级是管理端的订单和景点管理；第三优先级才是数据看板、评论、公告这些锦上添花的功能。很多同学把时间花在看板样式调整上，业务模块反而做得粗糙，答辩被追问一下就露馅了。
7. 从项目到经验的沉淀：后续还能怎么扩展
做完这个毕设拿到成绩只是第一步，我建议在这个骨架基础上做两次扩展，一次是为了“让简历更好看”，一次是为了“让自己真正理解工程化开发”。
简历方向的扩展，加一个Redis缓存层。把景点详情这类读多写少的接口加上缓存，用Spring Cache注解实现，代码改动量不大，但能在简历上明确写出“使用Redis做热点数据缓存”。再进一步，可以把库存扣减改造为基于Redis的预扣减，这就在项目里引入了分布式锁的概念。
工程化方向的扩展，引入单元测试。我在做完系统之后，给订单创建服务补了十几个测试用例，覆盖正常创建、库存不足、景点下架、重复提交等场景。补测试的过程让我重新审视了代码边界条件的处理，收获比写业务代码本身还要大。对于有面试打算的同学来说，“我给核心模块写了测试用例覆盖主要异常场景”这句话，比在简历上写“熟悉JUnit”有说服力得多。
另外一个值得尝试的方向是把前端工程化升级，用TypeScript重写Vue页面，或者把项目里的ECharts统计图表换成更丰富的可视化方案。这些改造不需要动后端，每天抽一两个小时做一点，一周内就能完成。
最后再分享一个我在实际开发中的体会：毕业设计是一个少有的、可以完整体验“从零开始做一个软件产品”的机会。需求分析、数据库设计、前后端编码、测试、部署、文档撰写，全链路走一遍，比刷一百道面试题更让人踏实。古城景区管理系统这个项目选题，恰好能支撑起这样一条完整的链路。做的时候多追问自己“为什么这样设计”，答辩的时候你自然会是一个有底气的人。
