SSM框架下火车票系统设计：从CRUD到业务状态与并发控制

上周帮一个学弟看他的毕业设计，他选的是“火车票在线预订与退改签管理系统”，用的是经典的SSM框架。他拿着初步的代码问我：“哥，我这个功能都实现了，增删改查都有，但总觉得哪里不对，看起来不像一个‘系统’，更像一个作业。”

我看了下，确实如此。登录、车次列表、订票、退票，每个功能点都有，但页面之间是割裂的，用户订完票后，订单状态怎么变？退票后，座位库存怎么恢复？这些逻辑要么没有，要么写在了最表层。这其实是很多同学做这类项目时的一个通病：把“功能实现”等同于“系统设计”，只完成了数据从页面到数据库的单向流动，却忽略了业务规则、状态流转和数据一致性这些真正构成一个“系统”的骨架。

一个能跑起来的Demo和一个经得起推敲、具备基本工程素养的系统，中间差的就是对业务逻辑的深入理解和封装。今天，我们就以这个“火车票预售系统”为例，抛开那些花哨的前端特效和复杂的架构，回到业务本身，聊聊如何把一个SSM作业，打磨成一个有模有样的、体现你工程思维的项目。这不仅是毕业设计过关的秘诀，更是你从“会写代码”到“会设计系统”的关键一步。

1. 先想清楚：火车票业务的核心不是CRUD，是状态与规则

很多人一听到“管理系统”，脑子里立刻蹦出“增删改查”四个字。对于火车票系统，这确实是最基础的操作，但如果你只做到这一步，项目就失去了灵魂。火车票系统的核心复杂性，在于一系列紧密耦合的业务状态和不容出错的业务规则。

1.1 理解核心业务实体与它们的生命周期

我们首先要为系统找到几个“主角”，并理清它们的一生。

1. 车次（Train）与座位（Seat）：这是系统的资源层。一个车次有固定的车厢、座位类型（如一等座、二等座）和每个类型的总票数。这里的关键是库存管理。库存不是简单的数字，它关联着车次、日期、座位类型，并且随着订票、退票、改签实时变化。你需要一个专门的服务或方法来原子性地操作库存，确保不会超售。
2. 订单（Order）：这是用户操作的结果，也是系统的核心状态载体。一个订单的生命周期远比“已创建、已支付、已完成”复杂。它至少应该包含：
   • 待支付：用户提交订单，但尚未付款（通常有15-30分钟时限）。
   • 已支付：付款成功，座位被正式锁定。
   • 已出票：系统完成制票（可能涉及与外部系统交互，毕业设计可简化为自动变更）。
   • 已改签：用户发起了改签，原订单关闭，产生新订单。
   • 已退票：用户退票，订单关闭，座位库存释放。
   • 已过期：待支付订单超时未付，自动关闭，库存释放。
3. 用户（User）：除了基本信息，用户行为会产生购票记录、常用联系人等衍生数据，这些是提升体验的关键。

关键设计点：不要把这些状态流转的逻辑散落在各个Controller的方法里。应该提炼出一个OrderService，其中包含createOrder（创建待支付订单）、payOrder（支付并锁定座位）、cancelOrder（取消未支付订单）、refundTicket（退票）等方法。每个方法内部，严格遵循“检查状态 -> 执行业务 -> 更新状态 -> 更新库存”的流程。

1.2 封装坚不可摧的业务规则

规则是系统的法律，必须被严格遵守且集中管理。以下是一些必须考虑的规则：

• 库存规则：查票时显示的余票，必须是实时、准确的。订票时，必须使用数据库的乐观锁（如版本号version）或悲观锁（SELECT ... FOR UPDATE）来保证并发下的库存一致性，防止同一座位被卖出两次。
• 时间规则：
  • 预售期：只能购买预售期内的车票。
  • 停售时间：发车前一定时间（如30分钟）停止售票。
  • 退改签时间：发车前不同时间段，退改签手续费比例不同，甚至不可退改。
  • 支付超时：待支付订单的自动取消。
