机票订购系统毕业设计：数据库设计、余票扣减与状态机实战

又是一年毕业设计季，后台私信里被问得最多的题目之一，就是“基于Web的机票订购系统的设计与实现”。说实话，这个题目在计算机毕业设计里属于长青款，几乎每个学校都有学生选。但说句得罪人的话，十个做机票系统的，能有三个把“余票扣减”讲清楚就不错了。大部分人的实现是把航班、订单、用户做成增删改查的CRUD页面，演示的时候查个航班、下个单、改个状态就结束。这作为课程作业没问题，但作为“设计与实现”的毕业论文，评审老师随便追问一句“多用户同时买同一航班最后一张票怎么处理”，很多人就卡壳了。

这个题目看起来门槛不高，但机票系统的业务复杂度恰好卡在一个很微妙的位置：比图书管理、班级管理等纯信息管理类系统复杂，又不像电商秒杀那样需要完整的分布式架构。航班搜索有条件组合，下单涉及订单状态流转，机舱座位涉及余票和超卖，退改签涉及状态回退，一个完整的业务闭环刚好能把事务、并发、状态机这些核心知识点串起来。这也是为什么我每次建议学生选题目，都会把这类“中间复杂度”的系统列为首选——它既不会让你做完没东西可写，也不至于做到一半直接放弃。

这篇内容我会从一个实际能跑通、能答辩的角度出发，把这个系统的需求边界、数据库设计、核心业务逻辑、容易翻车的细节、以及答辩时可以拿出来说的亮点，一层层拆开讲。不管你打算自己从零写，还是手里已经有一份源码准备理解后去答辩，这篇都能帮你把“为什么这么做”补上。

1. 为什么选“机票订购”做毕设：它比其他管理系统多出的三块硬骨头

很多同学选题目时是冲着“机票系统”这个名字去的，觉得听起来比“学生管理系统”高级。但真正开始写代码后才发现，这个系统的难点不在界面多炫，而在三个藏在业务流程里的硬骨头。

1.1 表面上是个CRUD，实际上是个高并发微缩模型

纯信息管理系统，比如图书管理系统，核心流程是“录入、查询、修改、删除”，数据之间最多有点外键关联。但机票订购系统的核心流程是“卖”，卖就有库存，有库存就有并发。

我见过不少实现是这么做的：用户点“订购”之后，后端先SELECT一下当前航班某舱位的余票数，判断大于0，然后执行INSERT生成订单，再执行UPDATE把余票减1。这个逻辑单独走一遍完全没问题，甚至测试阶段也发现不了异常。但只要有两个人同时买最后一张票，两个请求都查到了余票是1，然后都执行了INSERT和UPDATE，最后数据库里会有两张订单，航班余票变成-1。这在业务上就是超卖。

要解决这个问题，并发的控制点必须放到数据库的原子操作上，而不是应用层的if判断。比如扣减余票的SQL写成 UPDATE flight_cabin SET remaining = remaining - 1 WHERE id = ? AND remaining > 0，利用数据库行锁保证同一时刻只有一个请求能成功更新。返回受影响行数为0，说明没抢到。

毕设系统不需要做消息队列、Redis分布式锁那套东西，但单机数据库的行锁和事务隔离机制，足够支撑一篇论文的核心创新点论述了。关键是你要能把这个场景讲清楚，让评审老师知道你不是只会写增删改查。

1.2 需求边界：哪些功能是“必须有”，哪些属于“加分项”

机票订购系统的功能范围如果没有明确界定，很容易做着做着就变成“航空公司的完整中台”。正规的在线订票系统涉及用户端、管理端、支付网关、第三方航信系统对接、行程单打印、退改签策略引擎等等。毕设不可能全做，也没必要全做。

我的建议是把系统按角色切成两半：

• 前台用户端：注册登录、航班查询、下单订购、在线支付（模拟）、订单查询、退票申请。
• 后台管理端：航班信息管理、航线管理、舱位与票价管理、订单管理（查看、出票、审核退票）、基础数据统计。

这十个功能模块足够支撑完整业务逻辑，也覆盖了数据库设计、接口设计、权限设计、事务处理这些毕设要求的核心考察点。至于选座、在线值机、接机服务、保险套餐，都属于锦上添花。如果没有十足把握，不建议在主体功能之前先做这些。

1.3 我建议的模块划分（直接抄作业版）

