SpringBoot+Vue+MySQL铁路订票系统毕设全流程实战详解

做毕设那会儿，我身边不少同学选题都奔着"好写"去，最后答辩现场十个里有六个是图书管理、宿舍管理、仓库管理，题目一报出来，老师基本就知道后面是什么套路了。我自己选了铁路订票管理系统，用SpringBoot + Vue + MySQL这套组合做了完整的一轮，最大的体会是：这题目在"难度可控"和"有的可讲"之间平衡得非常好。它不是纯CRUD，余票查询、下单锁座、订单状态流转、退票改签这些业务点，随便挑一个都能展开聊十分钟，代码量和论文篇幅都很容易撑起来。

这篇文章不整虚的，我从选题论证开始，到数据库设计、后端接口开发、前端页面联调，再到论文撰写和打包部署，把完整流程和踩过的坑一条条写清楚。如果你正在纠结毕设选题，或者已经选了同类订票/预约系统，可以直接把这篇当参考地图用。

1. 毕业设计选题：铁路订票系统为什么比"XX管理系统"更值得做

先聊选题逻辑，这是很多人忽略但实际最影响后几个月心情的一步。同样是Web项目，题目选得好不好，直接决定你写代码时是越写越有劲，还是憋到答辩前想换个题重来。

1.1 业务复杂度恰到好处，演示时不会"三分钟露馅"

普通的图书管理系统、仓库管理系统，核心其实是一张主表的增删改查，再加两个关联表的查询。这类系统不是不能做，而是答辩演示时很容易陷入尴尬：给老师看一遍新增、修改、删除，三分钟就讲完了，剩下的时间全靠"未来可以扩展"来撑。

铁路订票系统的业务链天然更长：用户注册登录、车次列表展示、余票实时查询、下单锁座、订单支付、退票释放余票、个人订单管理……每一环都有真实的业务规则在里面。比如"下单时余票不能为负""一个订单最多买5张票""退票后余票要回补"。这些规则在代码里是逻辑判断，在论文里是需求分析和功能设计的素材，无论从哪个角度讲，都让你有得写、有得说。

1.2 技术栈选型：为什么是SpringBoot + Vue + MySQL而不是别的

每年都有人问我，要不要把后端换成Python的Flask或Django，前端要不要上React，数据库要不要试试PostgreSQL。我的建议是：除非你本来就很熟这些技术，否则不要为了"显得新"去换。

SpringBoot在Java后端的地位不用多说，毕设答辩时老师几乎人手都会用，你报出这个技术栈，老师对项目的结构心里就有数。Vue在国内高校前端的普及率也很高，而且它和SpringBoot的搭配模式非常干净：前端静态资源打包后可以直接丢进SpringBoot的static目录，也可以用nginx单独部署，两条路都有大量现成教程。MySQL更不用讲，关系型数据库的入门标准，资料多到任何报错都能搜到解决方案。

这套组合最实际的好处是"安全感"：毕设季凌晨两点卡住的时候，你能搜到答案比什么都重要。

1.3 功能边界怎么划：别打算做一个12306

选了这个题目后，第一件事是控制功能范围。很多同学一激动就想把选座、改签、候补购票、积分兑换全做进去，结果做到一半发现工作量完全失控，连核心链路都没跑通。

我的做法是：把系统分成"必须做"和"可选做"两层。

• 必须做：用户注册登录、车次查询、余票展示、创建订单、支付模拟、个人订单查询、管理员后台（车次管理、余票管理、订单查看）。
• 可选做：退票改签、图表统计、Excel导出、多角色权限细分。

先花三分之二的时间把"必须做"做扎实，有余力再碰"可选做"。铁路订票系统的核心价值在于业务流程完整，而不是功能数量多，这个边界想清楚之后，后面开发节奏会稳很多。

2. 数据库设计：先画ER图再建表，余票和订单的并发问题从这里就埋下种子

