基于SpringBoot的汽车票预订系统：从表设计到并发扣减实战解析

你是不是也接过类似这种“基于SpringBoot的XX系统”的题目？我之前做汽车票网上预订系统那阵子，真真切切体会了一把什么叫“看着简单，做着全是细节”。这个项目属于典型的管理类业务系统，核心就两件事：把车次和座位管明白，把订单和库存理清楚。听起来就是常规的增删改查，但真的动手写服务端、设计表、调接口、处理并发订票的时候，坑一个接一个。今天我就把这个系统的完整设计思路、表结构、核心代码片段、踩坑全过程整理出来，给正在做类似SpringBoot项目或者准备搞课设毕设的朋友一份能直接参考的实战记录。

1. 项目整体设计与技术选型

1.1 需求拆解：汽车票预订到底要管哪些事

拿到需求后我做的第一件事不是建项目，而是把业务流程画成了闭环。汽车票系统的角色非常清晰：前台用户、后台管理员。用户端需要注册登录、查线路、查班次、看余票、下单购票、支付（或者模拟支付）、退票、查我的订单。管理端要维护线路、车次、车辆、班次座位数、票价，还要能查看所有订单、处理退票、做简单的数据统计。

把这两条线拆开之后，我整理出了系统的基础模块：用户模块、线路模块、班次模块、订单模块、座位库存模块。很多人上来就急着写代码，结果做着做着发现需求没想清楚，返工成本很高。我这个项目在动手前专门花了两天把功能清单和字段清单列出来，后面写起来反而顺畅很多。

1.2 技术选型：为什么选SpringBoot，以及配套组件怎么搭配

技术栈是和指导老师以及几个在做Java开发的朋友商量后定的，核心考虑是两点：一是自己熟悉，二是这个技术组合在中小型业务系统里确实通用。

后端用的是SpringBoot 2.7.x，为什么不选3.x呢？因为3.x要求JDK 17，很多公司生产环境还在用JDK 8，我本地环境也是JDK 8，而且2.7.x的生态资料更完整，遇到问题更容易查到解决方案。ORM层选的MyBatis-Plus，它对单表CRUD的封装很省事，分页查询也有现成的插件，不用自己手写太多的SQL。数据库用MySQL 8.0，InnoDB引擎，事务和行级锁在处理订票扣库存的时候是刚需。权限认证这块我使用了JWT，把token存在前端，后端用拦截器校验，避免传统Session在前后端分离场景下的种种不便。

前端我用的是Vue 3加Element Plus，页面不多，主要就是用户端的首页、购票页、订单列表，管理端的后台管理。这里多说一句，如果是纯毕设或者个人练手，用Thymeleaf模板引擎也能完成，前后端分离的好处是接口清晰、页面交互更好，但多了一层联调的工作量。我选择前后端分离，主要是想完整走一遍这种开发模式，后面找工作写简历也能加分。

我还引入了两个辅助组件：一个是Redis，用来存验证码和热点班次缓存，另一个是定时任务框架，用来处理超过30分钟未支付的订单自动取消、库存回滚。这两个组件不算核心，但用上之后系统的使用体验和健壮性都提升了一个档次。

1.3 项目目录结构与开发节奏安排

项目结构我按照主流的分层方式组织：controller接收请求、service处理业务逻辑、mapper操作数据库、entity对应表结构、dto承接前端参数、vo返回给前端展示。订单号生成和JWT工具类放在utils包，全局异常处理和结果封装放在common包。这种组织结构看起来很常规，但它的好处是每个人拿到代码都能快速找到对应的位置，后续扩展功能也方便。

整个开发周期我用了一个多月，前面的需求调研和数据库设计大概一周，后端接口开发两周，前端页面一周，剩下时间用来联调、测试、部署和写文档。这里我建议所有做类似系统的人，不要一上来就写代码，先把数据库表设计好、接口文档列出来。因为表结构一旦确定，后面大部分代码都是围绕表的操作，表设计不合理，改起来比重新写还痛苦。