下面这个划分是我认为最合理的功能清单。按照这个清单开展设计，论文的“需求分析”章节差不多能直接出框架：

这样划分之后，你会发现整个系统的数据流非常清晰：航班数据驱动下单，下单驱动支付，支付驱动出票，出票之后才可能产生退票。每一个环节都有前置状态约束，这本身就是写论文时的逻辑主线。

2. 技术选型与项目骨架搭建：Spring Boot + Vue的组合怎么落地

机票订购系统的技术栈选择，直接决定了开发效率和论文的技术描述空间。我推荐一套绝大多数学校都认可、环境也好搭建的组合：后端Spring Boot，前端Vue，数据库MySQL。这个方案不是因为它最潮，而是因为它最能兼顾“开发效率”和“评审接受度”。

2.1 后端方案和前端方案的取舍

后端如果不选 Spring Boot，还有什么选择？Servlet + JSP，或者 SSM（Spring MVC + Spring + MyBatis）。Servlet + JSP 写起来太原始，所有逻辑堆在Servlet里，代码结构很难讲出“设计感”。SSM 是前几年毕设的主力，但整合配置繁琐，光是配置文件就能让新手折腾一个星期。Spring Boot 把自动配置做到位了，你只需要关注业务代码，对于毕业设计来说这是巨大的时间节省。

前端方面，纯 JSP + Bootstrap 其实也能实现，而且对后端同学来说最省事。如果你对前端不熟，我建议不要强行上 Vue。但如果你已经有一点 Vue 基础，用 Vue + Element UI 做后台管理界面，用 Vue + 原生布局做用户端页面，效果会明显高出一个档次。Vue 的工程目录结构本身也能作为论文里“前端设计”章节的素材。

我用一个对比表说明差异：

2.2 项目目录结构和启动流程

一个标准的前后端分离项目，目录组织分两块。后端部分用 Maven 管理依赖，代码按 controller / service / mapper / entity / common 分层；前端用 Vue CLI 创建工程，src 下按 views / components / api / router / store 组织。

后端项目名称比如 flight-order-system，前端项目名称比如 flight-web。本地开发时后端跑在 8080 端口，前端跑在 8081 端口并用 Vite 或 Webpack 的代理把接口请求转发到后端。

这一步最常见的问题在我看来有两个：一来数据库没建对版本，因 MySQL 8.0 的驱动写法与 5.7 不同，容易在启动时报连接失败；二来是 YAML 配置里忘了设置时区，导致插入订单时间比实际时间少 8 小时。我建议在 application.yml 中提前加好：

yaml复制server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/flight_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: 你的密码
    driver-class-name: com.mysql.cj.jdbc.Driver
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: Asia/Shanghai

mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

注意 serverTimezone=Asia/Shanghai 和 jackson 的时间配置缺一不可。前者管的是 JDBC 连接时数据库时区识别，后者管的是后端返回前端时 JSON 的格式化，少了任何一个都会在时间字段上出乱子。

2.3 从“不分层”到“一层管一件事”

代码组织方式是论文“系统设计”章节要花大篇幅写的内容。Controller 层只接收参数并返回结果，不写业务代码；Service 层处理事务和业务规则；Mapper 层通过 MyBatis-Plus 操作数据库；entity 实体类对应表结构。

很多同学写毕设时嫌分层麻烦，所有代码往 Controller 里堆，一个方法几百行。这在你调试的时候没什么，一旦要写论文里的“模块详细设计”或者画时序图，就发现自己根本没法组织描述，因为代码里根本分不清哪一段是在做校验、哪一段是在操作数据库。

我自己的习惯是Controller里只保留“收参、校验、调用Service、返回统一结构”四步。这样每个接口的代码不会超过20行，后续写接口文档也容易。如果代码写着写着发现Service里某个方法太长，就按功能拆成私有方法或者独立的Service方法。

3. 数据库设计：把“飞机、航班、舱位、订单”从生活概念变成表

数据库设计的好坏，能决定整个系统开发到后期是否想重写。我见过一个失败案例：有人把航班的所有信息直接放在一张表里，包括出发城市、到达城市、出发时间、到达时间、经济舱票价、商务舱票价、头等舱票价、三档舱位的余票数——一共30多个字段。单看表是能用的，但问题在于：如果后续要加一个“超级经济舱”，你得改表结构。而设计合理的系统，只需要往舱位字典表里加一条记录。

