最近不少准备做 Java Web 毕业设计的同学找我聊同一个困境网上各种 SpringBootVue 的旅游网站源码下载一抓一大把但要么缺 SQL 脚本、要么接口文档只有两页 PPT、要么代码结构乱到根本没法在答辩时讲清楚。这批人里有一部分是真心想做一个能跑通、能演示、能扛住评委提问的项目而不是只想交一份看起来差不多的东西。这次我围绕一套典型的 SpringBootVue 旅游网站平台项目来拆解从源码结构、SQL 脚本设计、接口文档规范到前端后端的协作思路把这类项目从能跑带到能讲明白、能改、能扩展的层面给准备拿它当毕设或者练手的人一条真正可以跟着走的路。先说说我对这种项目的总体判断旅游网站平台是所有 Java Web 毕设选题里功能边界最清晰的一种因为它既不涉及电商那种超复杂的订单状态机也不需要做社交产品那样高并发的实时消息体系它的核心就是资源展示信息检索订单流转这三个能力。这样的业务复杂度恰好卡在能体现完整开发链路和不会把自己埋进泥潭之间的黄金位置。你自己上手做完一遍能把 SpringBoot 的后端分层、Vue 的组件化开发、关系型数据库的表设计、RESTful 接口的规范全部串起来这正是评委想看到的东西。1. 为什么旅游网站适合做 SpringBootVue 毕设选型逻辑与功能边界1.1 前后端分离的架构选择不是跟风是必然趋势在拿到项目源码之后你首先要理解一个问题为什么现在的毕设几乎清一色是 SpringBoot 后端加 Vue 前端而不是以前那种传统的 JSPServlet 项目这背后不是单纯的技术潮流问题而是开发模式和团队协作方式的变化。SpringBoot 负责提供纯 RESTful APIVue 负责通过 Axios 这类 HTTP 客户端去消费这些 API两者之间只通过 JSON 数据交互前后端可以完全并行开发。理论上两个人在同一份接口文档的约束下前端不需要等后端写完 Controller后端也不需要等前端画好页面才启动联调。这种架构给你带来的最大好处是你可以在答辩时清晰地画出一条数据链路从用户在页面上点击一个按钮到 Vue 组件事件触发、Axios 发送请求、后端 Controller 接收参数、Service 处理业务逻辑、Mapper 操作数据库、再通过 JSON 原路返回、最终由 Vue 渲染到页面上。评委最喜欢问的就是这条链路因为它能一眼看出你是真的做过还是只会照着教程敲。而传统 JSP 项目里,页面和 Java 代码缠在一起,别说画链路了,自己调个 Bug 都会迷路。1.2 功能模块怎么划分才不会被评委追问到崩溃旅游网站最容易犯的错误是功能堆砌。很多参考源码里恨不得把订酒店、买机票、约导游、租车全塞进去看起来功能很多但实际上每个模块都做得很浅反而会在答辩时被评委抓住其中一个细节连续追问一追问就露馅。我建议把功能边界收敛成两条主线用户端和管理端。用户端围绕找景点、看详情、下订单、发评论这条完整用户体验链路管理端围绕维护数据、处理订单、管理内容这条运营链路,两头合起来正好闭环。完整的模块划分大概是这样端模块核心职责关键表用户端用户认证注册、登录、个人信息维护t_user用户端景点展示景点列表、详情、图片轮播、视频t_scenic用户端线路规划多日游线路、行程安排、价格展示t_route, t_route_item用户端订单系统选择日期和人数、生成订单、支付模拟t_order用户端互动功能评论、收藏、评分t_comment, t_favorite管理端景区管理景点的增删改查、上下架t_scenic管理端线路管理线路设计和价格调整t_route管理端订单处理查看订单、确认/取消订单t_order管理端数据概览访问量、订单量简单统计聚合查询这个划分方法的好处在于每个模块都能用一两句话说清楚它解决了什么问题不会出现那种一个页面管八件事的混沌状态。你在理解源码或者自己改代码的时候每动一个模块都能明确知道自己改的是哪一层、影响的是哪张表这种可控感在答辩前非常重要。1.3 这套源码的目录组织方式决定了它好不好扩展我压箱底的建议是拿到源码后先别急着跑起来先花一个小时把目录结构捋清楚。一个设计良好的 SpringBoot 项目,根目录下应该按职责而不是按技术栈划分包结构。比如你看到这样的包结构controller、service、mapper、entity、config、common、util比看到一堆散落的类文件要靠谱得多。common通常放统一返回体和异常处理config放跨域配置、拦截器配置、MyBatis-Plus 配置util放 JWT 工具类、日期工具类。前端 Vue 项目里views放页面组件router放路由表api目录里的每个 JS 文件对应后端一个模块的接口store放 Vuex 或 Pinia 的全局状态。这个组织方式本身就是一个潜在答辩亮点因为大部分人的项目目录是随便堆的你能把结构讲清楚评委的第一印象就不一样。前端侧的目录组织细节往往被非重点思考但这段恰恰容易出彩。你可以在前端api目录下看到类似scenic.js、order.js、user.js这种按业务模块拆分的接口定义文件每个文件导出一个或多个封装好的请求函数。这样前端调用接口时不用在页面组件里直接写一堆 Axios 裸请求而是统一调用函数。你讲解的时候就说我把接口层做了统一封装页面组件不直接关心请求细节只调用对应模块的接口函数这样后端接口 URL 变了我只需要改动 api 目录下的一个文件。这话一出口评委就知道你不是完全不懂工程化。2. 数据库设计这一环决定后续开发效率核心表结构与 SQL 脚本组织方案2.1 SQL 脚本不是建几张表这么简单它承载的是整个业务语义很多人打开 SQL 脚本只看建表语句忽视了脚本本身的分段组织方式。一套完整的旅游网站数据库脚本至少要包含四个部分建库和指定字符集、建表结构、初始化基础数据、生成若干条演示用的测试数据。分段的目的是为了让整个项目在任何一台干净的机器上都能一键复现,这个过程对应答辩时评委可能问的你这个系统怎么在三分钟内从一个空环境跑起来,你能够清晰回答先执行 init.sql 建库建表、再执行 data.sql 插入初始数据、最后启动 SpringBoot 和前端即可,这本身就是加分项。有一个细节我在指导别人时反复强调字符集必须用utf8mb4而不是utf8。原因很简单utf8在 MySQL 里最多存 3 字节的字符用户在评论里输入一个 Emoji 表情直接报错报错信息长得吓人其实就一个字符集问题。表情符号是 4 字节编码只有utf8mb4能存下。旅游网站的评论模块又是高频使用场景你总不能要求用户不发表情吧。这是一个小坑但它在实际运行里很容易出现而且一旦项目已经积累了几十张表再想改字符集迁数据会非常痛苦所以开局就锁死utf8mb4。核心表结构我大致说几个重点你可以对照着手里的 SQL 脚本看CREATE TABLE t_user ( id bigint NOT NULL AUTO_INCREMENT COMMENT 用户ID, username varchar(50) NOT NULL COMMENT 用户名, password varchar(100) NOT NULL COMMENT BCrypt加密后的密码, real_name varchar(50) DEFAULT NULL COMMENT 真实姓名, phone varchar(20) DEFAULT NULL COMMENT 手机号, avatar varchar(255) DEFAULT NULL COMMENT 头像URL, role tinyint DEFAULT 0 COMMENT 角色 0-普通用户 1-管理员, status tinyint DEFAULT 1 COMMENT 状态 0-禁用 1-正常, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;注意几个实战细节。第一密码字段长度留到 100因为 BCrypt 加密后的密码长度是固定的 60 个字符左右留 50 的话以后想换加密算法都换不了。第二用户名必须建唯一索引这是用户体系的底线约束。第三把update_time定义为ON UPDATE CURRENT_TIMESTAMP这样每次更新记录时时间戳自动维护不需要在 Java 代码里手动 set。订单表的并发设计就更讲究了。旅游网站和普通商品电商不太一样的地方是景区每天可预订的票数是有限的比如某个景点每天只放 500 张票用户下单时必须保证不会超卖。如果你的表设计里订单直接引用景区的总库存字段去减,那并发高点一定会出问题。更稳妥的做法是引入一个独立的库存或者版本号字段配合乐观锁来实现扣减。参考脚本里这一张表值得你多花时间看因为它是整个项目里最能体现业务深度的表。CREATE TABLE t_scenic ( id bigint NOT NULL AUTO_INCREMENT, name varchar(100) NOT NULL COMMENT 景点名称, summary varchar(500) DEFAULT NULL COMMENT 简介, detail text COMMENT 详细介绍, address varchar(200) DEFAULT NULL COMMENT 地址, cover_image varchar(255) DEFAULT NULL COMMENT 封面图, images varchar(1000) DEFAULT NULL COMMENT 轮播图多个用逗号分隔, open_time varchar(100) DEFAULT NULL COMMENT 开放时间, ticket_price decimal(10,2) DEFAULT 0.00 COMMENT 门票价格, daily_quota int DEFAULT 500 COMMENT 每日可售票数, version int DEFAULT 0 COMMENT 乐观锁版本号, status tinyint DEFAULT 1 COMMENT 上下架状态, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT景点表;远景图片用逗号分隔存在一个字段里听起来好像不规范但实际开发中你真要去建一张图片子表反而会把简单问题复杂化。景点图片是只读型数据变更频率极低,它的操作单元永远是整个景点的图片集合,用逗号分隔存储然后在后端拆分成数组返回完全够用且高效。数据库设计要权衡规范和实际场景不是越规范越好。2.2 测试数据要仿真别拿十条假数据糊弄评委SQL 脚本里初始数据这部分我见过太多项目只插个三五条记录,连图片 URL 都是随便写的xxx.jpg启动进去一看页面都在转圈。你试想一下这个场景答辩现场你打开前端首页景点列表空荡荡评委问为什么没有数据你说我还没来得及录入这种问答一次就足够毁掉整个答辩。正确做法是每个核心表至少插入 10 到 20 条有真实感的演示数据景点名称、简介、价格、地址都要看起来像真实业务里的样子图片 URL 要用可访问的在线图片地址这样你演示时页面才会丰满。还有一类数据是必须的但总被忽略就是管理员账号和你自己的测试用户账号。你可以把管理员的用户名密码写死在初始化脚本里同时在文档里标注管理员账号 admin密码 123456。别觉得这是小事很多人在答辩前找不到自己之前建的测试账号当场注册又暴露了密码规则逻辑非常尴尬。初始化脚本里预置好账号既方便你演示同时在回答评委系统里有没有预置数据这个问题时也能从容应对。模拟订单数据也建议准备几条涵盖待支付、已支付、已取消、已完成这些不同状态让订单列表页在演示时有内容可看。2.3 外键、索引与连表查询的取舍性能和安全之间的平衡旅游网站这类项目我的建议是物理外键尽量少用逻辑外键靠代码保证。也就是说表结构里不写FOREIGN KEY约束但是t_order里的user_id、scenic_id这类关联字段仍然要建普通索引。这样做的理由很简单物理外键会在每次插入、更新时触发额外的约束检查性能有损耗更重要的是在真实开发中很多业务需要先删主表再处理从表物理外键会让这种操作变得很痛苦。但字段上的普通索引一定要有因为所有订单列表查询都离不开WHERE user_id ?这种条件有索引和没索引在高数据量下差别巨大。初始化脚本里还应该考虑一个点给所有订单表按照创建时间建索引。管理端大概率要按时间范围去过滤订单没有这个索引,数据一多查询就会慢。旅游网站的订单量虽然不像电商那么大但是在本次项目演示中你不需要做到毫秒级,但至少不能出现明显的卡顿。这些索引字段在数据模型设计时就要前置思考等出现性能问题了再补索引已经属于应急处理的范畴了。3. SpringBoot 后端的骨架与原理解析认证、分层与业务实现3.1 统一返回体和全局异常处理是后端代码的第一张脸你打开后端的common包,大概率能看到ResultT这个类它定义了后端返回给前端的数据包装格式。我见过多种写法但核心结构基本一致状态码、提示信息、数据本体。一个通用返回体长这样public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }不要小看这个简单的类它解决了一个很重要的问题前端只需要统一解析code/message/data这个三层结构就能处理所有接口的返回而不需要对每个接口单独写一套判断逻辑。前端 Axios 封装里一般都会有响应拦截器只要code不是200就弹出message否则才把data返回给调用方。这套约定一旦建立后面写几百个接口都只需要遵循这一个模式。与之配套的还有全局异常处理器RestControllerAdvice作用是把代码里抛出的各种业务异常统一转换成Result格式返回。没有它的话后端一报错前端拿到的是乱七八糟的异常堆栈用户看到的就是一个白屏或者Internal Server Error。有了全局异常处理你可以把库存不足登录已过期没有权限这些情况都通过自定义异常抛出来前端收到后弹一条友好的提示。这一设计在整个后端工程里看起来不起眼但它把错误处理的复杂度降了一个量级。3.2 JWT 登录认证无状态会话是前后端分离项目的标配旅游网站项目和其他类型的系统一样登录认证的落地方式首选 JWT而不是传统的 Session。原因简单后端是纯 API,可能被小程序、网页、App 多个客户端共用Session 依赖服务端存储一旦水平扩展就会有会话同步问题而 JWT 是无状态的,token 里直接携带用户标识和过期时间服务端不保存任何会话信息校验只靠签名解密。对毕设项目而言无状态这一句话足够在答辩时解释为什么选 JWT 而不是 Session。JWT 的实际使用流程是这样的用户登录成功后后端生成一个 token里面封装用户 id、用户名、角色用密钥签名返回给前端前端把 token 存放在本地存储里每次 Axios 请求都在请求头里带上Authorization: Bearer token后端加一个拦截器对需要认证的接口校验 token 是否有效有效就从 token 里解析出当前用户 id 放入请求上下文。这里有一个特别容易被新手忽略的点密码存储绝对不能用明文也不能用简单的 MD5。明文密码一旦数据库泄露就是安全事故MD5 又很容易通过彩虹表反查出来。正确做法是用 BCrypt 加密Spring Security 自带的BCryptPasswordEncoder就能用它每次加密同一个密码得到的哈希值都不同天然抗彩虹表。注册时加密存库登录时用matches方法比对。在答辩时如果你能说出BCrypt 内置盐值同一密码多次加密结果不同这句话评委基本不会继续追这个问题。SpringBoot 项目里集成 JWT 的常见文件结构会是:一个JwtUtil工具类负责生成和解析 token一个拦截器实现HandlerInterceptor负责从请求头取 token 并校验一个WebMvcConfigurer实现类负责注册拦截器并配置哪些路径放行、哪些需要认证。注册和登录接口肯定放行前端要的静态资源也放行其余的接口统一走拦截器。实现思路的关键点 - token 里只放用户 id 和用户名不要放敏感信息 - 设置合理的过期时间比如 24 小时到期后前端跳回登录页 - 拦截器里对 token 解析失败的情况统一返回 401 - 前端 Axios 拦截到 401 后清除本地存储并跳转登录3.3 Service 层的事务与业务逻辑订单扣减的乐观锁实现后端的 Controller 层职责是接收参数、调用 Service、返回结果不应该写具体业务逻辑。真正复杂的业务都集中在 Service 层其中订单提交是整个项目里最适合深挖的点。一个完整的下单流程包含哪些操作查询景点当前剩余可订票数、判断预订人数是否超过余票、计算订单总价、生成订单记录、扣减余票数。这一串操作必须处于同一个数据库事务里任何一个步骤失败前面已执行的数据库操作都要回滚。SpringBoot 里实现事务非常简单在 Service 方法上加一个Transactional注解就完了但扣减余票的并发控制才是真正的难点。假设两个用户同时下单都查到剩余票数是 50各自扣减 1如果没有控制最终余票只少了 1 而不是 2这就是超卖。解决的常见方式是用乐观锁,在景点表加一个版本号字段更新时带上版本条件UPDATE t_scenic SET daily_quota daily_quota - #{count}, version version 1 WHERE id #{scenicId} AND version #{oldVersion} AND daily_quota #{count}这个 SQL 的含义是只有在版本号没变而且余票充足的情况下本次更新才会生效update影响行数为 1 就说明扣减成功为 0 就说明要么被别人改过了、要么票不够了此时直接抛异常让事务回滚。这个写法实际上是做高并发的人说的乐观锁思路,它不用锁表、不用synchronized更适合分布式场景。如果你能把这一套逻辑在答辩时讲清楚评委基本上可以确认你不是拿了个源码跑一跑就来答辩的你是真的理解和思考过的。同时你需要注意一个细节Transactional解决数据一致性,但它管不住逻辑异常如果你在事务方法内部用 try-catch 把异常吞掉了事务照样不会回滚。新手经常在这里踩坑测试的时候发现自己扣了余票但订单没生成成功其实就是异常被捕获后吞掉Spring 感知不到异常自然就不会回滚。这个经验写进你的笔记里调试时会少走很多弯路。3.4 文件上传与静态资源映射图片存储是前后端的同步难题旅游网站景点信息里有大量图片管理端上传景点图片用户端展示这些图片这里涉及一个经常出问题的地方。后端不能把图片存进数据库的 BLOB 字段那不是正确做法正确做法的落地选择通常是图片文件保存到服务器某个磁盘目录数据库只存图片的相对访问路径然后通过配置把图片目录映射成 URL 路径让前端可以直接访问。SpringBoot 项目里的实现方式很简单在application.yml里自定义一个上传路径然后在配置类中把物理路径映射为静态访问 URL。例如物理存储路径/www/upload/scenic/通过配置映射到 URL 路径/images/scenic/**那么前端访问http://服务器地址:8080/images/scenic/xxx.jpg就能直接看到图片了。这个方案比把图片塞到项目根目录下的static文件夹要更合理——因为项目打包成 jar 之后static目录是只读的运行时往里写文件不可行。还有一个很常见的坑前后端分离部署时后端跑在 8080前端跑在 80 或 5173 端口前端页面通过http://localhost:8080/images/...访问后端静态资源,这里又牵扯出跨域问题。正确的处理方式是在后端的跨域配置里开放需要的资源路径和请求方式同时静态资源映射本身也要正确配置,否则前端页面里的图片会一片空白。图片加载不出来是整个项目演示时最直观的翻车现场你应该提前把所有图片 URL 配置成可访问的相对路径然后用浏览器直接打开测一遍再启动前端集成验证一遍。4. Vue 前端从路由到渲染组件划分与数据协作方式4.1 前端路由设计页面结构与守卫逻辑Vue 项目里前端路由设计直接决定了系统的信息架构。旅游网站的前端路由通常分成两部分面向游客的展示端路由和管理员的后台管理端路由。游客端的典型页面路径有/home首页、/scenic景点列表、/scenic/:id景点详情、/order/confirm订单确认页、/user/center个人中心、/login登录注册。管理端一般放在/admin下面底部嵌套一堆二级页面比如/admin/scenic、/admin/order、/admin/user。路由守卫是前端最重要的安全措施之一。你要能读懂代码里router.beforeEach这一段逻辑每次路由跳转前先检查目标路径是否需要登录权限需要的话再看本地有没有 token没有 token 就跳转到登录页并且带上redirect参数登录成功后再跳回原页面。这里有一个细节很多人理解不到位前端路由守卫只是用户体验层面的保护真正的权限校验永远在后端接口前端守卫只是防止用户看到空白页或异常页。答的时候能把这一层说清楚说明你对前后端安全边界有正确的认知。4.2 Axios 封装与请求拦截让每个接口都自动携带 token你可以打开前端项目里的utils/request.js或者api/http.js这类文件它就是一个被统一封装的 Axios 实例。这个实例的作用很明确设置请求超时时间、设置请求拦截器、设置响应拦截器。请求拦截器在每次请求发出去之前从本地存储里取出 token加上请求头。响应拦截器在收到结果时统一判断 HTTP 状态码和后端业务状态码遇到 401 就清除本地登录信息并跳转登录页遇到其他错误就弹出错误提示。这个封装的意义在于你写任何页面组件时不需要关注 token 怎么传、错误怎么处理只需要调用封装好的函数比如import request from /utils/request export function getScenicList(params) { return request({ url: /api/scenic/list, method: get, params }) }调用getScenicList({ page: 1, size: 10 })拿到的就是已经剥离过的后端data数据页面里直接使用即可。这种封装在代码层面看不多但它体现了统一处理横切关注点的工程思想这个在回答你前端项目有什么亮点时是很好的素材。4.3 景区详情的视频点位与 m3u8 播放旅游场景里的一个出彩功能现在很多旅游网站平台都会在景点详情页放一段宣传视频或者慢直播流这个功能如果在你的项目里出现绝对是一个超出普通毕设水准的亮点。视频播放的技术选型要看你拿到的视频格式是什么。普通的 MP4 文件用原生video标签就能播放麻烦不大但如果你接的是网络摄像机生成的流媒体地址尤其是一些采用了 HLS 协议、地址后缀是.m3u8的视频源那就不是原生播放器能搞定的了。HLS 协议的原理是把一段视频切片成无数个小文件.m3u8本身只是一个索引文件里面记录的是每个切片的地址列表。由于浏览器原生不支持直接在video里播.m3u8地址需要借助hls.js这个库把切片拉下来解析后喂给video。前端实现逻辑大概是这样的先用Hls.isSupported()判断当前浏览器是否支持支持就创建 Hls 实例绑定到 video 元素上不支持就回退到原生播放能力。这个功能放在景点详情或景区直播里会非常有代入感而且代码量并不大却是实实在在的热门技术点。不过做这个功能时必须时刻注意跨域问题因为视频文件的响应和普通 JSON 接口一样受到 CORS 限制。如果你用的是第三方视频源远端服务没有开放跨域头那么就算前端代码写得再对也无法拉取切片。在实际项目里你可以选择放在后端做一层代理转发,或者在前端开发阶段用 Vite 的 proxy 配置做代理来解决。这个坑我在调试时踩过一开始一直怀疑是 hls.js 的参数没配对查了半天才发现是跨域把请求拦了。现在回想起来排查这一类问题最快的方法是直接打开浏览器 DevTools 的 Network 面板看报错是 CORS 的还是 404 的方向确认了再动手改代码。4.4 环境变量、代理与打包后的布局异常前端部署的三个老问题前端项目在开发环境跑得挺好一打包部署就出问题这是毕设答辩前最常见的技术事故。问题通常出在三个地方接口地址写死、路由模式、静态资源路径。开发时前端请求一个/api/xxx接口由 Vite 的 dev server 代理到http://localhost:8080这没问题但打包后部署到 Nginx/api的代理要重新在 Nginx 配置否则所有请求都会 404。处理方式是用环境变量区分开发环境和生产环境的VITE_API_BASE_URL在.env.development和.env.production里配置不同的接口前缀。路由模式的问题也很常见。如果你的 Vue 路由用了createWebHistoryHTML5 history 模式部署到 Nginx 后访问/scenic/1这样的路径刷新页面会 404,因为 Nginx 找不到对应的物理文件。解决办法是在 Nginx 配置里加入location / { try_files $uri $uri/ /index.html; }把所有非静态文件请求转发到index.html由前端路由接管。这也是为什么有些参考项目直接使用 hash 模式但为了 URL 美观用 history 模式再配 Nginx 回退是更专业的选择。还有一类打包后布局异常的问题,表现通常是 CSS 样式丢失、字体图标不显示、图片路径多了一层目录。这类问题多半是base或publicPath配置不对资源请求路径没有落在正确的静态文件根目录下。排查的时候看 DevTools 里的资源请求 URL,把它和线上文件实际路径对比一下就能快速定位是多了前缀还是少了前缀。5. 接口文档设计规范把约定的价值发挥到极致5.1 接口文档应该包含哪几块内容接口文档在这套源码里的价值经常被低估很多做毕设的人以为它是给评委看的花架子其实它更是前后端联调的施工图。一份合格的接口文档在每一个接口下面至少包含这些信息接口功能说明、请求方法、请求路径、请求参数表参数名、类型、是否必填、说明、请求示例、成功返回示例、错误码说明。不要以为有 Swagger 自动生成的在线文档就够了Swagger 能展示参数和返回结构但对业务含义和错误码约定解释得不充分。好的做法是手写一份 Markdown 接口文档同时接口代码里保留 Swagger 注解生成在线调试页两者互为补充。我见过很多接口文档只写获取景点列表 GET /api/scenic/list一行字然后就没了。这种文档根本没法用因为前端拿到手根本不知道要传什么参数、返回什么字段、字段名是什么类型。实际项目里前后端并行开发时接口文档是双方唯一的沟通契约文档不详细前端只能反复去问后端联调效率会直线下降。在你的毕设答辩中,完整详实的接口文档也给了评委一个明确信号这个项目是按真实工程规范管理的。5.2 核心接口定义示例接口协议如何组织才能一眼看懂下面是几个旅游平台里最有代表性的接口定义方式你可以直接对照这套设计去检查手头源码里的接口文档是否完整功能方法路径核心请求参数返回结果分页查询景点GET/api/scenic/listpage, size, keyword, status分页对象获取景点详情GET/api/scenic/{id}路径参数 id景点详情对象提交订单POST/api/order/submitscenicId, travelDate, count, contactPhone订单号取消订单PUT/api/order/cancel/{orderId}路径参数 orderId操作结果用户收藏景点POST/api/favorite/addscenicId操作结果管理员登录POST/api/admin/loginusername, passwordtoken返回结果部分建议统一用这样的一段 JSON 来展示{ code: 200, message: 操作成功, data: { orderId: 202501120001, amount: 360.00, status: 1 } }这里有一个很关键的设计约定订单号不要用数据库自增 id 直接返回给用户而是要有一套生成规则比如日期随机序列的格式。这样做的好处是订单号对外展示更专业同时避免暴露数据库里的真实记录数。5.3 接口文档的维护方式用工具把调试和数据 Mock 串起来我个人在实际项目中强烈推荐使用 Apifox 或者 Postman 来管理接口文档。这类工具支持从 Swagger 导入接口定义然后自动生成调试环境你可以在工具里为每个接口造好测试数据保存成一条条用例之后任何一次代码改动都能快速回归测一遍接口是否正常。对毕设场景来说最大的好处是,它可以把文档、调试、测试集中在一个界面,你答辩时直接在工具里调用接口返回数据,比你切到前端页面点点点更有工程师气质。更妙的是好的 API 工具还支持根据接口定义自动生成前端请求代码和后端 Controller 代码骨架这对于快速理解源码里的接口调用关系非常有帮助。我记得当时第一次用这类工具跑通接口导出到本地 生成前后端代码的时候对接口文档是前后端契约这句话的理解一下子从抽象变成具象了。如果你拿到手的一套源码是接口文档和代码对不上的那也别慌按工具里的接口调用记录去反向梳理往往比直接读源码走在理解的前面。5.4 错误码约定别让前端猜你的异常错误码是接口文档里最容易被忽略的部分。看到很多项目自定义返回结果里 code 只有 200 和 500,这其实是偷懒的做法。实际项目里应该针对常见业务场景设计一套有语义的错误码比如1001表示用户名或密码错误、1002表示 token 过期或无效、2001表示景点不存在或已下架、2002表示余票不足、3001表示订单状态不允许当前操作。有了这些错误码前端不只能弹一个提示框还能针对不同错误码做不同逻辑处理比如遇到1002就跳转登录页遇到2002就置灰提交按钮并提示用户降低预订数量。错误码表应该统一写进接口文档的开头或附录里前后端都遵守同一份约定。你在答辩前顺手把几个高频错误码记在脑子里评委问起你的系统怎么处理并发扣减余票失败这个问题时你可以直接说我会抛一个库存不足的业务异常,错误码是 2002,前端收到之后会做对应提示,这种回答非常有说服力。6. 部署、联调与答辩前自查把项目从能在我电脑上跑变成在任何环境都能跑6.1 从开发环境到生产环境的构建部署流程SpringBoot 后端在 IDEA 里启动只是第一步真正的项目交付要能打包部署。后端的打包命令用 Maven 的mvn clean package -DskipTests打出来的是一个可执行的 jar 包放到服务器上执行java -jar xxx.jar就能启动。这里要注意application.yml里数据库连接地址不要写成localhost应该换成数据库服务器的实际 IP,密码也不要写明文,可以用环境变量占位符比如${DB_PASSWORD}启动时通过--DB_PASSWORDxxx传入。这样你的项目配置就不会在传阅过程中泄露真实数据库密码。前端项目打包命令是npm run build产物是一个dist目录里面是纯静态文件。部署时的标准做法是用 Nginx 托管这个目录然后反向代理/api前缀的请求到后端的 SpringBoot 服务。关键的 Nginx 配置示例server { listen 80; server_name your_domain_or_ip; root /var/www/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这段配置解决了两个核心问题前端路由在 history 模式下的刷新 404以及后端接口的跨域代理。如果你不想在最外层用域名,直接配置成server_name _也是可以的取 IP 访问即可。部署完成后测试时记住只测前端页面能打开还不够一定要实测一遍完整的用户链路从注册到下单再到管理端处理订单中途任何一个接口 500 你都有时间提前修。6.2 跨域、端口、数据库连接部署期三大高频事故这三个问题几乎出现在每一套项目的部署阶段,提前总结一下能帮你快速定位。跨域问题的表现是浏览器控制台报CORS policy解决办法有两个维度后端加跨域配置类或者 Nginx 用反向代理让前端页面和 API 请求同源。后端加跨域配置时要特别注意allowedOriginPatterns和allowedOrigins的区别,前者允许携带通配符,适合有多个前端域名的情况后者严格要求精确匹配。SpringBoot 不同版本对这两种方法的默认行为还不太一样如果你用的是 SpringBoot 2.7建议用allowedOriginPatterns(*)否则可能遇到预检请求被拦截的诡异问题。端口占用是最没有技术含量但最高频的报错Port 8080 was already in use这句错误几乎每个 Java 开发者都见过。解决办法是netstat -ano | findstr 8080Windows或者lsof -i :8080Linux/Mac查端口被哪个进程占用然后杀掉对应进程或换一个端口。数据库连接失败就按这个顺序排查数据库服务是否启动、连接地址是否可达、用户名密码是否正确、数据库是否允许远程访问。时区问题在连接 MySQL 时也很典型经常报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized解决办法是在 JDBC 连接串里加上serverTimezoneAsia/Shanghai。6.3 答辩前必须自己问自己的十道题有了能跑的代码只是起点能撑住答辩提问才是最终目标。基于这套旅游网站项目,我列一下你拿源码后应该反复演练的问题提纲你的项目为什么选择前后端分离架构有什么好处你的数据库表设计是怎么考虑的核心表有哪些关系用户登录是怎么做的token 过期了前端怎么处理下单时怎么避免超卖乐观锁的实现细节是什么图片文件是怎么存储和访问的为什么不用 BLOB后端接口统一返回格式是什么异常怎么处理前端路由守卫解决了什么问题权限控制在前端还是后端部署时跨域怎么解决Nginx 代理的原则是什么项目里你觉得最出彩的功能是哪个为什么如果同时有 1 万人访问你的系统哪些地方会撑不住怎么优化最后一题特别值得好好准备。你不用真的做一套高并发架构但至少能说出来热点数据可以加 Redis 缓存搜索可以上 Elasticsearch图片可以放 CDN数据库可以做读写分离这些方向性的解决方案。评委要听的是你有没有工程扩展意识而不是要求一个毕设真的扛住 1 万并发。6.4 源码二次开发时的心态建议不是看懂而是能改最后说我个人的真实体会。很多人拿到一套完整的 SpringBootVue 项目源码第一反应是跑起来看看,跑通了就感觉自己已经会了。但你在答辩前如果只做到这一步评委随便改一个需求你就懵。比如评委说如果门票价格要支持浮动比如节假日涨价 20%你觉得要改哪些地方这个问题的本质是考你对数据模型、价格字段和订单价格快照的理解。如果你完整读过了订单表和景点表你会想到在订单表里冗余一个下单时的价格快照字段这样即使以后景点价格调整历史订单的价格也不会变同时景点表需要一个price与一个可选的节假日价格配置前端提交订单时展示的是实时价格后端算总价时用当前价格,一旦下单就冻结快照。我把这个思路写在这里也是想说明同一个点源码是很好的学习材料但学习的终点不是把代码跑起来而是把每个设计决策背后的为什么都挖出来转换成自己能表达的工程判断。当你真正做到这一步时答辩更像是在分享自己实际做过的一个项目而不是在背一份别人写的代码。我坚持认为一份附带 SQL 脚本和接口文档的完整源码价值远远超过代码本身它是一套已经被验证过的工程决策集。你在学习它的时候多问几个为什么这里要这么设计多尝试着改一改其中一个功能这套源码带给你的成长会远超把它跑通这一个动作。
SpringBoot+Vue旅游网站毕设全解析：从源码到答辩
最近不少准备做 Java Web 毕业设计的同学找我聊同一个困境网上各种 SpringBootVue 的旅游网站源码下载一抓一大把但要么缺 SQL 脚本、要么接口文档只有两页 PPT、要么代码结构乱到根本没法在答辩时讲清楚。这批人里有一部分是真心想做一个能跑通、能演示、能扛住评委提问的项目而不是只想交一份看起来差不多的东西。这次我围绕一套典型的 SpringBootVue 旅游网站平台项目来拆解从源码结构、SQL 脚本设计、接口文档规范到前端后端的协作思路把这类项目从能跑带到能讲明白、能改、能扩展的层面给准备拿它当毕设或者练手的人一条真正可以跟着走的路。先说说我对这种项目的总体判断旅游网站平台是所有 Java Web 毕设选题里功能边界最清晰的一种因为它既不涉及电商那种超复杂的订单状态机也不需要做社交产品那样高并发的实时消息体系它的核心就是资源展示信息检索订单流转这三个能力。这样的业务复杂度恰好卡在能体现完整开发链路和不会把自己埋进泥潭之间的黄金位置。你自己上手做完一遍能把 SpringBoot 的后端分层、Vue 的组件化开发、关系型数据库的表设计、RESTful 接口的规范全部串起来这正是评委想看到的东西。1. 为什么旅游网站适合做 SpringBootVue 毕设选型逻辑与功能边界1.1 前后端分离的架构选择不是跟风是必然趋势在拿到项目源码之后你首先要理解一个问题为什么现在的毕设几乎清一色是 SpringBoot 后端加 Vue 前端而不是以前那种传统的 JSPServlet 项目这背后不是单纯的技术潮流问题而是开发模式和团队协作方式的变化。SpringBoot 负责提供纯 RESTful APIVue 负责通过 Axios 这类 HTTP 客户端去消费这些 API两者之间只通过 JSON 数据交互前后端可以完全并行开发。理论上两个人在同一份接口文档的约束下前端不需要等后端写完 Controller后端也不需要等前端画好页面才启动联调。这种架构给你带来的最大好处是你可以在答辩时清晰地画出一条数据链路从用户在页面上点击一个按钮到 Vue 组件事件触发、Axios 发送请求、后端 Controller 接收参数、Service 处理业务逻辑、Mapper 操作数据库、再通过 JSON 原路返回、最终由 Vue 渲染到页面上。评委最喜欢问的就是这条链路因为它能一眼看出你是真的做过还是只会照着教程敲。而传统 JSP 项目里,页面和 Java 代码缠在一起,别说画链路了,自己调个 Bug 都会迷路。1.2 功能模块怎么划分才不会被评委追问到崩溃旅游网站最容易犯的错误是功能堆砌。很多参考源码里恨不得把订酒店、买机票、约导游、租车全塞进去看起来功能很多但实际上每个模块都做得很浅反而会在答辩时被评委抓住其中一个细节连续追问一追问就露馅。我建议把功能边界收敛成两条主线用户端和管理端。用户端围绕找景点、看详情、下订单、发评论这条完整用户体验链路管理端围绕维护数据、处理订单、管理内容这条运营链路,两头合起来正好闭环。完整的模块划分大概是这样端模块核心职责关键表用户端用户认证注册、登录、个人信息维护t_user用户端景点展示景点列表、详情、图片轮播、视频t_scenic用户端线路规划多日游线路、行程安排、价格展示t_route, t_route_item用户端订单系统选择日期和人数、生成订单、支付模拟t_order用户端互动功能评论、收藏、评分t_comment, t_favorite管理端景区管理景点的增删改查、上下架t_scenic管理端线路管理线路设计和价格调整t_route管理端订单处理查看订单、确认/取消订单t_order管理端数据概览访问量、订单量简单统计聚合查询这个划分方法的好处在于每个模块都能用一两句话说清楚它解决了什么问题不会出现那种一个页面管八件事的混沌状态。你在理解源码或者自己改代码的时候每动一个模块都能明确知道自己改的是哪一层、影响的是哪张表这种可控感在答辩前非常重要。1.3 这套源码的目录组织方式决定了它好不好扩展我压箱底的建议是拿到源码后先别急着跑起来先花一个小时把目录结构捋清楚。一个设计良好的 SpringBoot 项目,根目录下应该按职责而不是按技术栈划分包结构。比如你看到这样的包结构controller、service、mapper、entity、config、common、util比看到一堆散落的类文件要靠谱得多。common通常放统一返回体和异常处理config放跨域配置、拦截器配置、MyBatis-Plus 配置util放 JWT 工具类、日期工具类。前端 Vue 项目里views放页面组件router放路由表api目录里的每个 JS 文件对应后端一个模块的接口store放 Vuex 或 Pinia 的全局状态。这个组织方式本身就是一个潜在答辩亮点因为大部分人的项目目录是随便堆的你能把结构讲清楚评委的第一印象就不一样。前端侧的目录组织细节往往被非重点思考但这段恰恰容易出彩。你可以在前端api目录下看到类似scenic.js、order.js、user.js这种按业务模块拆分的接口定义文件每个文件导出一个或多个封装好的请求函数。这样前端调用接口时不用在页面组件里直接写一堆 Axios 裸请求而是统一调用函数。你讲解的时候就说我把接口层做了统一封装页面组件不直接关心请求细节只调用对应模块的接口函数这样后端接口 URL 变了我只需要改动 api 目录下的一个文件。这话一出口评委就知道你不是完全不懂工程化。2. 数据库设计这一环决定后续开发效率核心表结构与 SQL 脚本组织方案2.1 SQL 脚本不是建几张表这么简单它承载的是整个业务语义很多人打开 SQL 脚本只看建表语句忽视了脚本本身的分段组织方式。一套完整的旅游网站数据库脚本至少要包含四个部分建库和指定字符集、建表结构、初始化基础数据、生成若干条演示用的测试数据。分段的目的是为了让整个项目在任何一台干净的机器上都能一键复现,这个过程对应答辩时评委可能问的你这个系统怎么在三分钟内从一个空环境跑起来,你能够清晰回答先执行 init.sql 建库建表、再执行 data.sql 插入初始数据、最后启动 SpringBoot 和前端即可,这本身就是加分项。有一个细节我在指导别人时反复强调字符集必须用utf8mb4而不是utf8。原因很简单utf8在 MySQL 里最多存 3 字节的字符用户在评论里输入一个 Emoji 表情直接报错报错信息长得吓人其实就一个字符集问题。表情符号是 4 字节编码只有utf8mb4能存下。旅游网站的评论模块又是高频使用场景你总不能要求用户不发表情吧。这是一个小坑但它在实际运行里很容易出现而且一旦项目已经积累了几十张表再想改字符集迁数据会非常痛苦所以开局就锁死utf8mb4。核心表结构我大致说几个重点你可以对照着手里的 SQL 脚本看CREATE TABLE t_user ( id bigint NOT NULL AUTO_INCREMENT COMMENT 用户ID, username varchar(50) NOT NULL COMMENT 用户名, password varchar(100) NOT NULL COMMENT BCrypt加密后的密码, real_name varchar(50) DEFAULT NULL COMMENT 真实姓名, phone varchar(20) DEFAULT NULL COMMENT 手机号, avatar varchar(255) DEFAULT NULL COMMENT 头像URL, role tinyint DEFAULT 0 COMMENT 角色 0-普通用户 1-管理员, status tinyint DEFAULT 1 COMMENT 状态 0-禁用 1-正常, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;注意几个实战细节。第一密码字段长度留到 100因为 BCrypt 加密后的密码长度是固定的 60 个字符左右留 50 的话以后想换加密算法都换不了。第二用户名必须建唯一索引这是用户体系的底线约束。第三把update_time定义为ON UPDATE CURRENT_TIMESTAMP这样每次更新记录时时间戳自动维护不需要在 Java 代码里手动 set。订单表的并发设计就更讲究了。旅游网站和普通商品电商不太一样的地方是景区每天可预订的票数是有限的比如某个景点每天只放 500 张票用户下单时必须保证不会超卖。如果你的表设计里订单直接引用景区的总库存字段去减,那并发高点一定会出问题。更稳妥的做法是引入一个独立的库存或者版本号字段配合乐观锁来实现扣减。参考脚本里这一张表值得你多花时间看因为它是整个项目里最能体现业务深度的表。CREATE TABLE t_scenic ( id bigint NOT NULL AUTO_INCREMENT, name varchar(100) NOT NULL COMMENT 景点名称, summary varchar(500) DEFAULT NULL COMMENT 简介, detail text COMMENT 详细介绍, address varchar(200) DEFAULT NULL COMMENT 地址, cover_image varchar(255) DEFAULT NULL COMMENT 封面图, images varchar(1000) DEFAULT NULL COMMENT 轮播图多个用逗号分隔, open_time varchar(100) DEFAULT NULL COMMENT 开放时间, ticket_price decimal(10,2) DEFAULT 0.00 COMMENT 门票价格, daily_quota int DEFAULT 500 COMMENT 每日可售票数, version int DEFAULT 0 COMMENT 乐观锁版本号, status tinyint DEFAULT 1 COMMENT 上下架状态, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT景点表;远景图片用逗号分隔存在一个字段里听起来好像不规范但实际开发中你真要去建一张图片子表反而会把简单问题复杂化。景点图片是只读型数据变更频率极低,它的操作单元永远是整个景点的图片集合,用逗号分隔存储然后在后端拆分成数组返回完全够用且高效。数据库设计要权衡规范和实际场景不是越规范越好。2.2 测试数据要仿真别拿十条假数据糊弄评委SQL 脚本里初始数据这部分我见过太多项目只插个三五条记录,连图片 URL 都是随便写的xxx.jpg启动进去一看页面都在转圈。你试想一下这个场景答辩现场你打开前端首页景点列表空荡荡评委问为什么没有数据你说我还没来得及录入这种问答一次就足够毁掉整个答辩。正确做法是每个核心表至少插入 10 到 20 条有真实感的演示数据景点名称、简介、价格、地址都要看起来像真实业务里的样子图片 URL 要用可访问的在线图片地址这样你演示时页面才会丰满。还有一类数据是必须的但总被忽略就是管理员账号和你自己的测试用户账号。你可以把管理员的用户名密码写死在初始化脚本里同时在文档里标注管理员账号 admin密码 123456。别觉得这是小事很多人在答辩前找不到自己之前建的测试账号当场注册又暴露了密码规则逻辑非常尴尬。初始化脚本里预置好账号既方便你演示同时在回答评委系统里有没有预置数据这个问题时也能从容应对。模拟订单数据也建议准备几条涵盖待支付、已支付、已取消、已完成这些不同状态让订单列表页在演示时有内容可看。2.3 外键、索引与连表查询的取舍性能和安全之间的平衡旅游网站这类项目我的建议是物理外键尽量少用逻辑外键靠代码保证。也就是说表结构里不写FOREIGN KEY约束但是t_order里的user_id、scenic_id这类关联字段仍然要建普通索引。这样做的理由很简单物理外键会在每次插入、更新时触发额外的约束检查性能有损耗更重要的是在真实开发中很多业务需要先删主表再处理从表物理外键会让这种操作变得很痛苦。但字段上的普通索引一定要有因为所有订单列表查询都离不开WHERE user_id ?这种条件有索引和没索引在高数据量下差别巨大。初始化脚本里还应该考虑一个点给所有订单表按照创建时间建索引。管理端大概率要按时间范围去过滤订单没有这个索引,数据一多查询就会慢。旅游网站的订单量虽然不像电商那么大但是在本次项目演示中你不需要做到毫秒级,但至少不能出现明显的卡顿。这些索引字段在数据模型设计时就要前置思考等出现性能问题了再补索引已经属于应急处理的范畴了。3. SpringBoot 后端的骨架与原理解析认证、分层与业务实现3.1 统一返回体和全局异常处理是后端代码的第一张脸你打开后端的common包,大概率能看到ResultT这个类它定义了后端返回给前端的数据包装格式。我见过多种写法但核心结构基本一致状态码、提示信息、数据本体。一个通用返回体长这样public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }不要小看这个简单的类它解决了一个很重要的问题前端只需要统一解析code/message/data这个三层结构就能处理所有接口的返回而不需要对每个接口单独写一套判断逻辑。前端 Axios 封装里一般都会有响应拦截器只要code不是200就弹出message否则才把data返回给调用方。这套约定一旦建立后面写几百个接口都只需要遵循这一个模式。与之配套的还有全局异常处理器RestControllerAdvice作用是把代码里抛出的各种业务异常统一转换成Result格式返回。没有它的话后端一报错前端拿到的是乱七八糟的异常堆栈用户看到的就是一个白屏或者Internal Server Error。有了全局异常处理你可以把库存不足登录已过期没有权限这些情况都通过自定义异常抛出来前端收到后弹一条友好的提示。这一设计在整个后端工程里看起来不起眼但它把错误处理的复杂度降了一个量级。3.2 JWT 登录认证无状态会话是前后端分离项目的标配旅游网站项目和其他类型的系统一样登录认证的落地方式首选 JWT而不是传统的 Session。原因简单后端是纯 API,可能被小程序、网页、App 多个客户端共用Session 依赖服务端存储一旦水平扩展就会有会话同步问题而 JWT 是无状态的,token 里直接携带用户标识和过期时间服务端不保存任何会话信息校验只靠签名解密。对毕设项目而言无状态这一句话足够在答辩时解释为什么选 JWT 而不是 Session。JWT 的实际使用流程是这样的用户登录成功后后端生成一个 token里面封装用户 id、用户名、角色用密钥签名返回给前端前端把 token 存放在本地存储里每次 Axios 请求都在请求头里带上Authorization: Bearer token后端加一个拦截器对需要认证的接口校验 token 是否有效有效就从 token 里解析出当前用户 id 放入请求上下文。这里有一个特别容易被新手忽略的点密码存储绝对不能用明文也不能用简单的 MD5。明文密码一旦数据库泄露就是安全事故MD5 又很容易通过彩虹表反查出来。正确做法是用 BCrypt 加密Spring Security 自带的BCryptPasswordEncoder就能用它每次加密同一个密码得到的哈希值都不同天然抗彩虹表。注册时加密存库登录时用matches方法比对。在答辩时如果你能说出BCrypt 内置盐值同一密码多次加密结果不同这句话评委基本不会继续追这个问题。SpringBoot 项目里集成 JWT 的常见文件结构会是:一个JwtUtil工具类负责生成和解析 token一个拦截器实现HandlerInterceptor负责从请求头取 token 并校验一个WebMvcConfigurer实现类负责注册拦截器并配置哪些路径放行、哪些需要认证。注册和登录接口肯定放行前端要的静态资源也放行其余的接口统一走拦截器。实现思路的关键点 - token 里只放用户 id 和用户名不要放敏感信息 - 设置合理的过期时间比如 24 小时到期后前端跳回登录页 - 拦截器里对 token 解析失败的情况统一返回 401 - 前端 Axios 拦截到 401 后清除本地存储并跳转登录3.3 Service 层的事务与业务逻辑订单扣减的乐观锁实现后端的 Controller 层职责是接收参数、调用 Service、返回结果不应该写具体业务逻辑。真正复杂的业务都集中在 Service 层其中订单提交是整个项目里最适合深挖的点。一个完整的下单流程包含哪些操作查询景点当前剩余可订票数、判断预订人数是否超过余票、计算订单总价、生成订单记录、扣减余票数。这一串操作必须处于同一个数据库事务里任何一个步骤失败前面已执行的数据库操作都要回滚。SpringBoot 里实现事务非常简单在 Service 方法上加一个Transactional注解就完了但扣减余票的并发控制才是真正的难点。假设两个用户同时下单都查到剩余票数是 50各自扣减 1如果没有控制最终余票只少了 1 而不是 2这就是超卖。解决的常见方式是用乐观锁,在景点表加一个版本号字段更新时带上版本条件UPDATE t_scenic SET daily_quota daily_quota - #{count}, version version 1 WHERE id #{scenicId} AND version #{oldVersion} AND daily_quota #{count}这个 SQL 的含义是只有在版本号没变而且余票充足的情况下本次更新才会生效update影响行数为 1 就说明扣减成功为 0 就说明要么被别人改过了、要么票不够了此时直接抛异常让事务回滚。这个写法实际上是做高并发的人说的乐观锁思路,它不用锁表、不用synchronized更适合分布式场景。如果你能把这一套逻辑在答辩时讲清楚评委基本上可以确认你不是拿了个源码跑一跑就来答辩的你是真的理解和思考过的。同时你需要注意一个细节Transactional解决数据一致性,但它管不住逻辑异常如果你在事务方法内部用 try-catch 把异常吞掉了事务照样不会回滚。新手经常在这里踩坑测试的时候发现自己扣了余票但订单没生成成功其实就是异常被捕获后吞掉Spring 感知不到异常自然就不会回滚。这个经验写进你的笔记里调试时会少走很多弯路。3.4 文件上传与静态资源映射图片存储是前后端的同步难题旅游网站景点信息里有大量图片管理端上传景点图片用户端展示这些图片这里涉及一个经常出问题的地方。后端不能把图片存进数据库的 BLOB 字段那不是正确做法正确做法的落地选择通常是图片文件保存到服务器某个磁盘目录数据库只存图片的相对访问路径然后通过配置把图片目录映射成 URL 路径让前端可以直接访问。SpringBoot 项目里的实现方式很简单在application.yml里自定义一个上传路径然后在配置类中把物理路径映射为静态访问 URL。例如物理存储路径/www/upload/scenic/通过配置映射到 URL 路径/images/scenic/**那么前端访问http://服务器地址:8080/images/scenic/xxx.jpg就能直接看到图片了。这个方案比把图片塞到项目根目录下的static文件夹要更合理——因为项目打包成 jar 之后static目录是只读的运行时往里写文件不可行。还有一个很常见的坑前后端分离部署时后端跑在 8080前端跑在 80 或 5173 端口前端页面通过http://localhost:8080/images/...访问后端静态资源,这里又牵扯出跨域问题。正确的处理方式是在后端的跨域配置里开放需要的资源路径和请求方式同时静态资源映射本身也要正确配置,否则前端页面里的图片会一片空白。图片加载不出来是整个项目演示时最直观的翻车现场你应该提前把所有图片 URL 配置成可访问的相对路径然后用浏览器直接打开测一遍再启动前端集成验证一遍。4. Vue 前端从路由到渲染组件划分与数据协作方式4.1 前端路由设计页面结构与守卫逻辑Vue 项目里前端路由设计直接决定了系统的信息架构。旅游网站的前端路由通常分成两部分面向游客的展示端路由和管理员的后台管理端路由。游客端的典型页面路径有/home首页、/scenic景点列表、/scenic/:id景点详情、/order/confirm订单确认页、/user/center个人中心、/login登录注册。管理端一般放在/admin下面底部嵌套一堆二级页面比如/admin/scenic、/admin/order、/admin/user。路由守卫是前端最重要的安全措施之一。你要能读懂代码里router.beforeEach这一段逻辑每次路由跳转前先检查目标路径是否需要登录权限需要的话再看本地有没有 token没有 token 就跳转到登录页并且带上redirect参数登录成功后再跳回原页面。这里有一个细节很多人理解不到位前端路由守卫只是用户体验层面的保护真正的权限校验永远在后端接口前端守卫只是防止用户看到空白页或异常页。答的时候能把这一层说清楚说明你对前后端安全边界有正确的认知。4.2 Axios 封装与请求拦截让每个接口都自动携带 token你可以打开前端项目里的utils/request.js或者api/http.js这类文件它就是一个被统一封装的 Axios 实例。这个实例的作用很明确设置请求超时时间、设置请求拦截器、设置响应拦截器。请求拦截器在每次请求发出去之前从本地存储里取出 token加上请求头。响应拦截器在收到结果时统一判断 HTTP 状态码和后端业务状态码遇到 401 就清除本地登录信息并跳转登录页遇到其他错误就弹出错误提示。这个封装的意义在于你写任何页面组件时不需要关注 token 怎么传、错误怎么处理只需要调用封装好的函数比如import request from /utils/request export function getScenicList(params) { return request({ url: /api/scenic/list, method: get, params }) }调用getScenicList({ page: 1, size: 10 })拿到的就是已经剥离过的后端data数据页面里直接使用即可。这种封装在代码层面看不多但它体现了统一处理横切关注点的工程思想这个在回答你前端项目有什么亮点时是很好的素材。4.3 景区详情的视频点位与 m3u8 播放旅游场景里的一个出彩功能现在很多旅游网站平台都会在景点详情页放一段宣传视频或者慢直播流这个功能如果在你的项目里出现绝对是一个超出普通毕设水准的亮点。视频播放的技术选型要看你拿到的视频格式是什么。普通的 MP4 文件用原生video标签就能播放麻烦不大但如果你接的是网络摄像机生成的流媒体地址尤其是一些采用了 HLS 协议、地址后缀是.m3u8的视频源那就不是原生播放器能搞定的了。HLS 协议的原理是把一段视频切片成无数个小文件.m3u8本身只是一个索引文件里面记录的是每个切片的地址列表。由于浏览器原生不支持直接在video里播.m3u8地址需要借助hls.js这个库把切片拉下来解析后喂给video。前端实现逻辑大概是这样的先用Hls.isSupported()判断当前浏览器是否支持支持就创建 Hls 实例绑定到 video 元素上不支持就回退到原生播放能力。这个功能放在景点详情或景区直播里会非常有代入感而且代码量并不大却是实实在在的热门技术点。不过做这个功能时必须时刻注意跨域问题因为视频文件的响应和普通 JSON 接口一样受到 CORS 限制。如果你用的是第三方视频源远端服务没有开放跨域头那么就算前端代码写得再对也无法拉取切片。在实际项目里你可以选择放在后端做一层代理转发,或者在前端开发阶段用 Vite 的 proxy 配置做代理来解决。这个坑我在调试时踩过一开始一直怀疑是 hls.js 的参数没配对查了半天才发现是跨域把请求拦了。现在回想起来排查这一类问题最快的方法是直接打开浏览器 DevTools 的 Network 面板看报错是 CORS 的还是 404 的方向确认了再动手改代码。4.4 环境变量、代理与打包后的布局异常前端部署的三个老问题前端项目在开发环境跑得挺好一打包部署就出问题这是毕设答辩前最常见的技术事故。问题通常出在三个地方接口地址写死、路由模式、静态资源路径。开发时前端请求一个/api/xxx接口由 Vite 的 dev server 代理到http://localhost:8080这没问题但打包后部署到 Nginx/api的代理要重新在 Nginx 配置否则所有请求都会 404。处理方式是用环境变量区分开发环境和生产环境的VITE_API_BASE_URL在.env.development和.env.production里配置不同的接口前缀。路由模式的问题也很常见。如果你的 Vue 路由用了createWebHistoryHTML5 history 模式部署到 Nginx 后访问/scenic/1这样的路径刷新页面会 404,因为 Nginx 找不到对应的物理文件。解决办法是在 Nginx 配置里加入location / { try_files $uri $uri/ /index.html; }把所有非静态文件请求转发到index.html由前端路由接管。这也是为什么有些参考项目直接使用 hash 模式但为了 URL 美观用 history 模式再配 Nginx 回退是更专业的选择。还有一类打包后布局异常的问题,表现通常是 CSS 样式丢失、字体图标不显示、图片路径多了一层目录。这类问题多半是base或publicPath配置不对资源请求路径没有落在正确的静态文件根目录下。排查的时候看 DevTools 里的资源请求 URL,把它和线上文件实际路径对比一下就能快速定位是多了前缀还是少了前缀。5. 接口文档设计规范把约定的价值发挥到极致5.1 接口文档应该包含哪几块内容接口文档在这套源码里的价值经常被低估很多做毕设的人以为它是给评委看的花架子其实它更是前后端联调的施工图。一份合格的接口文档在每一个接口下面至少包含这些信息接口功能说明、请求方法、请求路径、请求参数表参数名、类型、是否必填、说明、请求示例、成功返回示例、错误码说明。不要以为有 Swagger 自动生成的在线文档就够了Swagger 能展示参数和返回结构但对业务含义和错误码约定解释得不充分。好的做法是手写一份 Markdown 接口文档同时接口代码里保留 Swagger 注解生成在线调试页两者互为补充。我见过很多接口文档只写获取景点列表 GET /api/scenic/list一行字然后就没了。这种文档根本没法用因为前端拿到手根本不知道要传什么参数、返回什么字段、字段名是什么类型。实际项目里前后端并行开发时接口文档是双方唯一的沟通契约文档不详细前端只能反复去问后端联调效率会直线下降。在你的毕设答辩中,完整详实的接口文档也给了评委一个明确信号这个项目是按真实工程规范管理的。5.2 核心接口定义示例接口协议如何组织才能一眼看懂下面是几个旅游平台里最有代表性的接口定义方式你可以直接对照这套设计去检查手头源码里的接口文档是否完整功能方法路径核心请求参数返回结果分页查询景点GET/api/scenic/listpage, size, keyword, status分页对象获取景点详情GET/api/scenic/{id}路径参数 id景点详情对象提交订单POST/api/order/submitscenicId, travelDate, count, contactPhone订单号取消订单PUT/api/order/cancel/{orderId}路径参数 orderId操作结果用户收藏景点POST/api/favorite/addscenicId操作结果管理员登录POST/api/admin/loginusername, passwordtoken返回结果部分建议统一用这样的一段 JSON 来展示{ code: 200, message: 操作成功, data: { orderId: 202501120001, amount: 360.00, status: 1 } }这里有一个很关键的设计约定订单号不要用数据库自增 id 直接返回给用户而是要有一套生成规则比如日期随机序列的格式。这样做的好处是订单号对外展示更专业同时避免暴露数据库里的真实记录数。5.3 接口文档的维护方式用工具把调试和数据 Mock 串起来我个人在实际项目中强烈推荐使用 Apifox 或者 Postman 来管理接口文档。这类工具支持从 Swagger 导入接口定义然后自动生成调试环境你可以在工具里为每个接口造好测试数据保存成一条条用例之后任何一次代码改动都能快速回归测一遍接口是否正常。对毕设场景来说最大的好处是,它可以把文档、调试、测试集中在一个界面,你答辩时直接在工具里调用接口返回数据,比你切到前端页面点点点更有工程师气质。更妙的是好的 API 工具还支持根据接口定义自动生成前端请求代码和后端 Controller 代码骨架这对于快速理解源码里的接口调用关系非常有帮助。我记得当时第一次用这类工具跑通接口导出到本地 生成前后端代码的时候对接口文档是前后端契约这句话的理解一下子从抽象变成具象了。如果你拿到手的一套源码是接口文档和代码对不上的那也别慌按工具里的接口调用记录去反向梳理往往比直接读源码走在理解的前面。5.4 错误码约定别让前端猜你的异常错误码是接口文档里最容易被忽略的部分。看到很多项目自定义返回结果里 code 只有 200 和 500,这其实是偷懒的做法。实际项目里应该针对常见业务场景设计一套有语义的错误码比如1001表示用户名或密码错误、1002表示 token 过期或无效、2001表示景点不存在或已下架、2002表示余票不足、3001表示订单状态不允许当前操作。有了这些错误码前端不只能弹一个提示框还能针对不同错误码做不同逻辑处理比如遇到1002就跳转登录页遇到2002就置灰提交按钮并提示用户降低预订数量。错误码表应该统一写进接口文档的开头或附录里前后端都遵守同一份约定。你在答辩前顺手把几个高频错误码记在脑子里评委问起你的系统怎么处理并发扣减余票失败这个问题时你可以直接说我会抛一个库存不足的业务异常,错误码是 2002,前端收到之后会做对应提示,这种回答非常有说服力。6. 部署、联调与答辩前自查把项目从能在我电脑上跑变成在任何环境都能跑6.1 从开发环境到生产环境的构建部署流程SpringBoot 后端在 IDEA 里启动只是第一步真正的项目交付要能打包部署。后端的打包命令用 Maven 的mvn clean package -DskipTests打出来的是一个可执行的 jar 包放到服务器上执行java -jar xxx.jar就能启动。这里要注意application.yml里数据库连接地址不要写成localhost应该换成数据库服务器的实际 IP,密码也不要写明文,可以用环境变量占位符比如${DB_PASSWORD}启动时通过--DB_PASSWORDxxx传入。这样你的项目配置就不会在传阅过程中泄露真实数据库密码。前端项目打包命令是npm run build产物是一个dist目录里面是纯静态文件。部署时的标准做法是用 Nginx 托管这个目录然后反向代理/api前缀的请求到后端的 SpringBoot 服务。关键的 Nginx 配置示例server { listen 80; server_name your_domain_or_ip; root /var/www/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这段配置解决了两个核心问题前端路由在 history 模式下的刷新 404以及后端接口的跨域代理。如果你不想在最外层用域名,直接配置成server_name _也是可以的取 IP 访问即可。部署完成后测试时记住只测前端页面能打开还不够一定要实测一遍完整的用户链路从注册到下单再到管理端处理订单中途任何一个接口 500 你都有时间提前修。6.2 跨域、端口、数据库连接部署期三大高频事故这三个问题几乎出现在每一套项目的部署阶段,提前总结一下能帮你快速定位。跨域问题的表现是浏览器控制台报CORS policy解决办法有两个维度后端加跨域配置类或者 Nginx 用反向代理让前端页面和 API 请求同源。后端加跨域配置时要特别注意allowedOriginPatterns和allowedOrigins的区别,前者允许携带通配符,适合有多个前端域名的情况后者严格要求精确匹配。SpringBoot 不同版本对这两种方法的默认行为还不太一样如果你用的是 SpringBoot 2.7建议用allowedOriginPatterns(*)否则可能遇到预检请求被拦截的诡异问题。端口占用是最没有技术含量但最高频的报错Port 8080 was already in use这句错误几乎每个 Java 开发者都见过。解决办法是netstat -ano | findstr 8080Windows或者lsof -i :8080Linux/Mac查端口被哪个进程占用然后杀掉对应进程或换一个端口。数据库连接失败就按这个顺序排查数据库服务是否启动、连接地址是否可达、用户名密码是否正确、数据库是否允许远程访问。时区问题在连接 MySQL 时也很典型经常报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized解决办法是在 JDBC 连接串里加上serverTimezoneAsia/Shanghai。6.3 答辩前必须自己问自己的十道题有了能跑的代码只是起点能撑住答辩提问才是最终目标。基于这套旅游网站项目,我列一下你拿源码后应该反复演练的问题提纲你的项目为什么选择前后端分离架构有什么好处你的数据库表设计是怎么考虑的核心表有哪些关系用户登录是怎么做的token 过期了前端怎么处理下单时怎么避免超卖乐观锁的实现细节是什么图片文件是怎么存储和访问的为什么不用 BLOB后端接口统一返回格式是什么异常怎么处理前端路由守卫解决了什么问题权限控制在前端还是后端部署时跨域怎么解决Nginx 代理的原则是什么项目里你觉得最出彩的功能是哪个为什么如果同时有 1 万人访问你的系统哪些地方会撑不住怎么优化最后一题特别值得好好准备。你不用真的做一套高并发架构但至少能说出来热点数据可以加 Redis 缓存搜索可以上 Elasticsearch图片可以放 CDN数据库可以做读写分离这些方向性的解决方案。评委要听的是你有没有工程扩展意识而不是要求一个毕设真的扛住 1 万并发。6.4 源码二次开发时的心态建议不是看懂而是能改最后说我个人的真实体会。很多人拿到一套完整的 SpringBootVue 项目源码第一反应是跑起来看看,跑通了就感觉自己已经会了。但你在答辩前如果只做到这一步评委随便改一个需求你就懵。比如评委说如果门票价格要支持浮动比如节假日涨价 20%你觉得要改哪些地方这个问题的本质是考你对数据模型、价格字段和订单价格快照的理解。如果你完整读过了订单表和景点表你会想到在订单表里冗余一个下单时的价格快照字段这样即使以后景点价格调整历史订单的价格也不会变同时景点表需要一个price与一个可选的节假日价格配置前端提交订单时展示的是实时价格后端算总价时用当前价格,一旦下单就冻结快照。我把这个思路写在这里也是想说明同一个点源码是很好的学习材料但学习的终点不是把代码跑起来而是把每个设计决策背后的为什么都挖出来转换成自己能表达的工程判断。当你真正做到这一步时答辩更像是在分享自己实际做过的一个项目而不是在背一份别人写的代码。我坚持认为一份附带 SQL 脚本和接口文档的完整源码价值远远超过代码本身它是一套已经被验证过的工程决策集。你在学习它的时候多问几个为什么这里要这么设计多尝试着改一改其中一个功能这套源码带给你的成长会远超把它跑通这一个动作。