2. 数据库设计与核心表结构

2.1 六张核心表的字段设计与关联关系

汽车票预订系统最核心的表我设计了六张，它们之间的关联关系决定了整个业务逻辑的走向。用户表（user）存账号、密码、手机号、身份证号；线路表（route）存出发城市、到达城市、里程、票价基数；班次表（schedule）存车次编号、所属线路、出发时间、到达时间、车辆ID；车辆表（bus）存车牌号、车型、座位总数；订单表（order）存下单用户、所属班次、乘车人数、总金额、订单状态、下单时间；座位表（seat）存某个班次中每个座位的状态。

这里重点说一下班次和座位的关系。一辆车有固定的座位数，同一个班次对应一个车辆，所以座位表我是按“班次+座位号”来组织数据的。每当管理员新增一个班次，系统就自动生成这个班次对应的几十条座位记录，初始状态全部为0（可用），用户下单成功后就改成1（占用）。这样设计的好处是查询某个班次的余票数，直接查座位表统计状态为0的数量就行，非常直观。

订单表里有几个字段我特意设置了索引：用户ID、班次ID、状态、创建时间。这些字段是查询的高频入口，比如查“这个用户的所有订单”、查“这个班次的所有有效订单”，没有索引的话数据量一大就容易慢查询。我还给每个订单加了唯一的订单编号，格式是时间戳加用户ID加随机数，保证并发下也不会重复。

2.2 表设计中的三个关键坑与优化策略

第一个坑是金额字段的类型。汽车票的票价会精确到分，如果用float或double存储，计算总价时容易出现精度丢失。我统一用了decimal(10,2)，传入数据时先用BigDecimal接收，所有金额运算都用BigDecimal，避免了很多隐性bug。

第二个坑是订票数量的限制。一个用户下单时可能买多张票，订单表里我设计了“票数”和“乘车人信息”两块，乘车人信息用JSON字符串存到order_detail表，因为一个订单的乘车人数量是不固定的。这里如果设计成固定字段（乘客1、乘客2），后期扩展就很麻烦。我用了一个单独的表来存乘车人，订单表和乘车人表是一对多的关系。

第三个坑是状态字段的语义。订单状态我用了几个数字来表示：0待支付、1已支付、2已出票、3已退票、4已取消、5已完成。数字状态在数据库里存储效率高，但代码可读性差，我专门写了一个OrderStatusEnum枚举类，把数字和描述对应起来，业务代码里只允许用枚举，不允许裸写魔法数字。

附上我调整后的订单表核心字段：

3. 后端核心模块的落地实现

3.1 从被动到主动：统一返回体与全局异常处理

项目一开始我让每个Controller直接返回各种类型的对象，前端同学拿着接口文档吐槽了好几次，因为有的接口返回Map，有的返回List，格式不统一导致前端没法做统一处理。后来我重构了一次，所有接口统一返回一个Result对象，内部包含三个字段：code（状态码）、message（提示信息）、data（数据）。

正常情况下code是200，业务出错时code是500，参数校验失败返回400，未登录返回401。前端拿到任何响应都先判断code是否等于200，不再需要为每个接口单独处理错误结构。

同时我在全局配置了一个异常处理器，用@RestControllerAdvice拦截所有Controller抛出的异常。自定义的业务异常直接返回它携带的错误码和提示信息，意料之外的异常统一转成“系统繁忙，请稍后重试”，避免把异常堆栈直接暴露给用户。这样做之后，前端联调的效率提升了很多，出问题的时候通过code基本能定位是哪一类错误。

3.2 认证与登录：JWT是SpringBoot里最常见的登录校验方式

登录这块我用了JWT，流程是用户提交账号密码，后端校验通过后生成一个token返回给前端，前端把token存到localStorage，之后每次请求都在请求头带上Authorization字段。后端写了一个拦截器，在请求进入Controller之前判断token是否存在、是否有效。