• 业务规则：
  • 一个用户同一车次同一日期是否可购买多张票？
  • 改签时，新票票价高于原票需补差价，低于原票是否退款？
  • 退票手续费如何计算（按时间阶梯）？

关键设计点：创建一个BusinessRuleValidator工具类或将这些规则作为常量定义在枚举中。在OrderService的每个方法入口处，首先调用验证器检查规则是否允许当前操作。例如，refundTicket方法里，先校验发车时间是否已过退票截止点。

把这些想清楚，并用代码严谨地实现，你的系统就从“玩具”升级为“工具”了。接下来，我们看看如何用SSM框架优雅地实现它。

2. SSM框架的角色：不是脚手架，是业务逻辑的舞台

很多同学把SSM（Spring + SpringMVC + MyBatis）用成了“配置框架”，觉得配好了就能用。实际上，这三者各有明确的职责，理解它们，你才能把上一节设计的业务逻辑安放得当。

2.1 Spring：管理你的业务“演员”和“道具”

Spring的核心是IoC（控制反转）容器。在这个项目里，你应该把所有业务逻辑的“演员”（Service、规则校验器）和“道具”（数据源、事务管理器）交给Spring来管理和装配。

• Service层是绝对的核心：你的OrderService、TrainService、UserService应该被声明为@Service。它们内部包含复杂的业务逻辑，并且可以相互注入（@Autowired）。
• 事务管理是关键保障：一次购票，可能涉及插入订单、更新库存、记录日志等多步数据库操作。这些操作必须在一个事务里，要么全成功，要么全失败。使用Spring的@Transactional注解可以轻松声明事务边界。务必在OrderService的payOrder、refundTicket等方法上添加。

@Service public class OrderServiceImpl implements OrderService { @Autowired private OrderMapper orderMapper; @Autowired private SeatInventoryMapper inventoryMapper; @Override @Transactional(rollbackFor = Exception.class) // 声明式事务 public boolean payOrder(Long orderId) { // 1. 检查订单状态是否为“待支付” Order order = orderMapper.selectById(orderId); if (!OrderStatus.PENDING_PAYMENT.equals(order.getStatus())) { throw new BusinessException("订单状态异常，无法支付"); } // 2. 检查库存（这里通常已在创建订单时预扣，支付时确认） // 3. 执行支付逻辑（模拟） boolean paySuccess = mockPaymentService.pay(order); if (paySuccess) { // 4. 更新订单状态为“已支付” order.setStatus(OrderStatus.PAID); orderMapper.updateById(order); // 5. 正式扣减库存（如果之前是预占，则转为实占；如果没预占，则直接扣减） inventoryMapper.decreaseRealInventory(order.getTrainId(), order.getDate(), order.getSeatType(), order.getQuantity()); return true; } return false; } }

2.2 SpringMVC：专注处理HTTP“对话”

Controller层应该保持“瘦”。它只负责三件事：

1. 接收请求：解析参数、验证基本格式（如@Valid）。
2. 调用Service：将业务逻辑委托给对应的Service。
3. 返回响应：封装成功或失败的数据模型。

它不应该包含任何业务逻辑、数据库操作或复杂的判断。

@RestController @RequestMapping("/api/order") public class OrderController { @Autowired private OrderService orderService; @PostMapping("/create") public ApiResponse createOrder(@RequestBody @Valid OrderCreateDTO dto) { // 1. 接收并校验参数（@Valid 负责基础校验） // 2. 调用核心业务逻辑 Long orderId = orderService.createOrder(dto); // 3. 返回统一格式的响应 return ApiResponse.success("订单创建成功，请及时支付", orderId); } @PostMapping("/{orderId}/pay") public ApiResponse payOrder(@PathVariable Long orderId) { boolean success = orderService.payOrder(orderId); if (success) { return ApiResponse.success("支付成功"); } else { return ApiResponse.fail("支付失败，请重试"); } } }

2.3 MyBatis：高效、灵活的数据“搬运工”

MyBatis的核心价值在于其灵活性。对于火车票系统这种业务逻辑复杂的项目，你会有很多复杂的查询。

• 动态SQL是利器：在TrainMapper.xml中，你可以根据用户查询条件（如出发地、目的地、日期、座位类型）动态拼接SQL，避免写多个类似的方法。

<select id="selectTrainsWithSeatInfo" resultMap="TrainWithSeatResultMap"> SELECT t.*, si.seat_type, si.total_inventory, si.available_inventory FROM train t LEFT JOIN seat_inventory si ON t.id = si.train_id AND si.date = #{queryDate} WHERE 1=1 <if test="fromStation != null and fromStation != ''"> AND t.from_station LIKE CONCAT('%', #{fromStation}, '%') </if> <if test="toStation != null and toStation != ''"> AND t.to_station LIKE CONCAT('%', #{toStation}, '%') </if> <!-- 更多条件... --> ORDER BY t.departure_time </select>

• 关联查询与结果映射：像上面这样，一次查询将车次信息和对应日期的库存信息关联出来，用<resultMap>进行映射，能极大减少数据库访问次数，提升性能。
• 注意性能：对于车次列表这种可能数据量大的查询，要考虑分页（PageHelper插件），避免一次性加载全部数据。

把框架用对地方，你的代码结构会清晰很多。但一个健壮的系统，还必须考虑那些“万一”。

3. 从“能运行”到“够稳健”：必须补上的工程化拼图

业务逻辑正确，框架使用得当，系统在理想状态下可以工作。但真实环境充满意外：网络抖动、用户误操作、并发请求。毕业设计若能体现你对这些“意外”的处理，会大大加分。

3.1 并发控制：防止库存超售的“锁”

这是火车票系统的经典面试题，也是核心难点。当多个用户同时购买同一车次最后几张票时，怎么保证不超售？

• 方案一：数据库乐观锁（推荐用于毕业设计） 在seat_inventory表增加一个版本号字段version。更新库存时，带上版本号条件。

