每年到了三四月，就有一批学生抱着笔记本跑来找我：“学长，我的项目跑不起来了”“这个数据库怎么连不上”“答辩的时候老师问我的系统有什么亮点，我说不出来”。其实大多数问题的根源不是技术能力，而是选题太浅、设计太散。这次我想聊一个每年都能看到、也确实值得认真做的方向——基于 Spring Boot 的一站式智慧旅游系统。这个题目既有业务纵深，又有技术亮点，不管是用来做毕业设计还是想积累一个拿得出手的实战项目，都挺合适。
“一站式智慧旅游”听起来有点大，但拆开看其实是一个很完整的业务闭环：游客出行前的景点查询、攻略阅读、门票预订，出行中的线路规划、酒店推荐，出行后的评价分享，再加上管理端对景点、订单、用户、评论的运营维护。只要把这个链路梳理清楚，系统的功能模块、数据库结构、接口设计、核心算法都能自然地长出来，而不是靠堆功能凑字数。下面我按自己实际做这个项目时的思路，从选题逻辑、技术选型、数据库设计、核心功能实现到踩坑记录，完整复盘一遍。
1. 智慧旅游系统这个选题，值得做到什么深度
1.1 它比“旅游信息管理系统”强在哪
很多人的第一反应是做个“旅游管理系统”，进去就是景点表、用户表、增删改查五个页面。这种题目不是不能做，而是答辩的时候非常被动。老师问一句“你的系统解决了什么问题”，只能回答“方便管理员管理数据”，这显然支撑不起一篇像样的毕业设计论文。
智慧旅游系统的核心差异在于“智慧”两个字，它要求系统能够辅助用户做决策，而不是仅仅展示数据。具体来说，至少要有这几个能力：
- 多维度检索：按城市、分类、评分、价格区间、关键词组合筛选景点，而不是只做一个模糊搜索。
- 个性化推荐：根据用户的浏览记录、收藏行为，推荐他可能感兴趣的景点和玩法。
- 行程规划：用户选择多个景点后，系统结合地理位置、游玩时长、开放时间，生成一条合理的游览顺序。
- 完整的预订流程：门票库存、下单、支付状态流转、订单状态变更，这是电商类业务的核心逻辑。
- 评价与反馈：用户游玩后写评价、打分，评价会反向影响景点评分和后续推荐。
这些能力把“管理系统”提升成了“服务平台”，技术上对应的是检索算法、推荐算法、规划算法、订单并发控制等，每一个都能在答辩时变成实打实的亮点。
1.2 需求边界怎么划，哪些必须做，哪些果断砍掉
做毕设最怕的是贪大求全。我见过有人一上来就要做地图轨迹、VR全景、语音导览、在线支付对接，结果做了三个月，连基础流程都没跑通。合理的做法是画一条需求主线，把“必须做”和“可以砍”分开。
我最终定下的功能范围是：
- 游客端：注册登录、景点浏览与检索、景点详情（图片、介绍、评分、评论）、收藏景点、门票加入购物车并下单、我的订单、行程规划小工具、个人中心。
- 商家端（简化）：维护自己名下的景点和票型信息、查看订单、处理退款申请。
- 管理端：用户管理、景点审核、分类管理、订单管理、评论管理、数据统计看板。
砍掉的部分包括：真实的第三方支付对接（用模拟支付代替）、复杂的推荐算法（只做基于标签和行为的简化推荐）、地图轨迹绘制（用坐标点的展示代替）、多商家入驻（用一个商家模型统一处理）。这个范围对一个学生团队来说，工作量和难度刚好处于“跳一跳够得着”的区间。
2. 技术选型和系统骨架：Spring Boot 这套组合为什么够用又能讲出亮点
2.1 前后端分离是必然选择，但别把坑留到联调才发现
我采用的是 Spring Boot + Vue 的前后端分离架构。Spring Boot 负责纯 API 接口，前端使用 Vue 3 + Element Plus 搭建管理端和游客端界面。为什么坚持分离？第一，它符合当前主流开发模式，答辩时可以讲清楚前后端通过 JSON 交互、通过 Token 鉴权；第二，管理端和游客端界面风格完全不同，分成两个前端工程比硬塞在一个单体页面里干净得多。
但这里有个很多初学者容易踩的坑：前后端分离之后，跨域问题会在一开始就拦你一下。如果你先用服务端渲染的方式写了一半再改分离，后面会非常痛苦。所以项目一开始就要配置好跨域，把开发环境的代理或者后端的 CORS 策略处理好，否则每一项接口联调都会冒出一个跨域报错。我后面会专门讲这个问题。
2.2 后端工程结构怎么分，才能让老师一眼看出你有工程素养
工程结构我建议按业务模块分包，而不是按 controller、service、mapper 这种三层方式堆文件。按业务分包的好处是，每个功能的前后端改动入口都在同一块区域，定位问题快，答辩时讲起来也清晰。
我实际用的结构是这样的：
com.example.travel ├── common // 通用代码：统一返回体、异常处理、工具类 ├── config // 配置类：跨域、拦截器、Redis序列化、文件上传 ├── controller // 接口入口 ├── service // 业务逻辑 ├── mapper // 数据访问层 ├── entity // 实体类 ├── dto // 前端交互数据对象 ├── vo // 视图对象，聚合多表数据返回给前端 └── security // 登录鉴权相关：JWT工具、自定义过滤器统一返回体我定义成 Result 类，里面有 code、message、data 三个字段。code 为 200 表示成功，其他值对应业务错误和系统错误。这个看似简单的事情，能帮你省掉大量前后端联调时的沟通成本，也很容易在文档里写出“系统设计了统一的接口规范”这句话。
2.3 权限模型：三类角色如何用一套方案管起来
系统的角色有三类：游客、商家、管理员。我没有做复杂到不实用的 RBAC 权限模型，而是用了“角色字段 + 拦截器 + 注解”的轻量方案。
用户表中有一个 role 字段，登录成功后生成的 JWT 里带着用户 ID 和角色信息。后端写一个拦截器解析 Token，将用户信息放入 ThreadLocal；再配合自定义注解 @RequireRole，标注在需要特定角色的接口上。拦截器检测到访问者的角色不匹配，直接返回 403。
这套方案的好处是直观易懂，代码量不大，但又能体现你对权限控制的理解。Redis 在这里也有个用处：登录后把 Token 存一份到 Redis，设置过期时间，做“强制下线”和“续期”都方便，后面我会展开讲。
3. 数据库与接口设计：一张表一张表地搭出旅游业务的地基
3.1 核心表有哪些，字段和关系怎么定
数据库是整个系统的地基。我的库里有这些核心表：
user：用户表，字段包括用户名、密码（BCrypt加密）、昵称、头像、手机号、角色、状态。scenic：景点表，包含景点名称、所在城市、详细地址、经度、纬度、分类ID、封面图、简介、详细内容、开放时间、建议游玩时长、平均评分、浏览量、状态。category：景点分类表，比如自然风光、人文古迹、主题乐园。scenic_image：景点轮播图表，一个景点对多张图片。ticket：票型表，包含票型名称（成人票、学生票、老人票）、价格、库存、所属景点ID。strategy：攻略文章表，标题、封面、作者ID、内容、发布时间、浏览数。strategy_comment：攻略评论表，这条表解决的是用户对攻略内容的反馈场景。favorite：收藏表，用户ID、景点ID、收藏时间，联合唯一索引避免重复收藏。orders：订单主表，订单编号、用户ID、商家ID、总金额、支付方式、支付状态、订单状态、创建时间、支付时间、退款时间。order_detail：订单明细表，关联订单ID、票型ID、景点ID、单价、数量、小计金额。review：评价表，用户ID、景点ID、订单ID、评分、内容、图片、回复内容、创建时间。
表之间最核心的关系是：用户通过收藏表和景点的多对多关系体现偏好；订单表和订单明细表是一对多；评价表同时关联用户、景点和订单，保证“买过票才能评价”，避免刷评价。
3.2 订单和库存的设计，有一段不能省的心思
门票库存不能做成所有票型共用一个字段，必须每个票型独立库存。下单时要同时扣减多个票型的库存，这里就要用到事务。
库存扣减我用了乐观锁的思路，SQL 这样写：
UPDATE ticket SET stock = stock - 1 WHERE id = #{ticketId} AND stock > 0这条语句放在事务里，执行后判断影响行数。如果影响行数为 0，说明库存不足，直接抛异常回滚。这个方案在并发量不高、做一个毕业设计系统时完全够用，而且好讲：数据库层面的原子更新、CAS 思想、事务回滚。比引入 Redis 分布式锁简单得多，也避免了你解释不清楚“为什么要用这么重的方案”。
3.3 接口设计怎么定，前后端才能少扯皮
接口我统一用 RESTful 风格，资源用名词复数，动作用 HTTP 方法。比如：
GET /api/scenic：分页查询景点GET /api/scenic/{id}：景点详情POST /api/orders：创建订单PUT /api/orders/{id}/cancel：取消订单POST /api/reviews：发表评价
所有接口都套在统一的/api前缀下，管理端接口用/api/admin，商家端接口用/api/merchant，游客端用/api/portal。这样方便对接口做权限分组，也方便 Nginx 层面做转发规则，答辩的时候讲你的接口规划，比甩出一堆没有规律的路径要有说服力得多。
4. 核心功能实现：从游客点开页面到下单出票的完整链路
4.1 多条件检索：一个接口要经得起四种组合条件的考验
景点列表页是最容易被用户第一眼否掉的功能，也是后端体现水平的地方。我的检索接口同时支持关键词模糊匹配、分类筛选、城市筛选、价格区间、排序方式这几个条件。
查询用 MyBatis-Plus 的 LambdaQueryWrapper 动态拼接条件，但这里有个容易被忽略的点：价格排序不能直接用票型表里最低价来排，因为一个景点有多个票型。我的做法是先查出每个景点的最低票价，存到scenic表的min_price字段里，然后排序时直接用这个字段。这个冗余字段避免了复杂的子查询，也让列表页的加载速度快了不少。
检索性能方面，我用了两层 Redis 缓存。第一层是热门景点列表，十分钟刷新一次；第二层是分类加城市组合条件下的前二十条景点数据，五分钟刷新一次。效果非常明显，自己测试的时候从原来约 200ms 的响应降到了 30ms 以内。这个优化在答辩时可以拿出来讲，而且实现难度不大。
4.2 简化版推荐：不需要高大上，但要有逻辑
推荐功能做成什么样才能让老师点头？我的做法是“基于用户行为的标签偏好推荐”。
原理很简单：用户有收藏记录，收藏过的景点有分类标签，统计用户最偏好的分类；然后从这些分类下找出评分最高的几个景点，排除用户已经收藏过的，作为“为你推荐”的结果返回。如果用户没有收藏行为，就按全局评分倒序推荐热门景点。
这个算法虽然简单，但胜在能讲清楚三个层次：用户行为数据从哪来（收藏表）、偏好怎么建模（分类统计）、推荐结果怎么去重（排除已有收藏）。如果还想再深一层，还可以在用户点击景点详情时记录浏览历史，把浏览行为也纳入统计。这套逻辑放在毕设里是恰到好处的深度，不会让人觉得你在堆名词。
4.3 行程规划：贪心算法把多个景点串成一条合理路线
行程规划是游客端最有“智慧感”的功能。用户选择几个景点和游玩开始日期，系统根据每个景点的经纬度、建议游玩时长、开放时间，计算出一条起点到终点总路程最短、时间不冲突的游览顺序。
我实现的是简化版的贪心算法：从第一个景点开始，每次从未访问的景点中选一个“从当前位置过去距离最近”的景点作为下一站，不断重复，直到所有景点都被访问。然后检查整条路线中是否存在开放时间冲突：如果某景点的到达时间晚于它的停止入场时间，就提醒用户调整顺序或减少景点。
地理距离计算用的是 Haversine 公式，通过经纬度算两点球面距离：
private double getDistance(double lat1, double lng1, double lat2, double lng2) { double radLat1 = Math.toRadians(lat1); double radLat2 = Math.toRadians(lat2); double a = radLat1 - radLat2; double b = Math.toRadians(lng1) - Math.toRadians(lng2); double s = 2 * Math.asin(Math.sqrt(Math.pow(Math.sin(a / 2), 2) + Math.cos(radLat1) * Math.cos(radLat2) * Math.pow(Math.sin(b / 2), 2))); return s * 6371.393; }这种贪心策略虽然不保证全局最优，但在景点数量不超过十个时，直观效果已经很接近最优解了，而且代码量小、能讲清楚思路。如果你想让推荐结果更“像样”，可以在生成算路线后，按距离由短到长给每条路线打分，然后返回前三套路线供用户选择。
4.4 订单状态机：把逻辑锁死在正确的时间线上
订单系统如果没有状态机约束，代码会变成一团乱麻。
我定义的订单状态流转很简单：
待支付：用户下单后未支付，可取消，超时自动关闭。已支付：支付成功后进入，此时可以申请退款。已完成：游玩日期过后自动完成，此时可以评价。已取消：用户主动取消或超时未支付。已退款：商家同意退款后进入。
后端在取消和退款接口里都会做状态校验：只能从“待支付”取消，只能从“已支付”退款。状态流转的逻辑集中在 OrderService 里，不允许在 Controller 里直接修改订单状态字段。这样代码里不会出现“同一个订单被取消两次”以及“已退款订单还能评价”的奇葩状态。
订单编号的生成我用的是：日期前缀 + 随机数 + 用户 ID 尾号，避免暴露订单流水量，也保证了人工排查时的可读性。例如某个订单编号可以长这样：2025030812345678。
4.5 数据看板让管理端不再像“填空题”
管理端如果只有对各类数据的增删改查，就还是停留在“管理系统”的层面。为了让项目有一个亮眼的管理端首页，我加了一个数据看板：总用户数、今日订单数、总成交金额、景点浏览量 Top5、分类占比饼图、最近七天订单趋势曲线。
这些统计接口写起来并不难，就是几个分组聚合 SQL 组合：
SELECT category_id, COUNT(*) AS cnt FROM scenic GROUP BY category_id;然后把数据返回给前端，用图表组件渲染。这一页在最终展示时的视觉冲击力非常强，老师一打开管理端首页，就会觉得这个系统是完整的。
5. 开发过程中真正让人头大的几个问题，和处理它们的思路
5.1 本地图片上传成功，前端却永远访问不到
景点图片上传后，前端访问图片 URL 显示 404，这是我见过出现频率最高的初学者问题。原因很简单：Spring Boot 不会默认把本地磁盘目录映射成静态资源路径。
解决方法是写一个资源映射配置，把磁盘路径映射到 URL 路径：
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath + "/"); } }这样前端就可以通过https://你的域名/upload/xxx.jpg访问图片了。出于演示和调试的方便，我建议把上传路径做成配置项，而不是硬编码在代码里，因为不同电脑上绝对路径不同，不然每次换环境都要改代码。
5.2 库存超卖：并发下查了库存再扣减，一定会出问题
最初我也写过“先 select 查库存，再 update 扣减”的代码。本地一个人测试一点问题都没有，但用模拟并发工具压了一下，超卖就出现了。两个请求同时查到库存为 1，然后各自扣减，库存就变成了 -1。
解决办法就是我前面说过的，把“库存是否充足”的判断和“扣减库存”的操作合并成一条原子更新语句：
int rows = ticketMapper.updateStock(ticketId); if (rows == 0) { throw new BusinessException("库存不足，请更换票型"); }配合事务，库存不足直接抛异常，事务回滚，订单和明细都不会落库。这个案例特别适合写进论文的“系统难点与解决方案”章节，因为它是真实的并发场景，比背诵“什么是线程安全”要生动得多。
5.3 JWT 过期之后，前端页面还是“看起来登录着”
JWT 无状态本来是个优点，但用户登录状态下 Token 过期后，前端还在正常展示页面，只有点某个功能时才突然收到 401。体验非常奇怪。
我的解决方法是前后端配合：
前端在请求拦截器里统一处理 401 响应，收到 401 就清掉本地 Token，跳转回登录页，不把每个请求的错误都抛给用户。
后端额外提供一个刷新机制。JWT 的有效期设置短一些，比如 30 分钟，同时把 Token 记录在 Redis 中。前端发现 Token 快过期时，调用刷新接口，后端从 Redis 查到了对应记录，就签发新 Token；如果 Redis 里的记录也不存在了，就必须重新登录。这样用户连续操作不会突然被踢下线，同时无效 Token 也无法刷出新 Token，安全边界是清晰的。
5.4 跨域问题：前端明明是正常的，接口就是调用失败
前后端分离项目，如果你用前端工程跑在 5173 端口，后端跑在 8080 端口，那么浏览器发起的请求属于跨域请求，会先发一个 OPTIONS 预检请求。后端接口如果没有处理 OPTIONS 请求，前端就会看到“CORS error”或者“405 Method Not Allowed”。
后端的 CORS 配置要同时解决三件事：允许的来源、允许的请求头、允许的请求方法。并且注意一定要把allowCredentials设置为 true 时，allowedOrigins 不能写*，要写具体的前端地址，否则浏览器也会拦截。
如果使用类似 Nginx 之类的反向代理部署，可以统一配置/api前缀的转发，从根上避免跨域，这也是我最终采用的方案。但在本地联调阶段，后端配置 CORS 仍然是最省事的做法。
6. 文档、答辩与给别人调试项目的一些经验
6.1 系统设计文档怎么写，才算有料
很多同学的文档就是“数据库设计章节把建表语句复制一遍，功能设计章节把页面截图贴一遍”，这样写其实是给自己挖坑。论文和文档的作用是说明你的思考和实现逻辑，而不是把代码换个方式呈现。
我的建议是文档里重点写这几块：
- 需求分析：用户角色、用例图、业务流程，文字描述清楚每个角色能干什么。
- 系统设计：架构图、模块划分、数据库 ER 图、核心接口设计。
- 核心功能实现：把推荐算法、行程规划贪心算法、订单并发控制的“问题-方案-验证”讲清楚，最好配一段关键代码和一张测试数据对比。
- 系统测试：功能测试用例表格 + 简单的性能测试记录，证明你的系统不只是“能跑”。
6.2 演示时如果遇到现场翻车，怎么补救
答辩演示最容易翻车的环节是：网络断了、数据库没启动、Redis 没启动、演示数据不完整、页面白屏。我吃过的亏基本都在这几个地方。
我的经验是准备一个“演示模式”的数据脚本，里面预置了分类数据、十几个景点、多种票型、几个用户账号、若干订单和评价。演示之前先把脚本执行一遍，再依次启动 Redis、MySQL、后端、前端。
另外养成一个习惯：所有启动服务的命令写成脚本文件，一键启动。这样就算现场环境变了，也可以快速恢复。再准备几张截图作为备用，一旦系统现场崩了，直接切换到截图进行讲解，别在台上满头大汗地敲命令。
6.3 帮别人调这个项目的经验，也一并分享给你
后期帮一些学弟调试过类似的毕设项目，发现最常见的几类问题可以提前规避：
第一，数据库连接配置五花八门，有人把密码写错，有人没建库，有人没执行 SQL 脚本。拿到项目的第一步永远是检查配置文件里的数据库地址、用户名、密码、库名，再确认脚本是否执行成功。
第二，依赖版本不一致。Spring Boot 2.x 和 3.x 的很多配置写法不同，比如javax.servlet改成了jakarta.servlet。如果你用的是 3.x，就不要再沿用 2.x 的旧教程代码。复制别人代码时一定要先确认版本。
第三，前端依赖装不上或版本冲突。我发现很多问题来自npm install时产生的 lock 文件与项目不完全匹配，干脆删掉node_modules和package-lock.json之后重新安装，通常能解决奇怪的问题。
调试技能本身也很重要。我习惯在本地调试时用热部署和远程调试组合，后端改动后不用重启整个应用；前端用浏览器的网络面板看请求和响应体，能定位绝大多数联调问题。
最后还是分享一点个人体会
做完这个项目，我最大的感触是：真正拉开差距的往往不是某个高深的技术点，而是你有没有把整个业务闭环理顺。景点检索、行为推荐、行程规划、订单状态机、库存并发控制，单个拎出来都不算难，但串成一个完整系统后，它对“工程能力”的锻炼是非常全面的。
如果你准备用 Spring Boot 来做毕业设计或面试项目，智慧旅游这个方向我依然推荐。它的业务场景丰富、逻辑链条完整，默认就给论文和答辩提供了大量素材；开发时遇到的缓存、并发、权限、文件上传、前后端交互这些问题，也恰恰是实际生产中最高频的通用问题。做完一遍，你会发现自己对“一个系统是怎么从零到一长出来”这件事的理解，跟对着教程敲一遍完全是两个层次。
如果你手头已经有一个类似的半成品项目跑不起来，也别急着推倒重来。按我上面说的顺序排查一遍：数据库配置、依赖版本、缓存启动、跨域、图片路径、库存 SQL。我调试过不少项目，百分之八十的故障都集中在这些位置。把这些问题处理顺了，剩下的路自然就通了。
