SpringBoot+Vue汽车票网上预订系统毕设实战全解析

看到这个标题，点进来的同学应该都是奔着“毕设/课设”来的。SpringBoot+Vue 汽车票网上预订系统管理平台，这个题目在学校里出现频率非常高，因为它业务链路完整、技术栈主流、演示效果直观，关键还不会像电商系统那样堆砌一堆营销功能，做起来有边界感。说白了，这是一套“标准到不能再标准”的前后端分离项目，但正因为它标准，才值得把它背后每一个设计细节都吃透。这篇文章我就按自己实际做过这类项目的思路，从选型到数据库，再到前后端实现和源码部署，把这个系统彻底拆干净，顺带把那些“SpringBoot版本太高”“MySQL SSL连接错误”“Vue打包放不进SpringBoot”之类的坑一次性填平。

1. 项目定位与技术选型：先搞清楚这套系统要解决什么问题

1.1 为什么汽车票预订系统适合当毕设和课设

很多人选题目有个误区，上来就想要“独特”“新颖”，结果要么功能太虚，要么数据模型复杂到答辩时自己都讲不清楚。汽车票预订系统不一样，它的核心业务非常实在：旅客要查班次、买车票，车站要管车辆、排班、看订单。这本质上就是一个“信息管理 + 在线交易”的组合，既能演示普通用户的完整操作流，又能体现管理员的维护场景，工作量和难度刚好卡在课设要求的中上位。

更关键的是，这个方向容易扩展。今天你做一个基础版，拿到的表结构是用户表、班次表、订单表；明天你想升级，可以加坐位图、支付回调、短信验证码，每一步都有明确的业务含义。我见过不少同学用“汽车票系统”做底子，最终演化出带数据分析、座位锁定的完整项目，这在写简历时是很自然的一句话：“独立设计并实现一个包含座位库存管理、订单状态流转的业务系统。”所以别嫌题目普通，能把普通题目做扎实，本身就是能力。

1.2 技术选型背后的理由：SpringBoot+Vue+MySQL为什么是经典组合

这个组合几乎成了国内Java后端项目的默认配置，不是没有原因的。SpringBoot最大的价值是“开箱即用”，内嵌Tomcat、自动装配、自带健康检查，学生不需要去折腾复杂的SSM配置文件，把精力放在业务逻辑上。Vue则胜在轻量和组件化，前端页面可以拆成组件维护，配合Element UI这类组件库，两天搭出一个像样的管理后台完全不成问题。MySQL不用多说，关系型数据库能很好地表达用户、班次、订单之间的关联，而且学校机房、个人电脑普遍都装了。

还有一个隐藏原因：岗位匹配。Java开发岗位看简历，最常出现的技术组合就是SpringBoot+MySQL，前端能写Vue的同学更是加分。用这套系统做项目，面试时聊技术栈完全不虚，不会像纯JSP项目一样给人留下“过时”的印象。

1.3 角色与功能模块：用户端、后台管理端各管什么

我在设计功能时会先把角色理清楚，因为角色直接决定页面和接口的数量。这套系统通常分三类角色：普通用户、管理员、超级管理员（很多毕设版本只分用户和管理员，足够了）。