3.1 核心表结构与关联关系

机票系统至少应该有这几张核心表：用户表、机场/城市表、航线表、航班表、航班舱位表、乘机人表、订单表、订单乘机人关联表、支付记录表、退票记录表。其中最重要的设计，是把“航班”和“舱位”分开。

简单版的错误设计是一张航班表包含起飞时间、机型、经济舱价格和余票。正确做法是拆成两张表：

• flight（航班表）：航班号、航线ID、出发日期、出发时间、到达时间、机型。
• flight_cabin（航班舱位表）：航班ID、舱位等级（经济舱/商务舱/头等舱）、票价、余票数。

拆表的核心原因在于：同一次航班，不同舱位的价格和余票是独立的。如果合并在一行，每次修改经济舱价格还得同时考虑另外两个舱位字段，代码写起来非常拧巴。拆开后，下单时锁定的是某航班下某舱位的那一行记录，并发控制也变得更精准。

用户表、航线表和机场表相对简单，但要注意航线表不要直接用字符串存“北京-上海”，而是用出发机场ID和到达机场ID关联机场表。虽然做毕设时可以简单一点，但采用外键关联会让后期统计和数据维护方便很多，也能在论文ER图中展示出表间关系。

3.2 班期与余票为什么不能拍脑袋设计

这里提一个很容易被忽略的需求：飞机航班并不是每天都飞。比如某个航班只在周一、周三、周五执飞。如果需求里没有“按星期循环排班”的要求，那可以直接用“日期+具体航班”的方式管理，一个航班就是当天的实体。

但更常见、更贴合航空公司真实逻辑的方式，是维护一张航班计划表，里面存航线、计划起飞时间、执飞机型、执飞星期（如1,3,5）。然后管理员针对某一天的执飞，生成一个具体的航班实例。不过这个设计对毕设而言可能稍微重了一点，因为它把业务分成了“计划”和“实例”两层。

毕设时间有限的话，可以走一条折中路线：把航班直接按日期建数据，也就是每次录入一个航班时，选择的日期就是实际的起飞日期。不做循环生成。系统演示时手动录入近几天或特定日期的航班即可。论文中可以把“按周生成”作为系统的扩展设计，简单描述基于班期规则可以自动生成航班实例，这也算一个拓展亮点。

余票的处理上，我的建议是数据库只维护“剩余票数”，不要另存“总票数”。总票数可以根据机型对应座舱布局推导出来。因为每次出票和退票都是对余票做加一或减一操作，单独存总数反而容易造成数据不一致。比如余票扣了总数没扣，或者退票退了总数没加回来。

3.3 几个在数据库上容易踩的坑

第一，订单号和支付流水号不要用自增ID。自增ID有两个问题：一是容易被遍历和猜测，二是从业务角度生成订单的规则往往包含日期和随机因素。用时间戳加随机数生成主键，或者直接用雪花ID算法，能避免很多不必要的麻烦。不过如果你用MyBatis-Plus，它内置了雪花ID的生成策略，把主键策略设为 ASSIGN_ID 就行。

第二，金额字段要用 decimal，不要用 float 或 double。float 和 double 在二进制存储上有精度损失，比如金额 99.9 实际存储可能是 99.899999。票价、支付金额、退款金额全部用 decimal(10,2)，虽然毕设阶段这个精度差异不明显，但这是评审老师较喜欢挑的规范问题，值得留意。

第三，所有时间字段用 datetime，不推荐使用 timestamp。timestamp 的取值上限是2038年，存 2038 年之后的日期会直接报错。datetime 的存储范围更大，且不受数据库时区配置影响，能减少因为时区问题导致的“时间差8小时”异常。

4. 核心业务实现：从搜索航班到支付出票，链路怎么跑通

功能模块拆完之后，真正决定系统质量的是几个核心业务场景的实现细节。按一次完整的购票流程来看，至少需要跑通四条链路：航班搜索、下单锁定余票、模拟支付回调、出票或退票。每一步都有关键问题要先想明白。

4.1 航班搜索：不是简单SELECT，先想清楚查询条件

用户搜索航班时输入的条件通常是：出发城市、到达城市、出发日期。但数据库里航线表存的是机场ID，航班表存的是航线ID。所以查询要做两次关联：先根据城市名或机场名找到航线ID，再从航班表里找出当天执飞的航班列表，最后关联航班舱位表返回每个舱位的价格和余票。