很多新手拿到题目第一反应是打开Navicat开始建表，边建边想字段，建到一半发现缺关联，又回头改。这个习惯在毕设里特别吃亏，因为数据库设计是要写进论文的一章，后面接口开发、前端取数全都依赖表结构，返工代价很高。我自己的流程是：手绘ER图 → 工具再画一遍 → 写建表SQL → 补测试数据。

2.1 五张核心表：谁跟谁是一对多，必须一开始就理清

铁路订票系统最核心的表有五张：用户表、车次表、余票表、订单表、订单明细表（如果需要记录多张票的乘客信息）。

用户和订单是一对多：一个用户能下多个订单。车次和余票是一对多：一个车次按座位等级拆成多条库存记录。订单和车次是多对一：多个订单可能指向同一趟车。这层关系不复杂，但一定要在ER图阶段理清楚，否则后面写SQL时ON条件很容易写错。

下面是车次表和余票表的参考结构，我在实际建表时调整过几版，最后定下来的是这套：

CREATE TABLE t_train ( id BIGINT PRIMARY KEY AUTO_INCREMENT, train_no VARCHAR(20) NOT NULL COMMENT '车次编号，如G1234', train_type VARCHAR(10) COMMENT '高铁/动车/普快', start_station VARCHAR(50) NOT NULL, end_station VARCHAR(50) NOT NULL, depart_time DATETIME NOT NULL, arrive_time DATETIME NOT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE t_ticket_stock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, train_id BIGINT NOT NULL, seat_type VARCHAR(20) NOT NULL COMMENT '一等座/二等座/硬座/软卧', price DECIMAL(10,2) NOT NULL, total_count INT NOT NULL, remaining_count INT NOT NULL, UNIQUE KEY uk_train_seat (train_id, seat_type) );

余票表单独拆出来，而不是把余票数量直接塞进车次表，是因为一趟车有多种座位等级，每个等级的票价和余票数都不一样。如果全部塞进车次表，后续加一种座位类型就得改表结构，而拆成独立表之后，加等级只是加一条记录的事，非常简单。

2.2 几个"想当然"字段的坑：身份证、手机号、状态值

有些字段看起来简单，真做起来全是细节。手机号和身份证号不要用bigint存，用varchar。原因很实际：Java后端接MySQL时，如果字段是bigint，返回给前端JSON后，超过一定长度的数字会出现精度丢失，身份证号后几位直接变0，这种bug排查起来非常像"玄学"。密码字段不要用明文，也别用简单的MD5，Spring Security自带的BCryptPasswordEncoder在SpringBoot里集成很方便，用一次就记住了。

订单状态这种字段，建议用整型配合枚举值，而不是直接存"待支付""已支付"这种中文。整型状态0待支付、1已支付、2已取消、3已退票，代码里写一个OrderStatus枚举类，可读性一点不比字符串差，而且写SQL统计时更方便。论文里的"数据库设计规范"也能水一段文字，属于一个选择服务两处需求。

2.3 余票扣减的并发问题：从"先查再改"到行级锁

订票系统最值得在论文里写的技术点，就是并发场景下的余票扣减。如果代码写成"先查remaining_count，判断大于0，再减1"，两个请求同时查到余票为1时，就会超卖。

处理方案有很多，毕设阶段我推荐最直观的一种：对余票表的记录加行级锁，先锁住再更新。

SELECT * FROM t_ticket_stock WHERE id = ? FOR UPDATE;

事务内先通过FOR UPDATE锁住这条余票记录，然后判断余票数是否充足，充足才执行UPDATE扣减并插入订单。因为同一趟车同一种座位的余票记录只有一条，行锁会让第二个请求排队等待，从机制上杜绝超卖。这个思路写进论文就是"基于悲观锁的并发控制"，老师一听就知道你考虑过真实业务场景，比单纯写CRUD强太多。

3. SpringBoot后端落地：分层结构、核心接口与事务边界