用户端的核心是“查票—购票—订单”这条链路，管理端的核心是“资源维护—排班—订单监管”。这两块功能不要混在一起，前端路由要分模块，后端接口也要分前缀，比如/api/user/**和/api/admin/**，这样权限控制才有清晰边界。

2. 数据库设计：把用户、班次、订单串起来的基础

2.1 核心数据表：从实体关系开始拆

数据库是整个系统的地基，也是答辩时老师最喜欢追问的地方。汽车票系统的实体关系并不复杂，我建议先画一张草稿：用户买票，班次由车辆和站点组成。最简单的设计只需要五张表：用户表、站点表、车辆表、班次表、订单表。

有些版本还会把订单和乘客拆开，支持一笔订单多个乘客，但毕设阶段建议一个订单对应一个班次下的一个乘客，逻辑更清晰，也够用。班次表里的depart_station_id和arrive_station_id都指向站点表的id，这就是典型的一对多外键关系；一个班次属于一辆车，所以bus_id外键指向车辆表。

2.2 关键状态与约束：订单状态、余票字段怎么设计

表结构谁都会建，但状态字段设计得好不好，直接反映你有没有真实业务经验。订单表我建议必加order_status字段，取值范围固定为：待支付、已支付、已出票、已取消、已退票。不要用整数 0、1、2 代替，直接用字符串可读性好，查询也方便。如果是课设周期短，可以把“待支付”和“已支付”合并，只保留“已出票”和“已取消”两个状态，逻辑更简单。

余票字段我强烈推荐使用remaining_seats而不是每次都用total_seats - 已售数量去算。后一种做法你的订单表必须严格准确，一旦出现异常订单就会导致余票永远错误。直接在班次表维护一个余票数，每次下单成功后减一，取票时判断“余票大于0”，这是多数业务系统实际采用的做法。

注意：状态字段和余票字段都建议加索引。用户查自己的订单、管理员筛订单状态，这两个查询频率极高。

2.3 索引、事务与一个容易被忽略的并发问题

订单表必须有唯一索引order_no，因为打印出来的订单号如果重复，演示时会非常尴尬。自增ID只适合内部使用，不适合直接暴露给用户，这也是为什么我要单独生成order_no。它可以用“时间戳+随机数+用户ID尾号”拼接，保证唯一且可读。

真正体现业务水平的，是下单时的并发控制。汽车票不像普通商品，余票是有限的，两个用户同时抢最后一张票，数据库层要保证只有一个成功。我常用的写法不是查一遍再改一次，而是直接在SQL层面做条件更新：UPDATE schedule SET remaining_seats = remaining_seats - 1 WHERE id = ? AND remaining_seats > 0。如果影响行数为0，说明余票不足，直接提示“票已售罄”。这个方法不需要加锁，也不需要Redis，对于毕设系统完全够用，而且面试时说出来非常加分。

3. 后端SpringBoot实现：登录、查票、下单这类接口怎么写

3.1 工程结构与关键配置：让代码看起来像企业项目

很多课程设计的通病是代码全堆在Controller里，一个类几百行，答辩时一问Service层是什么都答不上来。我建议按标准四层结构来拆：Controller接收参数、Service处理业务、Mapper操作数据库、Entity映射表。即使你用的是MyBatis-Plus，也可以遵循这个分层，代码一多你就会感谢当初的结构。

pom.xml里核心依赖把这些加上：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> </dependency>

application.yml里最容易踩坑的是数据库连接串。MySQL 8.0默认开了SSL，本地开发时经常报“SSL connection error”，加上useSSL=false即可；还要处理时区问题，否则控制台会报 “The server time zone value” 错误：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/bus_ticket?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8 username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: mapper-locations: classpath*:/mapper/**/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

这里多说一句，“版本太高”是很常见的坑：SpringBoot 3.0开始强制要求JDK17，而很多同学的电脑里是JDK8。如果你用的是SpringBoot 2.7.x，配合JDK8完全没问题；如果项目pom里已经写了3.x版本，你又不想升级JDK，那请直接降低SpringBoot版本或者安装JDK17。

3.2 用户登录与权限控制：JWT方案从请求到拦截完整走一遍

毕设系统的权限控制不需要做得很花哨，用JWT把“登录状态”和“角色”传下去就够了。登录接口流程是：前端把用户名密码传过来，后端查询用户表，校验密码，通过后生成一个token，把用户ID和角色塞进去，设置过期时间，返回给前端。前端拿到token后存在localStorage里，每次请求都带上Authorization请求头。

后端用一个拦截器统一校验：

@Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); if (token == null || token.isEmpty()) { response.setStatus(401); return false; } try { Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } catch (Exception e) { response.setStatus(401); return false; } }

管理员接口再加一层角色判断：如果当前请求路径以/api/admin开头，而token里的role不是管理员，则直接返回403。注册接口、登录接口、班次查询接口要放行，否则用户连登录都进不来。这个逻辑请务必在拦截器里认真写，因为答辩时老师一定会问“你这个系统的权限是怎么控制的”。

3.3 核心订票接口：一个事务把余票和订单一起搞定

购票是整个系统的核心业务，我建议单独写一个purchaseTicket方法，并加上@Transactional事务注解。逻辑分几步：根据前端传的scheduleId查班次，判断班次状态和发车时间是否有效；更新余票，使用前面说的UPDATE ... WHERE remaining_seats > 0；生成订单号；插入订单记录；最后返回订单详情给前端。

@Transactional public Order purchaseTicket(Long userId, Long scheduleId, String passengerName, String passengerIdCard) { Schedule schedule = scheduleMapper.selectById(scheduleId); if (schedule == null || schedule.getStatus() == 0) { throw new BusinessException("班次不存在或已停运"); } if (schedule.getDepartTime().before(new Date())) { throw new BusinessException("该班次已发车"); } int rows = scheduleMapper.reduceRemainingSeats(scheduleId); if (rows == 0) { throw new BusinessException("余票不足，购票失败"); } Order order = new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setScheduleId(scheduleId); order.setPassengerName(passengerName); order.setPassengerIdCard(passengerIdCard); order.setOrderStatus("已支付"); orderMapper.insert(order); return order; }