  UPDATE seat_inventory SET available_inventory = available_inventory - 1, version = version + 1 WHERE train_id = #{trainId} AND date = #{date} AND seat_type = #{seatType} AND available_inventory > 0 AND version = #{oldVersion}

  执行后，检查受影响的行数（int updatedRows）。如果为0，说明更新失败（可能是库存不足或版本号被其他请求修改了），此时应返回“库存不足”给用户。这种方案并发度高，实现相对简单。

• 方案二：分布式锁（如Redis）（更接近生产环境） 在扣减库存前，先尝试获取一个针对“车次-日期-座位类型”的唯一锁（SET key uuid NX EX 30）。拿到锁的请求才能进行后续的查询、校验、扣减操作，操作完成后释放锁。其他请求获取锁失败则排队或直接返回“请求繁忙”。这能保证强一致性，但引入Redis增加了复杂度。

实操建议：在毕业设计中，实现乐观锁方案并清晰阐述其原理，已经足够体现你的能力。可以在Service层捕获更新失败的情况，抛出明确的异常或返回错误码。

3.2 异常与事务：保证数据干净的“回滚键”

• 统一异常处理：使用Spring的@ControllerAdvice或@RestControllerAdvice创建一个全局异常处理器。将系统异常（BusinessException）、参数校验异常（MethodArgumentNotValidException）、数据库异常等，统一捕获并转换为前端友好的ApiResponse格式返回。这能让你的接口响应规范且安全（避免泄露堆栈信息）。
• 事务边界清晰：再次强调@Transactional的使用。确保在创建订单、支付、退票这些包含多个数据库写操作的方法上，正确使用事务。并注意事务的传播行为（通常用默认的REQUIRED即可）。

3.3 基础保障：日志、缓存与安全

• 日志：在关键业务节点（订单状态变更、库存变动、支付回调）使用SLF4J记录日志。这不仅是为了调试，更是事后排查问题的依据。记录的信息要包括用户ID、订单ID、操作前状态、操作后状态等。
• 缓存：车次信息、站点信息等变动不频繁的数据，可以引入Redis或Caffeine进行缓存，减轻数据库压力，提升查询速度。例如，将热门车次的余票信息缓存几分钟。
• 安全：
  • SQL注入：MyBatis的#{}预编译方式已能很好防止，避免使用字符串拼接SQL。
  • XSS：前端渲染时对用户输入进行转义，或使用现代前端框架（如Vue、React）它们通常有内置的防护。
  • CSRF：如果使用Thymeleaf等模板引擎，Spring Security提供了内置防护。如果是前后端分离，需要在后端生成并验证Token。
  • 权限控制：使用拦截器或Spring Security实现简单的角色控制（如用户、管理员）。用户只能操作自己的订单，管理员可以管理车次。

补上这些拼图，你的系统就有了应对真实世界复杂性的初步能力。最后，我们谈谈如何让这个项目在你的简历和面试中脱颖而出。

4. 不止于完成：如何让你的项目成为面试的亮点

一个毕业设计项目，如果只是功能堆砌，在面试官眼里价值有限。但如果你能讲清楚背后的设计思考和工程实践，它就是一个绝佳的谈资。

4.1 准备你的“项目叙事线”

不要平铺直叙地介绍功能。按照“挑战 -> 设计 -> 实现 -> 优化”的逻辑来组织你的介绍。

1. 挑战：“我意识到火车票系统的核心难点在于高并发下的库存一致性和复杂的业务状态流转，而不是简单的增删改查。”
2. 设计：“因此，我重点设计了订单状态机、库存扣减的原子操作，并将业务规则集中封装。在架构上，严格遵循了Controller-Service-Mapper的分层，确保业务逻辑集中在Service层。”
3. 实现：“在实现库存扣减时，我对比了乐观锁和悲观锁，最终采用了基于版本号的乐观锁方案，在SeatInventoryMapper中实现了decreaseInventoryWithVersion方法，并在Service层处理更新失败的重试或返回。”
4. 优化与思考：“我还考虑了支付超时订单的自动取消，这里我用了一个简单的定时任务（Spring的@Scheduled）来扫描‘待支付’状态的超时订单。我也知道生产环境会用消息队列延迟处理，但在这个项目中，定时任务是一个清晰且可行的方案。”

4.2 突出你的技术选型与权衡

面试官喜欢问“为什么”。你要能解释清楚你的选择。

• “为什么用SSM而不用Spring Boot？” -> “我想更深入地理解Spring的IoC、AOP和事务管理原理，SSM需要手动配置更多，但学习曲线更清晰。我也知道Spring Boot是更高效的生产选择。”
• “为什么用MyBatis而不用JPA？” -> “火车票的查询条件多变，特别是车次查询，需要灵活的动态SQL。MyBatis的XML映射方式让我能更直观地控制复杂SQL，我觉得它更适合这个业务场景。”
• “如何处理高并发？” -> “我主要从数据库层面用乐观锁解决了库存超售问题。我也知道这是单机方案，如果流量再大，我会考虑引入Redis分布式锁，或者将库存服务拆分、做读写分离。”

4.3 展示你的代码与文档

• 清晰的代码结构：确保你的项目包结构清晰（如controller,service,dao/mapper,entity/domain,dto,utils等），命名规范。
• 关键代码片段：准备好展示你的核心Service方法、包含乐观锁的Mapper SQL、全局异常处理类等。
• 基础文档：一个清晰的README.md，写明项目简介、技术栈、核心功能、数据库设计（可以贴ER图）、如何部署和运行。这体现了你的工程素养。
• 数据库设计：准备好你的ER图，并能解释主要表（user,train,seat_inventory,order,order_item等）的设计和关联关系，特别是状态字段、版本号字段的设计意图。

记住，毕业设计是你向企业展示自己第一个“作品”的机会。它不必完美无缺，但必须体现出你发现问题、设计解决方案、并付诸实践的完整思维能力。从理清业务状态这个最本质的问题开始，用合适的框架搭建结构，再为它注入异常处理、并发控制等工程化的思想，你构建的就不仅仅是一个系统，而是你作为一名软件开发者的专业雏形。