数据库定了，后端开发就有了地基。我用的SpringBoot版本是2.7.x，配套MyBatis-Plus做ORM，这套组合写起来很快，而且MyBatis-Plus的代码生成器能直接把单表CRUD代码生成出来，把时间省给业务逻辑。

3.1 包结构设计：按业务模块分，不按技术层次分

后端包结构有两种常见组织方式：按技术层分（controller、service、mapper下面再分业务），或者按业务模块分。我的经验是毕设项目按业务模块组织更清晰，因为铁路订票系统的业务边界非常明确。

com.example.train ├── controller │ ├── UserController.java │ ├── TrainController.java │ ├── OrderController.java │ └── AdminController.java ├── service │ ├── UserService.java │ ├── TrainService.java │ ├── OrderService.java │ └── TicketStockService.java ├── mapper ├── entity ├── config ├── common │ ├── Result.java │ ├── JwtUtil.java │ └── GlobalExceptionHandler.java

config目录放WebMvc配置、CORS跨域配置、MyBatis-Plus分页插件配置。common目录放统一返回结果类Result、JWT工具类和全局异常处理器。这套包结构就是论文里"系统总体架构"那章的配图来源，画上去非常符合教学惯例。

3.2 余票查询接口：联表查询的一次实践

车次列表要展示的信息不只是车次本身，还有各座位的余票数和票价。最自然的方式是左连接余票表，查出来之后在Java代码里按车次做聚合。前端拿到的是一个车次对应多个座位等级的数据结构，展示时按小组件循环渲染即可。

List<Map<String, Object>> list = trainMapper.selectTrainWithStock( new QueryWrapper<Train>() .like("train_no", keyword) .ge("depart_time", queryDate) );

这里有个小经验：分页插件一定要配置，否则MyBatis-Plus的Page查询在超过一条数据时不会自动组装分页信息。我当时漏配了这个，车次列表一页永远只显示10条但不带总数，前端分页组件总是显示只有一页，排查半天才反应过来插件没注册。

3.3 下单接口的事务边界：哪些操作必须放同一事务

下单是整个系统最核心的接口，涉及的操作包括：校验用户是否登录、查询余票、锁余票记录、扣减余票、创建订单、生成订单号。这些操作必须在一个事务里完成，否则可能出现余票扣了但订单没建成，或者订单建了余票没扣的数据不一致问题。

我在OrderService里用@Transactional标注下单方法，事务边界就划在"扣余票+建订单"这一段。生成订单号时用时间戳加随机数，再加一点业务前缀，比如ORD加当前年月日时分秒再加四位随机数，足够保证演示场景下不会重复。这里还应该加一个幂等判断：同一个用户对同一车次同一座位等级在短时间内提交两次，要能识别出重复下单。我的处理是在代码里先查该用户是否已有相同车次且状态为"待支付"的订单，有就直接返回"请勿重复下单"。

3.4 JWT登录鉴权与拦截器配置

毕设级别的登录鉴权，没必要引入Spring Security做一套完整的授权体系，用JWT加一个HandlerInterceptor就能解决问题。用户登录成功后，后端签发一个token返回给前端，前端存在localStorage里，每次请求在header里带Authorization: Bearer <token>。拦截器统一校验，放行登录、注册和车次查询等公开接口，其余接口必须带有效token。

public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token != null && token.startsWith("Bearer ")) { token = token.substring(7); if (JwtUtil.verify(token)) { return true; } } response.setStatus(401); return false; } }

这套实现代码量不大，但"前后端分离下如何做登录状态管理"这个点写进论文非常加分，而且面试或答辩时老师大概率会追问，你只要答清楚token的无状态特性和刷新机制就算过关。

4. Vue前端开发：从页面骨架到一条完整的购票链路

前端用Vue 2配合Element UI，这个组合和SpringBoot后端在毕设生态里的搭配非常成熟，文档、组件、踩坑记录都是现成的。

4.1 页面路由与组件拆分：让后端同学也能看懂的结构