这里有三个细节值得注意。第一，余票更新和订单插入必须在同一个事务里，否则会出现“票扣了但订单没生成”或“订单生成了但票没扣”的不一致状态。第二，reduceRemainingSeats的SQL是核心，不要先select再update，两条语句之间其他请求可能已经把票买走了。第三，订单状态我没设“待支付”，因为课设系统一般不接真实支付，直接默认“已支付”可以少一个状态流转。如果有人问为什么不接支付，你回答“预留了支付接口，当前演示采用模拟支付”，这完全说得通。

4. 前端Vue实现：页面、路由、请求封装与联调细节

4.1 页面结构与技术选型：Vue2还是Vue3

前端选型取决于你的后端版本和Node环境。如果后端是SpringBoot 2.x，我建议用Vue2 + Element UI，这套组合最成熟，网上的解决办法最多，踩坑成本最低；如果你愿意折腾，用Vue3 + Element Plus也没问题，但要注意Element Plus的组件用法和Vue2有差异。对课设来说，稳定性优先，选你熟悉的版本比选新版本重要得多。

页面层面我建议拆成两个区域：前台用户端和后台管理端。前台页面包括登录注册页、班次查询页、下单页、我的订单页；后台管理页包括数据概览、用户管理、车辆管理、班次管理、订单管理。目录结构上，把页面放在src/views下，按user和admin分文件夹，组件放到src/components，这样逻辑清晰，写路由时也方便。

4.2 路由与请求封装：登录状态怎么贯穿全站

前端请求封装直接影响后期开发效率。我习惯在src/utils/request.js里创建一个axios实例，设置基础路径为/api，然后在请求拦截器里自动加上token：

import axios from 'axios' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = token } return config }) request.interceptors.response.use( response => response.data, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } return Promise.reject(error) } )

路由守卫也很重要。在Vue Router里加一个全局前置守卫，判断目标页面是否需要登录。如果用户没登录就访问“我的订单”“后台管理”，直接跳转到登录页。后台管理路由还要额外判断本地存的角色字段，不是管理员就提示无权限。这个逻辑能挡住大部分“没登录却能打开页面”的演示事故。

经验之谈：路由模式建议使用hash模式。history模式虽然地址栏好看，但打包后放到SpringBoot里运行时，刷新页面容易404，还需要额外配置转发规则。课设阶段别折腾这个。

4.3 前后端联调：跨域、接口对不上、参数类型不匹配

本地开发时，前端默认跑在http://localhost:3000，后端跑在http://localhost:8080，端口不同就一定有跨域问题。最简单的方案是后端写一个全局CORS配置类，允许所有来源访问；更贴近企业做法的是在前端vue.config.js里配置devServer转发，把/api开头的请求转发到后端端口。前端开发环境下请求地址写相对路径/api/user/login，这样代码里不用写死IP，后期部署到服务器也不会因为地址变了而全部改写。

联调阶段最容易遇到三类问题：后端返回的日期格式前端解析不了、后端返回的字段名和前端定义的不一致、接口路径大小写对不上。我的建议是让后端先设计一个统一的返回对象Result，所有接口都返回{ code, message, data }，前端在axios的响应拦截器里统一判断code是否为200，而不是每个页面都写一遍成功失败逻辑。日期格式则在application.yml里全局配置好，前端就不会收到“2025-06-01T12:00:00.000+00:00”这种奇怪的东西。

5. 源码部署实录：从环境检查到第一次启动成功

5.1 版本匹配：先看SpringBoot版本再选JDK

很多同学拿到源码后第一件事就是双击启动，结果一屏红色报错。大多数问题不是源码有问题，而是本机环境版本不匹配。这里列一个我实测下来比较稳的组合：

拿到一个陌生源码时，我建议先看pom.xml里的SpringBoot parent版本，再查本机java版本，两个对齐后再启动后端。如果SpringBoot版本太高（比如3.2.x），而你只有JDK8，你会看到类似“UnsupportedClassVersionError”的报错，这就是热词“springboot版本太高”背后最典型的场景。

5.2 本地启动五步走：从导入SQL到前后端跑通

把一套源码跑通，我的固定顺序是这样的，你照着做一般不会乱。

第一步，先把sql目录下的建库脚本在MySQL里执行一遍。执行前确认你用的是哪个数据库版本，脚本里如果有ENGINE=InnoDB DEFAULT CHARSET=utf8mb4这类语句，基本问题不大。如果脚本里带了外键，导入时要注意表顺序，先建父表再建子表。

第二步，修改后端application.yml里的数据库账号密码，以及MySQL 8.0和5.7的连接串差异。用5.7的话驱动可以保持com.mysql.cj.jdbc.Driver，但连接串最好同样加上useSSL=false&serverTimezone=Asia/Shanghai，能省很多莫名其妙的报错。