一个可行的查询示例是准备好一个视图或直接在SQL里进行多表连接：

sql复制SELECT f.id, f.flight_no, r.departure_city, r.arrival_city,
       f.departure_time, f.arrival_time, f.aircraft_type,
       fc.cabin_class, fc.price, fc.remaining
FROM flight f
JOIN route r ON f.route_id = r.id
JOIN flight_cabin fc ON f.id = fc.flight_id
WHERE r.departure_city = ? AND r.arrival_city = ? AND f.flight_date = ?
ORDER BY f.departure_time

实际的“城市匹配，应按城市先搜索出所有航线和可能的中转方案；但如果是直达航班查询，上面这个SQL已经够用，也可以据此继续实现中转推荐”。如果要支持中转推荐，就需要在代码里做两次直达航班的拼接，再过滤出中转等待时间合理（1到4小时之内）的航线组合。这个功能普通管理系统没有，做出来比较容易在答辩时让人眼前一亮。

4.2 下单锁定余票：一个UPDATE解决库存超卖

下单是整个系统技术上最有含金量的环节。用户从前端提交订单请求，后端要做的逻辑是：

1. 根据航班ID、舱位等级查出航班舱位记录，锁定该记录。
2. 校验余票大于0。
3. 生成订单主记录，状态为“待支付”。
4. 扣减舱位余票。
5. 关联乘机人信息。

在实际编码时，我会建议先把扣减余票这一步单独抽象成一个带有条件的UPDATE，并让它在一个事务里率先执行。比如：

java复制@Transactional(rollbackFor = Exception.class)
public Order createOrder(CreateOrderRequest req) {
    // 1. 尝试扣减余票，利用数据库行锁防止超卖
    UpdateWrapper<FlightCabin> updateWrapper = new UpdateWrapper<>();
    updateWrapper.eq("id", req.getCabinId())
                 .gt("remaining", 0)
                 .setSql("remaining = remaining - 1");
    boolean update = flightCabinMapper.update(null, updateWrapper) > 0;
    if (!update) {
        throw new BusinessException("该舱位余票不足");
    }

    // 2. 创建订单主记录
    // 3. 保存乘机人关联信息
}

这里 gt("remaining", 0) 和 setSql("remaining = remaining - 1") 两者必须配合使用。gt 条件在UPDATE执行时就会由数据库的行锁机制保证只有一个事务能通过这个条件，因此更新成功的基本上就是抢到票的那一方。

很多人会把“查余票”和“扣余票”分成两条SQL，在Service里先查一遍再UPDATE。这种做法在并发场景下会出现超卖，因为两个事务可能同时读到余票为1，随后又都执行了UPDATE把余票扣成负数。把判断和扣减放在同一个UPDATE语句中，目的就是让整个判断过程原子化。

另外要注意的是，订单表本身的插入动作要放在扣减余票之后。假如先创建订单再扣减余票，扣减失败时订单已经插入到了数据库，还需要回滚删除，多一步操作。事务虽然能保证要么全部成功要么全部回滚，但站在阅读代码的人的视角，流程意图没有“先锁定库存、再落订单”清晰。

4.3 订单状态机：让状态流转和支付/退票/改签对齐

订单状态我建议用整型枚举存储，而不是直接存中文。存中文确实看起来很直观，但后面扩展支付宝或微信支付回调时，状态比较和条件查询都会很别扭。项目里定义一个枚举类，代码中用 0待支付、1已支付待出票、2已出票、3已取消、4已退票，数据库字段加注释说明含义。

状态设计时需要注意一个细节：退票的状态不能直接从“已出票”变成“已退票”。中间必须有一个“退票审核中”的状态。要么在订单上加状态，要么用独立的退票记录表维护退票流程。我推荐用独立的退票表，原因是最初的订单表字段会保持稳定，而且一张机票一年内可以多次申请退改签，独立表可以在后续扩展时保持一定的兼容性。

一套推荐的订单状态机如下：

• 待支付：用户下单后生成，等待模拟支付。
• 已取消：待支付状态下，用户可以主动取消，或超过15分钟未支付的系统自动取消。
• 已支付待出票：支付回调成功后进入，管理员可以执行出票操作。
• 已出票：出票成功后进入，可以申请退票。
• 退票审核中：用户提交退票申请后进入，此时订单不能再被其他操作修改。
• 已退票：管理员审核通过退票后进入，同时归还对应航班舱位的余票和支付金额。