前端页面不需要太多，核心是：登录注册页、首页车次查询页、车次详情/下单页、订单列表页、订单详情页、管理后台页。路由用Vue Router配置好，懒加载方式引入组件，不然首页首次加载会把所有JS一次拉下来，本地打开还好，部署到服务器上会明显变慢。

组件拆分的原则是"一个业务页面一个文件夹"。比如下单页，拆成车次信息卡片、座位等级选择、乘客信息表单、订单确认提交四个子组件，父组件负责数据聚合和提交逻辑。这套拆分方式在写论文"前端界面设计"章节时可以直接画组件树，比我见过很多硬掰的架构图自然得多。

4.2 余票查询页与车次列表：前端最需要耐心调的部分

余票查询页的逻辑是：用户选择出发城市、到达城市、出发日期，点击查询，前端调用后端的车次列表接口，拿到数据后渲染表格，表格里每一行显示车次号、始发站、终点站、发车时间、到达时间、各座位等级的余票数和票价。余票数是红还是绿、按钮是可选还是置灰，都需要在拿到数据后做条件判断。

这里容易踩的坑是时间格式。后端返回的depart_time如果直接拿Java的LocalDateTime序列化成JSON，前端拿到的可能是2025-06-18T10:30:00这种带T的字符串，显示在页面上很丑。我当时的处理是在实体类时间字段上加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")，前后端一天解决，不用前端再写格式化方法。

4.3 axios封装、跨域与会话保持：联调阶段的三个老熟人

axios封装我习惯放在src/utils/request.js里，统一设置baseURL和请求拦截器。

const service = axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }); service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = 'Bearer ' + token; } return config; });

跨域问题在开发环境用Vue CLI的proxy解决，在vue.config.js里把/api前缀的请求代理到后端8080端口。生产环境如果是把前端打包后放进SpringBoot的static目录，就不存在跨域问题了。联调时最常遇到的接口通但数据不对，大部分是字段名对不上，Java后端用驼峰命名，前端也按驼峰接，基本不会出错。

提交订单接口调用时要注意防重复提交的交互设计。我前端的做法是点击提交后立即把按钮变为loading状态，同时禁用，请求成功或失败后再恢复。配合后端的幂等判断，双保险足够应对答辩演示时手滑连点两次的尴尬场景。

5. 论文撰写与答辩准备：如何把代码量转化成分数

论文部分的工作量不该被低估，很多代码写得不错的同学最后卡在论文格式上。我的建议是：论文不是最后一个月开始写，而是开发到哪个模块，就写哪个模块的章节，最后一个月只做整合和排版。

5.1 论文结构映射：每一章对应系统实现的哪部分

毕设论文通常有固定的六章结构：绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试。我写的时候把每一章和真实代码对应起来，避免出现"论文写了一套，代码是另一套"的尴尬。

• 绪论：写研究背景和意义，铁路票务行业的信息化需求，这一段可以引用一些公开数据，但别写成行业报告。
• 相关技术介绍：SpringBoot、Vue、MySQL各自的特点，篇幅不用多，每个技术写清楚"在系统里承担什么角色"比罗列特性更有说服力。
• 需求分析：用例图加功能需求和非功能需求，铁路订票系统的用例非常清晰，用户端和管理员端各一张用例图就够。
• 系统设计：架构图、功能模块图、数据库ER图、核心表结构，这部分对应我前面讲的数据库设计章节。
• 系统实现：按模块写，每个模块放一个核心代码片段加运行截图。
• 系统测试：功能测试用例表格加结论，再写一点性能测试（可以简单提一下用JMeter压测了余票查询接口，200并发无报错之类）。

5.2 数据库设计章节的写法要点

数据库设计章节是答辩老师最爱翻的部分，也是最容易看出你是否真做过系统的地方。不要只贴建表语句，要把每张表的用途、表之间的关系、关键字段的设计理由写清楚。比如余票表为什么单独建、订单状态为什么用整型而不是字符串、为什么在数据库层面做唯一约束。这些"为什么"就是你论文的深度所在，也是答辩时提问的主要来源。