拦截器的配置有个细节要特别注意。放行接口要提前规划好，比如用户注册、用户登录、线路查询、班次查询这些接口是不需要登录就能访问的，必须加入白名单，否则前端页面还没登录就被拦截了。我第一次配置的时候太懒，只放行了/login和/register，结果前端同事说查询班次接口一直返回401，排查半天才发现是拦截器配置漏了。

还有一点，JWT的密钥和过期时间我放在了application.yml里，通过@Value注解读取，没有硬编码在代码里。过期时间设置的是24小时，用户只要一天内活跃就不需要重新登录。拦截器里校验通过后，我把token里的userId解析出来存入请求域，在Controller里用一个UserContext工具类获取当前登录用户，这样每个接口都不需要前端传用户ID了，既方便又安全。

3.3 班次查询与余票统计的实现细节

班次查询是用户端使用频率最高的接口，条件包括出发城市、到达城市、出发日期，有时还要按时间段和票价排序。我在设计这个接口的SQL时，用schedule表关联route表，根据出发城市和到达城市找到对应的线路ID，再筛出当天出发时间内的班次。

余票数量这里我没有直接在班次表里存一个字段，而是实时查询“该班次状态为0的座位记录数”。虽然多一次数据库查询，但保证了数据的实时准确。当数据量上来之后，可以在Redis中缓存班次信息和余票数量，每次购票成功后异步更新缓存。我在这个项目里做了简单的Redis缓存，key是schedule:seat:{scheduleId}，value是可用的座位数，查询时优先读缓存，缓存没有命中再查数据库。

分页查询我用的是MyBatis-Plus的分页插件，在配置类里注册一个PaginationInnerInterceptor即可。这里有个容易踩的坑，分页插件必须配置数据库类型，如果不指定，它判断数据库类型可能出错，导致分页SQL生成异常。我用的配置是new PaginationInnerInterceptor(DbType.MYSQL)，问题就解决了。

3.4 下单与锁票：并发场景下的库存扣减怎么做

这个系统的核心难点，也是我调试最久的地方，就是并发订票时如何保证不超卖。最开始我用的是查座位、判断有没有空位、然后插入订单、把座位置为占用，这样一步步来，用Postman模拟两个用户同时抢同一班次的最后一张票时，两个请求都查询到了余票为1，两个订单都成功插入了，严重超卖。

后来我查了资料，把座位库存扣减改成了数据库层面原子的update语句。核心思路是：用户下单时，直接执行 UPDATE seat SET status = 1 WHERE schedule_id = ? AND status = 0 LIMIT 1，如果影响行数为1，说明成功占用了一个座位，如果影响行数为0，说明座位已经被抢光，直接提示余票不足。这条SQL利用InnoDB的行锁，两个并发事务同时执行时，后执行的那个会等待锁，然后发现条件已经不满足，影响行数变成0，自然就失败了。

这个方案的妙处在于不需要在应用层加锁，也不需要引入分布式锁，就能解决并发问题。但要注意，座位状态更新和订单创建必须放在同一个事务里，否则可能出现座位更新成功了但订单插入失败的问题。

业务代码大致是这样的：

java复制@Transactional(rollbackFor = Exception.class)
public OrderResult createOrder(CreateOrderRequest request) {
    // 1. 校验班次信息
    Schedule schedule = scheduleMapper.selectById(request.getScheduleId());
    if (schedule == null) {
        throw new BusinessException("班次不存在");
    }
    // 2. 尝试锁定指定数量的座位
    int affected = seatMapper.lockSeat(request.getScheduleId(), request.getTicketCount());
    if (affected != request.getTicketCount()) {
        throw new BusinessException("余票不足，剩余可用座位数：" + affected);
    }
    // 3. 生成订单并保存
    Order order = new Order();
    order.setOrderNo(generateOrderNo());
    // ... 设置其他字段
    orderMapper.insert(order);
    return new OrderResult(order.getOrderNo());
}

对应的Mapper SQL：

sql复制UPDATE seat SET status = 1 
WHERE schedule_id = #{scheduleId} AND status = 0 
LIMIT #{ticketCount}