状态机还牵涉库存回补问题：已取消和退票审核通过时，对应航班舱位的余票都要加回去。否则一单支付超时取消后，票就白白锁死了，其他用户买不到。系统里的自动取消操作，可以定时15分钟扫描所有“待支付”订单并对比创建时间与当前时间的差值，超时的执行取消和回补库存。

4.4 支付模块：没有真实支付渠道时的模拟闭环

毕业设计系统通常不会真的去对接支付宝或微信支付。一来需要营业执照和商户号，二来学生个人开发者也没法通过审核。所以需要设计一个“模拟支付”的闭环，把正常的业务流走通。

简单做法是：用户在订单列表点“去支付”，前端把订单金额展示出来，后端提供一个模拟收银台接口。输入一个支付密码或直接点“确认支付”，后端生成一条支付记录，然后立刻把预置的订单状态更新为“已支付待出票”。

更接近真实系统一点，可以主动设计一个异步回调接口。控制层定义一个“支付宝异步通知模拟接口”，在支付页面确认支付后，先跳转到一个“正在确认支付结果”的过渡动画，1到2秒后由前端再次模拟平台向该接口发起回调请求。虽然本质上都是同步完成，但从论文设计上，你是把业务系统和支付渠道解耦的。

在支付记录表中，至少要包括订单号、交易流水号、支付金额、支付方式、支付状态、回调时间和创建时间。即便毕设里不做这个接口，有一张支付记录表，也会让整个系统的数据闭环更完整，同时避免“钱付了，但找不到凭证”这类逻辑漏洞。

出票动作通常在后台管理系统中由管理员操作。这是为了贴近传统机票代理人的业务模式。当你点击“确认出票”后，系统把订单状态从“已支付待出票”改为“已出票”，并生成一个模拟的票号或票号规则。生成的逻辑可以简单到“航空公司二字码+航班号+日期+随机四位数字”。

5. 测试与排错：机票系统最容易翻车的几个场景

很多同学写代码时能正常走通一遍流程就觉得自己完工了，结果一到演示环节，或者在写论文做测试分析时，问题就暴露出来了。下面这几个场景是机票系统的高频翻车点，提前去测、主动去踩，比答辩时被打个措手不及要好得多。

5.1 并发下单压测：先把超卖打出来再修

前面提到了并发超卖问题，这里我建议你主动用并发工具去压一下。不用专门的压测环境，一台电脑就够了。

方法是先准备一个航班舱位，把余票手工改成1。然后写一个简单的测试脚本或在Postman里配置并发请求，或者直接用Java的线程池模拟10个线程同时调用下单接口。查看最终的订单数量和剩余余票。如果下单成功数大于1，那说明你的扣减逻辑还只是“查-改”模式，需要改成前面那种原子UPDATE。

毕设里通常不要求你做出高并发性能优化，但“验证系统在并发下单时不会超卖”这一条写进测试章节，直接体现你做的是工程而不是写普通作业。也建议你把压测结果截几张图，作为论文中的测试依据。

5.2 时间与跨天：航班日期常见的坑

机票系统里时间处理最容易出错的地方是“跨天”。比如一个航班起飞时间是 2025-06-01 的特价机票，它在订单数据里的搜索条件可能会被用户选择为 2025-05-31 晚上。如果做航班接口时，对日期是全等匹配，用户凌晨搜索或跨时区访问时就会遇到查不到航班的问题。

此外，航班起降时间跨天也很常见。比如出发时间23:55，到达时间次日01:20。如果你在数据库里把到达时间设计成“time”类型，只有时分秒，没有跨天标记，那么展示出来就会对用户造成误导。我用一个折中方案来规避这个问题：用 datetime 完整存储“航班日期+出发时间”和“航班日期+到达时间”。如果到达时间跨天，则录入航班时写入的到达日期自动加一天。这样处理时间计算时不依赖字符串拼凑，跨天和24小时内超长航线都能正确表示。

5.3 事务边界：回滚不全导致的数据不一致