第三步，启动后端。在IDEA里直接运行主类，观察控制台日志，看到 “Started Application in x.xxx seconds” 就是成功了。我习惯启动后先用浏览器调一下/api/health或Swagger地址，确认接口层已经工作，再进入前端环节。

第四步，前端项目打开终端，先执行npm install，如果速度很慢或者报错，就用npm config set registry https://registry.npmmirror.com切换镜像源。安装成功后执行npm run dev，本地访问前端地址，用测试账号登录。

第五步，如果你想打包成一个单机可运行的项目，在前端项目执行npm run build，会生成dist目录，把dist里所有文件复制到后端src/main/resources/static目录下，然后重新打包后端。这样启动后端后，直接在8080端口访问就能看到前端页面，不再需要单独起前端服务。这就是“vue打包放进springboot中”的做法。

5.3 常见问题速查表：MySQL、Vue打包、端口占用一次说清

我汇总一下做这类项目最高频的报错和解决办法，很多热搜词对应的就是下面这些场景。

这里面有一个容易被忽视的坑：前端请求的接口路径如果与后端@RequestMapping斜杠不一致，比如后端是/api/user/login，前端请求了/api/users/login，会直接404。联调时一定要先用Postman或Apifox把后端接口测通，再连前端，避免两头猜。

6. 从“能交差”到“有亮点”：扩展方向与答辩准备

6.1 低成本加分扩展：选座、验证码、统计报表

基础版本做完后，如果想在答辩时压过同组同学，可以做几个“低成本高感知”的扩展。第一个是座位图选择：在班次表里加一个已售座位数组字段，前端渲染一个网格，已售座位置灰，用户选座后下单，整个演示效果瞬间就不像课设了。第二个是图形验证码：后端用Java生成图片，登录页面加一层校验，成本低但能体现你对“防机器人攻击”有意识。第三个是数据统计：用ECharts画一个“近七日售票趋势”和“热门线路Top5”，管理员首页直接出图，这在答辩时是最抢眼的画面。

这些扩展里，我个人最推荐座位图，因为它把“汽车票”这个业务特点发挥出来了。火车票、飞机票都有选座，汽车票虽然没有那么严格，但作为系统设计可以按“座位号”落地。实现上只需要在订单表增加seat_number字段，班次表增加sold_seats字段存已卖座位号，每次下单时判断目标座位是否在已卖列表里。

6.2 答辩高频问题：老师会盯着你不放的地方

答辩场上，老师不一定全程看演示，但一定会围绕几个点提问。我列一下出现概率最高的问题，以及建议回答的思路。

“你这个系统是怎么防止超卖的？”——答：使用数据库条件更新，UPDATE schedule SET remaining_seats = remaining_seats - 1 WHERE id = ? AND remaining_seats > 0，利用MySQL行锁保证同一时刻只有一个请求能扣减成功。

“用户登录的状态是怎么保存的？”——答：后端生成JWT，前端存在localStorage，请求时通过Authorization头传递，后端拦截器统一解析校验。注意不要在回答里说“session”，因为前后端分离项目用session会绕。

“订单取消后余票怎么恢复？”——答：取消订单时开启事务，先将订单状态改为已取消，再执行UPDATE schedule SET remaining_seats = remaining_seats + 1 WHERE id = ?，两步在同一事务里保证一致性。如果你没做这个功能，现在就去加上，这是老师最常设的陷阱。

“为什么用MySQL而不用MongoDB？”——答：系统数据是典型的结构化关系型数据，用户、班次、订单之间有明确关联，需要事务支持，MySQL更合适。

我个人在实际操作中的体会是，这些问题的回答不需要背得多深，但一定要把你自己写的代码里关键逻辑讲清楚。哪怕你只是用了MyBatis-Plus的selectById，也要知道它底层执行了什么SQL。老师不怕你功能少，就怕代码不是你写的。如果你准备的时间紧，优先把事务、权限、超卖这三个点弄明白，再把自己写过的类和方法过一遍，答辩基本稳了。

另外，演示的时候请一定准备好两套数据：一套空库数据用来演示后台新增班次，一套带历史订单的数据用来演示列表和图表。顺手在浏览器里开一个无痕窗口，先把用户端购票流程走完，再切换到管理员端看订单，两个角色切换得越流畅，老师对你的印象分就越高。

这套系统后续还能往很多方向扩展，比如接入真实支付接口、增加短信通知、把订单模块改成可配置的发车时间范本等等。不管你是不是毕业设计，我都建议你把下单、事务、权限这段逻辑自己动手敲一遍，因为这才是将来工作里真正会用到的东西。