注意MySQL的UPDATE语句LIMIT参数化在某些驱动下可能报错，我这里实际使用的是先加悲观锁查询可用座位ID列表，再逐条更新的方式，在生产中建议用如下稳妥写法：

sql复制-- 先查出可用座位ID
SELECT id FROM seat 
WHERE schedule_id = #{scheduleId} AND status = 0 
LIMIT #{ticketCount} FOR UPDATE;

然后在事务里逐条更新这些ID的状态，虽然多了一次查询，但用FOR UPDATE锁住行之后，并发安全性是有保障的。我在这个方法里专门加了大量的日志输出，测试并发的时候能清楚看到每个请求锁定了哪个座位ID，问题排查起来也方便。

3.5 订单超时未支付：定时任务自动取消并回滚库存

用户下单后如果一直不支付，座位会一直被占用，影响其他用户购票。所以系统里必须有一个超时关闭机制。我设定的规则是：订单创建后30分钟内未支付，订单状态自动改为已取消，已占用的座位恢复为可用状态。

实现方案是在服务启动时开启Spring自带的定时任务，每隔1分钟扫描一次订单表，找出创建时间超过30分钟且状态为待支付的订单。这里有一个关键点：处理超时订单必须谨慎，不能直接把所有符合条件的订单都取消，要注意用户可能正在支付的过程中被误杀。我结合了订单的更新时间，先尝试乐观更新订单状态，更新成功说明用户没有在支付，更新失败说明订单状态已经改变了，不需要处理。

另一种做法是用RabbitMQ的延迟队列来做超时消息，比定时扫描更实时。但考虑到项目体量不大，定时任务已经足够，而且实现成本低。在数据量大的时候，定时任务可以配合分页批量处理，每次取100条连续关单，避免一次性加载过多数据导致内存压力。

3.6 退票业务：状态流转与库存恢复的逻辑一致性

退票算是订单模块里最讲究流程的功能。用户发起退票后，我先判断订单状态是否为已支付或已出票，只有这两种状态才允许退票。然后检查当前时间是否已经超过班次发车时间，如果发车了就不允许在线退票。

退票操作分两步：先更新订单状态为已退票，再恢复座位状态为可用。这两步我同样放在了同一个事务里。这里有个容易忽视的细节：一个订单可能包含多张票，如果只退了部分票，那么占用的座位只释放对应的数量，而不是全部释放。我的做法是给订单增加一个“已退数量”字段，退票时传退几张，系统只释放对应数量的座位。

退票的退款逻辑我没有对接真实支付渠道，而是模拟了一个退款状态位。真实项目中这里要调用支付平台的退款接口，还要考虑退款失败后的补偿机制，复杂度会高很多。这也是我建议初学者在做类似系统时，可以把支付和退款做成模拟实现，把业务逻辑先跑通，等技术成熟后再对接真实渠道。

4. 前端页面与后端接口的对接实践

4.1 页面规划与Vue组件划分

前端页面我划分成了用户端和管理端两大部分。用户端主要包含注册登录页、首页（线路班次搜索）、班次列表页、订单确认页、订单列表页、订单详情页、个人中心。管理端包含登录页（管理员账号）、数据概览页、线路管理页、班次管理页、订单管理页、用户管理页。

Vue项目的目录结构上，我按功能模块来组织组件，而不是按页面路径来组织。比如和订单相关的组件放在views/order文件夹下，和班次相关的放在views/schedule文件夹下。公共组件，比如时间选择器、分页组件、状态标签，统一放在components/common目录。路由配置里我用到了路由懒加载，每个页面独立加载，首屏速度会好很多。

4.2 接口设计规范：RESTful风格与参数校验

后端接口设计遵循RESTful风格，资源用名词复数表示，动作用HTTP方法区分。比如获取班次列表是GET /api/schedules，创建订单是POST /api/orders，取消订单是PUT /api/orders/{id}/cancel，退票是PUT /api/orders/{id}/refund。