例如用户下单买了票，在事务中需要扣余票、生成订单、保存乘机人三个操作。如果你只在某个方法上加@Transactional，而调用链内有报错却被吞掉，就有可能出现票已经扣了但订单没生成的情况；或者订单生成了但乘机人信息没保存。

一个有效的排查手段是，在Service层主动抛出一个异常，然后去数据库确认所有关联表的数据都保持原状。像订单场景可以设计为：某个乘机人年龄字段超限（比如大于100岁），应当不进行“下单成交”逻辑并按业务规则回滚所有数据，否则会出现非常棘手的数据问题。

调试时还可以在application.yml里打开SQL日志，逐条看着Hibernate或MyBatis打印的SQL执行顺序来排查问题。日志里先执行了UPDATE还是INSERT，能直观反映事务内部的操作顺序是否符合预期。

6. 让毕设从“能用”到“能答辩”的升级思路

代码能跑通只是第一步。评审老师看论文或者现场Demo时，更关注的是你呈现出的工程思维。同样一套功能，表达方式不一样，分数能差出两档。下面这几处升级空间，我认为性价比比较高，花的时间不多，但对答辩很有帮助。

6.1 展示时不光讲功能，还要讲清楚“我解决了什么问题”

答辩时不要光演示“我点了一下查询，然后航班列表出来了”。这类描述是没有信息量的。你应该把观众的注意力引到系统设计难点上，比如：

• “在航班搜索部分，为了满足用户筛选时段的需求，我实现了按早中晚三个时段聚合展示，SQL里用CASE WHEN对起飞时间做区间分组。”
• “下单模块是我最花心思的地方，这里用数据库的原子更新操作解决余票并发扣减，避免超卖。”
• “订单状态没有一个简单的状态字段，而是通过状态机约束流转，不同的操作角色只能把订单从特定状态迁移到另一个指定状态。”

顺着这些点展示，系统本身的功能也顺带演示了，而且演示的逻辑会从“点按钮”升级为“讲设计思想”。

6.2 三处我建议加上的提分功能

如果还有富余时间，系统里可以挑一两个非核心功能做深度，以下三个方向比较容易出效果，也方便展示，还具备较好的视觉反馈：

• 简易价格曲线：管理员后台维护航班舱位票价时，不同日期票价可能不同。前端以折线图或柱状图的形式展示某条航线未来7天的票价走势。前端用ECharts实现，后端只需一个按日期分组统计的接口。
• 座位锁定提示：在用户选座或仅浏览阶段，航班详情页对某些余票很少的舱位做视觉提醒。比如余票小于3张时在舱位卡片上标注“仅剩2张”，这个在真实业务中叫做库存紧迫度展示。后端返回舱位数据时根据余票自动计算提示文案，不需要额外表结构。
• 后台仪表盘：首页放一组统计卡片和图表：今日订单数、今日销售额、近7天订单趋势、热门航线TOP5。这会给评审老师很强的“完整度”感知。哪怕SQL写得比较简单，效果也比纯列表页好很多。

6.3 写在最后的开发建议

我个人做了这么多年项目，最想提醒的不是技术本身，而是项目管理的“完成策略”——尽量不要按面面俱到的顺序开发所有模块。先集中火力把“航班维护、用户下单、余票扣减、支付回调、订单状态更新”这五件事端到端跑通，让一个真实用户能够从注册到出票走完整个闭环，再往里面补后台管理、统计图表、权限角色这些外围功能。主链路完成之后，系统就已经能进行完整的整体性演示了；外围功能都是增量叠加，不会影响整体稳定性。

如果时间确实紧张，也可以在拿到现成源码的基础上，先阅读它的数据库表结构和订单状态流转逻辑，确保你能在白板上画出“用户下单后余票怎么减、支付失败后怎么回补、退票审核通过后状态怎么翻”这条链路，再谈改动和二次开发。源码是别人对问题的一种解答方式，能够用代码逻辑去还原这套流程，才是你自己对项目的理解。做毕设不是背代码，是用代码表达对业务的理解。

机票订购系统这个题目的上限弹性很大。你可以只做最基本的CRUD，也可以加入状态机、事务控制、并发扣减、数据可视化表达，最终呈现出来的系统深度和答辩效果是截然不同的。哪怕只是把“余票不超卖”“订单状态严格流转”这两个问题想透、实现好，就已经切中了真实业务的核心痛点，也足以让你的毕业设计在一堆“管理系统”里显得更有说服力。