5.3 答辩高频提问清单

根据我的答辩经历和旁边同学的反馈，老师针对这类系统通常问这几个问题：

• 系统的角色权限是怎么控制的？（答：JWT拦截器加管理员标记字段）
• 余票扣减如何防止超卖？（答：SELECT FOR UPDATE行锁加事务）
• 如果用户下单后不支付，余票什么时候释放？（答：订单有支付超时时间，定时任务扫描超时订单并回补余票）
• 你的系统有什么可以改进的地方？（答：引入Redis缓存热点车次余票，用消息队列异步处理订单）

最后一个问题其实是送分题，提前准备好两个"可扩展点"，把改进思路讲清楚，比现场临时想答案效果好十倍。

6. 打包部署与踩坑记录：从开发环境到"能演示"的系统

毕设评分的一个硬指标是系统能跑起来。很多项目代码写得挺完整，结果在答辩前的部署环节翻车，最后只能开着IDEA和浏览器演示，一旦现场网络波动就心态崩掉。

6.1 本机环境版本怎么选：所有"怪问题"的源头

环境版本是最容易出问题又最容易被忽略的。我整理了一份我实测稳定的版本组合：

版本不匹配会出现很多莫名其妙的问题。例如MySQL 8.0之后驱动类变成了com.mysql.cj.jdbc.Driver，有些老教程还在写com.mysql.jdbc.Driver，SpringBoot启动直接报驱动找不到。这种问题搜起来很耗时，最好一开始就用对版本。

6.2 前后端如何打包：一个就够了，两个也行

铁路订票系统的部署有两条路线。路线一：后端打成jar包，前端npm run build之后把dist目录下的文件复制到SpringBoot的src/main/resources/static/里，一起打进jar包，一个命令java -jar xxx.jar就能启动整个系统。这条路线最适合答辩前应急，日志里能看到静态资源请求，部署成本最低。

路线二：后端jar包用java -jar跑，前端dist目录丢给nginx代理，同时把/api开头的接口请求反向代理到后端端口。这条路线更接近企业真实部署方式，但涉及nginx配置文件，对第一次做的同学来说可能要多花点时间。我建议两条都试一下：开发过程用nginx方式，答辩前一夜加固成单jar包方式。

6.3 部署阶段容易踩的坑：端口、路径、数据库连接

部署最常见的坑有三个。

第一个是端口冲突。后端用的8080端口如果被其他程序占了，启动日志里会看到端口占用异常，改application.yml里的server.port就好，别在不清楚情况时反复重启。

第二个是数据库连接配置。如果前后端分离部署，后端配置文件里的spring.datasource.url要写服务器能访问到的MySQL地址，别图省事直接写localhost。另外生产环境记得在数据库初始化时把建表SQL和初始数据都执行一遍，我之前就是忘了一开始往库里插管理员账号，结果后端能起但管理后台怎么都登不进去。

第三个是前端路由刷新404问题。如果用的是history路由模式，直接部署到nginx时刷新某个子页面会出现404。解决方案是前端改成hash模式，或者在nginx配置里加try_files $uri $uri/ /index.html。毕设演示用hash模式最省心，问题少一多半。

写到最后的一点体会

做完整个项目回头看，铁路订票管理系统这个题目最值钱的地方不是技术有多难，而是它逼着我在一个"像样的业务场景"里把前后端分离开发的完整链路走了一遍。从设计表结构时考虑并发扣减，到下单接口划事务边界，再到前端处理loading态和重复提交，每一个点都是实际开发中会碰到的事，做一遍比看十遍教程管用。如果你正在做类似的毕业设计，我建议别急着写代码，先把功能边界、表结构、页面流转这三件事想清楚，后面至少能少走一半弯路。剩下的时间，该就熬夜该优化优化，答辩的时候你会感谢当初那个没有划水的自己。