参数校验这块我使用了Spring Boot的@Validated注解配合javax.validation中的注解，在Controller接收参数时就直接校验，不需要手写一堆if判断。举个例子，创建订单接口的请求体里，scheduleId不能为空，ticketCount要在1到5之间，日期格式要匹配等，这些约束都写在DTO的字段上，省了不少代码量。

java复制public class CreateOrderRequest {
    @NotNull(message = "班次ID不能为空")
    private Long scheduleId;

    @Min(value = 1, message = "购票数量至少为1")
    @Max(value = 5, message = "单次最多购买5张票")
    private Integer ticketCount;
}

4.3 联调中三个最常见的坑

第一个坑是跨域问题。前端开发服务器运行在localhost:5173，后端在localhost:8080，端口不同必然产生跨域问题。我在后端配置了一个全局CorsFilter，允许指定的来源访问，同时允许携带认证信息。这里提醒一句，跨域配置要谨慎，不要使用通配符*，要明确列出允许的来源，否则上线之后别人也能直接调用你的接口。

第二个坑是日期格式不一致。后端返回的是LocalDateTime，默认序列化格式是2024-12-25T10:30:00这种带字母T的格式，前端展示的时候还要做转换。我在配置里加了Jackson的全局格式化，把LocalDateTime统一转成yyyy-MM-dd HH:mm:ss，前端拿到就能直接展示。

第三个坑是空值字段消失。后端某条记录的字段为null时，默认序列化会直接不输出这个字段，前端用某个字段之后发现undefined，再去看响应才发现字段不存在了。我在配置里设置了输出null字段的策略，保证字段缺失引起的问题不会在运行时才暴露。

5. 性能优化、安全防控与部署上线

5.1 查询性能优化：从全表扫描到索引覆盖

项目做完功能之后，我导入了一批模拟数据测试性能。当班次数据到几万条、订单数据到十几万条时，原来那些不带条件的查询明显变慢了。我通过慢查询日志发现，几个高频查询都没有充分利用索引。

排查之后做了两件事。第一件是我之前提到的，给查询常用的外键和状态字段创建了索引。第二件是优化了一个别SQL写法。比如统计某个线路的售出票数时，原来的SQL是先把所有相关订单查出来，再在Java代码里循环计算，这种做法数据量一多就很不靠谱。改用一条带聚合函数的SQL后，统计结果直接由数据库算好返回，速度高了几十倍。

5.2 安全性防控：密码加密、请求频率限制、接口幂等

系统的安全性我重点关注了三个方面。第一是用户密码，绝对不允许明文存储。我使用BCrypt算法做密码哈希，它是Spring Security自带的加密器，同样的明文每次生成的哈希值都不同，即使数据库泄露也无法通过彩虹表反推出原始密码。

第二是接口限流。我实现了一个简单的滑动窗口限流器，针对频繁调用的接口做限制，比如验证码发送接口一分钟只能请求一次，登录接口一分钟最多尝试五次。这个限流逻辑基于Redis实现，每次请求把当前时间戳写入一个ZSet集合，统计窗口期内的请求次数，超出则直接拒绝。这样做有效防止了恶意刷接口的行为。

第三是接口幂等性。用户点了两次“提交订单”按钮，会创建两个一模一样的订单吗？我在下单接口上加了防重逻辑：前端生成一个唯一请求编号，后端在处理前检查这个编号是否已经处理过，如果处理过就直接返回上次的结果。实现方式是Redis的SETNX命令，键就是请求编号，第一次请求成功写入，第二次请求发现已经存在就不再执行下单逻辑。

5.3 部署上线：从本地打包到云服务器运行

本地开发完成后，部署也是一个容易出问题的环节。项目打包用Maven的mvn clean package命令，打出来的jar包直接扔到服务器上运行。这里要说一下打jar包之前，必须确认application.yml里的数据库地址、密码、Redis地址都改成了服务器的实际地址，我用变量配置加Profile的方式管理本地环境和生产环境的配置。

服务器运行我用的是nohup启动方式：nohup java -jar car-ticket-system.jar > app.log 2>&1 &。日志输出到app.log文件，排查问题的时候用tail -f app.log实时查看。Nginx我配置了一层反向代理，前端打包后的静态文件放在Nginx的HTML目录，后端接口通过/api路径转发到SpringBoot进程，同时解决了静态资源访问和跨域两个问题。

部署过程中踩过的一个坑是服务器时间和数据库时间的时区不一致，导致订单超时关闭逻辑一直异常。后续我在连接数据库的URL中显式设置了serverTimezone=Asia/Shanghai，并且在服务器上统一了系统时区，问题才算是彻底解决。

6. 常见问题与排查日志速查

6.1 事务失效：同一个类里的方法调用为什么事务不生效

这个坑我印象很深。最初我写的某个Service方法里，自己调用了同类中的另一个加@Transactional注解的方法，结果事务一直没生效，数据处于不完整状态。查了资料才知道，Spring的事务是通过AOP代理实现的，同类内部的调用走的是this调用，不经过代理对象，所以事务注解不会生效。

解决方法是让两个方法都在不同类中，或者把内部调用的方法抽到另一个Service中，再或者用AopContext.currentProxy()获取代理对象来调。我推荐把核心业务逻辑拆分到独立的Service组件中，这样既符合单一职责原则，也能确保事务生效。

6.2 分页查询丢失数据：子查询排序问题

我在做订单列表分页的时候，发现排序是按照订单创建时间倒序的。刚开始直接在分页查询里用ORDER BY create_time DESC，但数据量变大后发现有些订单丢失了，翻页的时候偶尔有数据重复。这是因为MySQL的分页和排序在特定条件下会走不同的执行计划，排序不稳定时，同一行数据可能出现在不同的页中。

解决办法是在排序字段后面加上主键排序，保证排序结果的完全确定性。比如ORDER BY create_time DESC, id DESC，这样每条记录的排序位置就是唯一的了。排查这类问题的时候，我发现先看执行计划是很有帮助的，确认分页查询是否走了预期的索引。

6.3 时区问题：为什么8小时的时间偏差

出现过一次诡异的问题，后端返回的订单创建时间比实际时间晚了8个小时，显示在页面上像是晚了一整天。排查后发现是服务器系统时区是UTC，而MySQL连接时没有指定时区，程序运行时就把本地时间转换成UTC存储，读取的时候再转回来，一来一回时区信息就乱了。

解决方式是MySQL的连接URL上加上serverTimezone=Asia/Shanghai参数，同时在JVM启动参数里加上-Duser.timezone=Asia/Shanghai，双保险。还有一点，数据库中存储时间字段我全都用了datetime而不是timestamp，因为datetime不受MySQL全球时区转换的影响，处理起来更可控。

6.4 内存溢出排查：几百张图片导致的OOM

还有一个不太常见但在后台管理功能里遇到过的问题，是导出Excel报表时，一个Excel文件里塞了太多数据，导致内存溢出了。我排查后发现是导出实现里把所有数据一次性查询装载到内存，数据量大时直接把内存打满。后来改成了分批查询和写入Excel的方式，每查500条就往文件里写一次，内存占用瞬间降下来了。

这类问题在业务系统里很典型，解决思路就是避免一次性加载过多数据，凡是涉及批量处理的操作，都要考虑分页或流式处理。

7. 写在最后的个人经验提示

做这个系统最深的感触是：类似“XX预订系统”的核心其实不在界面多炫酷，而是在业务状态的流转和并发数据的准确性上。从需求分析到数据库设计，从接口开发到并发调优，每一个环节都在考验对业务的理解程度和基本功的扎实程度。我踩过事务不生效、分页排序错乱、时区偏移、线程安全问题等好几个大坑，也正是这些坑让我对SpringBoot的自动配置原理、事务传播机制、数据库锁机制有了更深入的掌握。如果你也想做类似的系统，建议不要贪快，把每张表的关系理清楚，把每个状态流转画出来，再动手写代码，后面会省心很多。