Spring Boot + Android航空票务系统：Java毕设完整实战解析

1. 项目概述与核心需求解析

1.1 先聊聊这个毕设选题的含金量

"云上航空"这个项目名字一看就知道，核心是Java后端+移动端APP的航空票务管理系统。作为毕设题目，这个选题其实非常巧妙——它既踩中了民航出行这个高频业务场景，又完美覆盖了Java后端开发、数据库设计、移动端交互三个核心技术栈。很多同学做毕设最大的痛点就是"业务太玩具"，而航空票务天然带有多角色（乘客、管理员）、多状态（预订、支付、出票、退改）、多约束（航班库存、价格联动）的复杂业务逻辑，正好能把你的技术点全部展示出来。

这个系统的核心价值一句话就能讲清楚：让乘客通过手机APP完成航班查询、机票预订、在线支付、电子客票管理，同时让运营人员在管理端维护航班、舱位和票价信息。看上去就是"卖机票的APP"，但真正动手做的时候，你会发现它涵盖了用户认证、并发库存控制、分布式会话、订单状态机、移动端API设计等一堆硬核知识点。

话说回来，每年Java毕设空中飞着一堆"XX管理系统"，但真正能拿高分、能在答辩时讲清楚系统亮点的并不多。航空票务这个领域之所以值得做，是因为它有明确的业务闭环和真实行业痛点（比如超售风险、价格实时性、订单一致性），做的时候你能拿出真东西来讲，而不是背课本概念。

1.2 系统角色与业务闭环梳理

你拿到这个题目后，第一步千万别急着敲代码，先把角色和业务理清楚。一个标准的航空票务系统，核心用户角色一定是两个：C端乘客和B端管理员。

乘客端的核心诉求非常简单：查航班、比价格、买票、看订单。对应到功能上就是：

• 航班检索：出发城市、到达城市、出发日期三个条件组合查询，支持按价格、时段、航空公司筛选
• 在线预订：选择舱位等级（经济舱/公务舱/头等舱），填写乘机人信息，生成订单
• 票款支付：对接模拟支付通道，完成订单支付闭环
• 订单中心：查看待支付、已出票、已取消、退改签记录等状态
• 个人中心：注册、登录、常用乘机人管理、会员信息维护

管理端则是另一个视角：航班管理（增删改查）、舱位票价维护、订单审核、统计报表。毕设层面通常不需要做完整的后台管理页面，基础CRUD加上简单统计即可。

这背后的核心业务逻辑是订单状态流转。一张机票订单从创建到完结，至少要经历：待支付 → 已支付 → 出票中 → 已出票 → 已使用，同时穿插着已取消、退票申请、改签申请等分支状态。这个状态机设计的好坏直接决定了你系统的健壮程度和答辩时能讲出的深度。

我在实际做的时候，最深的体会是：不要为了追求功能数量而忽略业务链条的完整性。宁可把查询→预订→支付→出票→验票这一个闭环做扎实，也不要东做一个西做一个互不关联的模块。完整闭环意味着你的数据库表之间有关联、接口之间有调用、状态之间有流转，这正是老师最想看到的"工程能力"。

2. 技术选型与架构设计思路

2.1 Java后端为什么选Spring Boot + MyBatis组合

Java后端的技术选型，说实话到了2025年基本没有什么悬念：Spring Boot + MyBatis（或MyBatis-Plus）是绝对的主流。为什么？三个理由：

第一，Spring Boot大幅降低了配置成本。我记得当年做毕设最痛苦的就是SSH（Spring + Struts + Hibernate）时代那一堆XML配置，而Spring Boot用自动配置和starter机制把这些全都屏蔽掉了，10分钟起一个Web服务不是吹的。你花在环境搭建上的时间越少，留给业务逻辑的时间就越多。

第二，MyBatis在中小型项目里的灵活性无人能比。虽然JPA/Hibernate在对象关系映射上更"自动化"，但航空票务这种系统里大量存在多表联查、动态条件拼装（航班查询的筛选条件就是典型的动态SQL场景），MyBatis手写SQL反而更直观可控。如果你用MyBatis-Plus，还能把单表CRUD交给它，复杂的联查自己写SQL，分工特别舒服。

第三，面试和答辩的延续性好。Spring Boot + MyBatis几乎就是Java就业市场的标配技能，你毕设用的技术栈和你找工作面试准备的八股文高度重合，做一遍等于免费实习了一次。

我给你的具体版本建议是：Spring Boot 2.7.x（稳定且教程多，别一上来就追3.x，很多老教程不兼容）、MyBatis-Plus 3.5.x、JDK 1.8或11（视你本机环境而定）。全套用Maven管理依赖，Java 8语法基本够用。

2.2 移动端：原生Android还是H5混合方案

"云上航空"既然是APP，移动端方案肯定要提前定。这里有两个主流选择，我先把利弊讲透：

方案A：原生Android（Java/Kotlin）。好处是有真实的原生体验，可以调用设备能力，毕设答辩时演示"这是真实的APP安装包"会更有冲击力。但缺点是开发周期长，如果你还要写大量页面交互，加上调试时间，压力不小。

方案B：H5混合方案（WebView套壳或UniApp等跨平台框架）。开发速度快，页面用Vue/React写，一套代码跑Android和iOS，界面美化的上限高。缺点是在答辩时容易被打上"这不是真正的APP"标签，需要你有解释的底气和设计理由。

以我个人的经验和建议来说，如果你Android基础尚可，优先考虑原生Java写一个精简版APP，核心页面控制在6-8个（首页、航班列表、航班详情、下单页、订单列表、订单详情、个人中心、登录注册），每个页面用RecyclerView和CardView好好打磨，配合Material Design的控件，整体质感就很不错。页面不多，用原生Java写工作量可控，但答辩效果和真实度远胜H5套壳。

如果你选择原生Android，网络层用Retrofit + OkHttp，图片加载用Glide，JSON解析用Gson，这些常规依赖组合足够应对APP端的需求。后端接口给我按RESTful风格设计，返回统一JSON结构，移动端解析起来就不会到处磨兼容性。

2.3 数据库设计：11张核心表搞定全部业务

数据库是毕设的重中之重，我见过太多同学代码写得不错但表设计一塌糊涂，答辩时被问两句就露馅。航空票务系统最核心的数据库表我建议就这11张，不多不少，每张表都有明确的业务含义：

• user表：用户表，字段覆盖手机号、密码、昵称、头像、注册时间、状态
• airport表：机场表，存机场三字码（如PEK）、机场名称、所在城市
• flight表：航班表，航班号（如CA1831）、起降机场、起降时间、航空公司、飞行时长
• flight_season表（可选）：航班班期表，如果同一航班号每天飞行则用班期字段标记星期几执飞
• cabin_type表：舱位等级表，经济舱/公务舱/头等舱，对应不同的折扣系数和退改规则
• cabin_price表：舱位票价表，关联flight和cabin_type，存票价金额、余票数量、折扣率
• orders表：订单表，这是整个系统最核心的表，订单号（用时间戳+随机数生成）、用户ID、航班信息、舱位等级、乘机人信息、订单状态、支付状态、总价、创建时间
• passenger表：乘机人表，姓名、证件类型、证件号码、手机号
• order_passenger表：订单和乘机人的关联表，多对多关系
• payment_record表：支付流水表，记录支付渠道、支付时间、金额、第三方流水号
• admin表：管理员表，后台登录用

这里面的核心设计要点是余票数量管理。航班库存不要直接放在flight表上，而是放在cabin_price表里，因为同一个航班的不同舱位等级价格和余票都是独立的。另外，订单与航班通过"快照"方式关联（把下单时的航班、票价信息冗余到订单表中），这样即便后续航班信息变化，历史订单也不受影响——这个细节一定要记得，答辩时可以说这是"面向历史归档的冗余设计"。

SQL示例片段 -- 订单核心表结构参考 CREATE TABLE `orders` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `order_no` VARCHAR(32) NOT NULL COMMENT '订单号', `user_id` BIGINT NOT NULL COMMENT '下单用户ID', `flight_id` BIGINT NOT NULL COMMENT '航班ID', `cabin_type_id` BIGINT NOT NULL COMMENT '舱位等级ID', `flight_snapshot` TEXT COMMENT '航班信息快照JSON', `total_amount` DECIMAL(10,2) NOT NULL COMMENT '订单总金额', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '状态:0待支付,1已支付,2出票中,3已出票,4已取消,5退票中,6已退票', `create_time` DATETIME NOT NULL, `update_time` DATETIME NOT NULL ) COMMENT='订单主表';

外键关系上，建议逻辑外键而非物理外键，也就是表与表之间通过ID字段关联，但不直接在数据库层面建FOREIGN KEY约束。这样做的好处是方便后续分库分表，也避免初学者物理外键带来的死锁和级联问题，这在实际企业开发中是常见做法，答辩时也站得住脚。

3. 核心功能模块实现详解

3.1 航班余票查询：从SQL到缓存的设计

航班查询是航空票务系统的门面功能，也是压力最大的接口。用户输入出发城市、到达城市、出发日期，系统要快速返回符合条件的航班列表、各舱位价格和余票数。前端还要支持按价格排序、按时段筛选。

首次实现时，我的SQL原型大致是这个思路：

SQL示例片段 SELECT f.id, f.flight_no, a1.airport_name AS dep_airport, a2.airport_name AS arr_airport, f.dep_time, f.arr_time, f.airline, cp.price, cp.remaining_seats FROM flight f JOIN airport a1 ON f.dep_airport_id = a1.id JOIN airport a2 ON f.arr_airport_id = a2.id JOIN cabin_price cp ON cp.flight_id = f.id AND cp.cabin_type_id = 1 WHERE a1.city = #{depCity} AND a2.city = #{arrCity} AND DATE(f.dep_time) = #{date} AND cp.remaining_seats > 0 ORDER BY cp.price ASC;

这个SQL主表、关联、过滤、排序全都齐了。但实际写完后你会发现性能瓶颈：如果flight表数据量一旦上万，这种三表联查加日期函数的查询很快就慢了。这时就需要引入缓存方案。

我的做法是分两步：第一步，在应用层加一个简单的本地缓存（Caffeine或Guava Cache），以"城市+日期"为key缓存查询结果，默认5分钟过期。因为航班数据本身不是秒级变动的，5分钟缓存足够支撑高频查询流量。第二步，如果条件允许，可以用Redis缓存热门航线的航班ID列表，避免频繁穿透数据库。毕业设计层面做一个本地缓存就够讲出层次感了。

这里要特别留意机票超售问题。余票字段不能只在查询时显示，下单时必须做并发控制。最简单的方案是用数据库乐观锁：

SQL示例片段 UPDATE cabin_price SET remaining_seats = remaining_seats - 1, version = version + 1 WHERE flight_id = #{flightId} AND cabin_type_id = #{cabinTypeId} AND remaining_seats > 0 AND version = #{version};

这个UPDATE语句的意义在于：如果并发环境有两个请求同时减库存，数据库会保证只有第一个能更新成功（因为第二个的remaining_seats已经不满足大于0的条件或者版本号冲突了）。返回影响行数为1才算锁定库存成功，这行数你也一定要检查，否则就会出现超售事故。这个细节在答辩时是绝对的加分项。

3.2 订单状态机：把业务逻辑讲清楚

订单模块是整个系统最"值钱"的部分，因为它的状态流转涉及到真实的商业规则。我在设计时画了一张状态流转图（学术名叫状态机图），核心路径是：

待支付 → 已支付 → 出票中 → 已出票 → 已使用

分支路径：待支付可以取消（释放库存）；已支付后不能直接取消，只能走退票流程；已出票后支持退票申请，退票完成后库存回补。

在代码实现上，我强烈建议用这种方式：不要用一堆if-else散落在Service层到处判断状态，而是用状态枚举+状态流转合法性校验方法集中管理。

Java代码示例 public enum OrderStatus { UNPAID(0, "待支付"), PAID(1, "已支付"), TICKETING(2, "出票中"), TICKETED(3, "已出票"), CANCELLED(4, "已取消"), REFUNDING(5, "退票中"), REFUNDED(6, "已退票"), USED(7, "已使用"); private final int code; private final String desc; } // 定义合法的状态迁移 private static final Map<OrderStatus, Set<OrderStatus>> TRANSITIONS = new HashMap<>(); static { TRANSITIONS.put(UNPAID, new HashSet<>(Arrays.asList(PAID, CANCELLED))); TRANSITIONS.put(PAID, new HashSet<>(Arrays.asList(TICKETING, REFUNDING))); TRANSITIONS.put(TICKETING, new HashSet<>(Arrays.asList(TICKETED))); TRANSITIONS.put(TICKETED, new HashSet<>(Arrays.asList(USED, REFUNDING))); TRANSITIONS.put(REFUNDING, new HashSet<>(Arrays.asList(REFUNDED))); }

这样做的好处，一句话就能讲明白：状态的合法性与业务规则集中定义，不需要在Service里到处散落"如果订单状态是XX并且..."的判断，代码的可维护性明显提升。而且答辩时你说"我用状态机管理订单生命周期"这种方式，懂行的老师立刻就会点头。如果你愿意再进一步，把状态流转的操作后置处理（如支付成功后发邮件通知、出票成功后更新库存）做成监听器模式，那就更有公司级项目的味道了。

3.3 一个完整的下单流程演示

为了让你有一个更整体的把握，我把乘客下单的一个完整调用链列出来，方便你对照写代码时心里有个地图：

1. 乘客检索航班：前端提交"北京-上海，2025-06-01" → 后端查缓存/数据库，返回航班列表（含价格、余票、航空公司）
2. 进入航班详情：乘客选某个航班，查看经济舱/公务舱/头等舱的票价和退改规则
3. 提交订单：前端提交选中的航班+舱位+乘机人数组 → 后端锁定库存（使用上面那条UPDATE语句）→ 生成订单记录（状态=待支付）→ 如果有秒杀场景可以发一个延时消息15分钟后自动关闭，但毕设阶段可以不搞这么复杂，定时任务简单扫一下即可
4. 模拟支付：调用支付通道（毕设可以用一个本地模拟支付接口，直接返回支付成功）→ 更新订单状态=已支付 → 记录支付流水
5. 异步出票：可以简化成在支付成功后立刻调一个出票服务，生成票号，更新订单状态=已出票 → 同步更新乘机人的票状态
6. 订单查询：用户端查询订单列表和详情，展示当前状态

在这个流程里，第3步是整个链路的关键点，它同时涉及事务和锁两个硬核概念。我当时的做法是：在Service方法上标注@Transactional，库存扣减和订单创建要么一起成功要么一起失败；库存扣减单条UPDATE走乐观锁保证并发安全。就这么几行代码，事务+并发控制+回滚三大知识点全讲到了。

3.4 APP端核心页面职责说明

如果移动端走原生Android路线，我建议把页面数量控制在8个以内，页面质量远比数量重要。核心页面与职责建议如下表：

我特别想提醒你的是Token认证机制。APP登录后后端返回一个Token（用JWT或UUID都行），APP端用SharedPreferences保存，每次请求在拦截器（OkHttp Interceptor）中自动带上。后端用一个简单的拦截器校验Token有效性，同时把userId解析出来放入ThreadLocal供当前请求使用。这套机制是企业开发的标准做法，虽然毕设里也可以用session简单替代，但用Token的好处是前后端完全解耦、无状态、可扩展，而且回答"如何实现登录态保持""如何做身份认证"这类问题时会更加从容。

4. 实际开发中的5个重难点与排查技巧

4.1 余票并发扣减的超卖问题

这个坑我几乎可以断定每个做票务系统的人都会踩一次。现象是这样的：当两个用户几乎同时购买同一条航线的最后一张票时，两个请求都读到了remaining_seats = 1，如果扣减逻辑是"先SELECT查询余票数，在Java代码里判断大于0后再UPDATE"，那么两个请求都能通过判断，最后库存变成-1——这就是超卖。

排查和解决：查日志时你会发现两条UPDATE语句都成功了，原因就是代码没有做原子性约束。解决方案就是前面提到的那条带条件的UPDATE语句，把"剩余票数>0"这个条件变成UPDATE子句的一部分，数据库的行锁会保证只有一个请求能成功执行。另外，给cabin_price表加一个version字段做乐观锁会更稳妥，因为remaining_seats > 0在某些场景下不够（比如两张票同时买2张，余票只剩1张，条件能通过吗？不能。但如果买1张呢？能。所以条件够用。但version可以处理更多更新场景）。实际开发中我把UPDATE行数拿到后判断，如果影响行数为0立即抛异常，前端收到失败提示"余票不足"，闭环就完成了。

4.2 订单状态更新丢失更新

另一个我犯过的错误：用户连续点击支付按钮，导致支付接口被调用两次。两次请求都把订单从"待支付"改成"已支付"，从数据库结果上看好像没问题，但如果你要做退款，就会发现支付流水表里多了两条扣款记录，金额对不上了。

解决方案：支付的接口需要加上幂等处理。最简单的方案：支付前检查订单状态必须是"待支付"，并且这个检查与更新要在同一个事务里完成（你在UPDATE语句里加AND status = #{expectedStatus}条件），同时用订单号做唯一索引约束支付流水表。另外APP端的按钮也要做防重点击处理，双保险下来基本就稳了。这个坑讲出来，老师会觉得你对"并发下的幂等性"有真实的思考。

4.3 航班列表接口响应慢

第一次压测（或者你用Charles看请求耗时）时会发现航班列表接口要1.5秒到2秒，主要瓶颈出现在：多表联查没有走索引、返回字段过多包含不必要的JSON、数据库连接每次请求都重新创建没走连接池。

优化三板斧：

• 给airport.city、flight.dep_time、cabin_price.flight_id这些字段加索引，查询直接走索引扫描
• 后端返回给前端的JSON不要直接序列化整个实体类，而是用一个VO/DTO类来裁剪字段，航班列表只需要id、航班号、起降机场、起降时间、价格、余票和航空公司，其他字段全部去掉
• 使用连接池（Spring Boot默认的HikariCP，配置好maximum-pool-size和minimum-idle）

优化后实测接口耗时降到200ms以内，这个优化过程本身就是很好的答辩素材，你可以用"优化前1.5s，优化后200ms"这种有数据支撑的对比，说服力远胜空口说"我做了优化"。

4.4 APP端接口联调时的中文乱码问题

移动端请求后端接口时返回的中文经常出现乱码，这个问题的80%原因是后端接口返回的Content-Type头没有显式指定字符集，或者Android端解析时使用了错误的编码。排查方法很简单：在Android端打印响应体的字符串，或在Postman/浏览器中直接访问该接口看返回是否正常。

解决方案：在Spring Boot的配置文件中添加server.servlet.encoding.force=true强制使用UTF-8编码；同时前端Retrofit添加addConverterFactory(GsonConverterFactory.create())时确保Gson默认UTF-8。还有一个细节是URL参数拼接中文时必须先做URLEncoder.encode()编码，否则Tomcat默认的UTF-8在某些配置下会出错。这些小问题一对一记录下来，解决了一个你的工程经验就积累了一分。

4.5 订单超时未支付怎么处理

真实业务中，用户下单后如果15分钟内不支付，订单应该自动取消并释放库存。有些同学会想到用Spring的@Scheduled定时任务每分钟扫描一次待支付订单，超过15分钟就取消。这个方法本身没错，但要注意两个问题：一是每分钟全表扫描待支付订单，如果数据量大效率不高，应该加一个索引让查询走覆盖索引；二是取消订单与释放库存在同一个事务里，并且取消逻辑要满足幂等（只有状态为"待支付"的订单才能被取消并把库存回补）。

另外提一个进阶思路（毕设如果时间充裕可以做）：下单后发一个延迟消息，15分钟后检查订单是否仍在"待支付"，是就自动取消。这个方案用RabbitMQ的延迟消息或者Redisson的延迟队列都能实现。如果你在答辩时能主动说出"用延迟消息替代定时轮询是为了避免无效扫描、提升实时性"，那就是加分项里的加分项。

5. 项目亮点提炼与答辩经验分享

5.1 给项目加分的5个设计亮点

很多同学做完功能就觉得万事大吉，其实答辩时能不能拿高分，关键在于你有没有"超越课程要求的设计点"。我从自己带毕设的经验出发，总结了几个不太费力气但很亮眼的设计：

• 余票扣减的乐观锁设计：用一个UPDATE语句解决并发超卖，体现了基本的并发控制意识
• 数据库快照冗余：订单表冗余航班价格信息，保证历史订单不受后续改价影响，体现数据归档思维
• Token鉴权+拦截器：前后端分离架构下的标准认证实践，体现工程化素养
• 统一响应体结构：Result<T>包装所有接口返回，前端解析逻辑统一，便于统一异常捕获（定义好业务异常码，比如200成功、401未登录、500系统异常、400参数错误）
• 状态机管理订单状态：用枚举+迁移表集中管理状态流转合法性，替代散落的if-else

这五个点从并发、数据一致性、安全性、可维护性、可扩展性多个维度展示了你的工程意识。答辩时即使每个点只花2分钟讲，半小时的答辩时间也充实了。

5.2 GitHub管理与代码提交规范

毕设项目一定要用Git做版本管理，这不仅是为了防丢代码，答辩时很多老师会看你的Git提交记录来判断"这是不是你自己做的"。我看到太多项目整个Git历史只有一次"initial commit"，这种记录可以说没有任何工程价值。

我的建议是：从第一天就建立一个Git仓库，每次完成一个功能模块就提交一次，提交信息写清楚。比如feat: 完成航班查询接口、fix: 修复订单超时释放库存的问题、docs: 更新README部署文档。这个习惯会让你在答辩前整理代码时轻松很多，同时也是未来进入公司工作的基本功。

5.3 答辩时如何把项目讲出深度

答辩本质上是一场"技术叙事"。老师想听到的不是"我做了一个APP"，而是"你为什么这么做、遇到的问题怎么解决、方案有什么取舍"。建议你准备以下几点：

• 一张系统架构图（不用画得太复杂，但要清晰展示前端APP、后端服务、数据库三层关系，以及Redis、消息队列等中间件的位置）
• 一段核心流程的口头讲解（建议用"乘客下单"这个完整链路贯穿讲，自然引出库存、事务、状态流转这些关键点）
• 一个你真实踩过的坑（这个最有效，比如并发超卖那个案例，你说出来就变成了故事，可信度天然高）
• 三个业务规则的Why解释（比如：为什么订单表要冗余航班快照？为什么线下退款不能设计成直接删除订单？为什么不能用物理外键？把Why答好，比把What背熟重要十倍）

我在答辩现场见过两类学生，一类是上来就背PPT念接口列表，另一类是直接打开代码库从一条完整业务链路开始讲。后者往往给老师的印象更深，因为老师能看到你是真的在"理解"系统，而不是在"背诵"系统。

5.4 关于项目后续扩展的一些小思路

如果你的答辩时间充裕，或者你想在展示环节多一个"高光时刻"，可以在现有系统之上做这些低成本扩展：

• 添加一个模拟支付沙箱页面，展示回调-签名验证-状态刷新完整闭环，比单纯"本地直接返回支付成功"更有说服力
• 给航班数据引入定时同步机制，比如用一个脚本读取本地CSV数据文件初始化航班表，比一条条INSERT数据更有"数据工程"味道
• 加一个简单限流器（比如用Guava的RateLimiter对查询接口做QPS限制），在答辩时演示"当QPS超过阈值时返回友好提示"，这是高并发场景非常经典的话题

我在这里最想表达的体会就一句话：毕设的价值不在于"项目多完整"，而在于"你自己能讲多清楚"。一个你能把每个表、每个状态、每个接口的来龙去脉都讲明白的项目，远比一个大而全但草草了事的项目更有说服力。我在带学生的过程中也反复强调一个逻辑：完整做完再朝一个方向深挖一道。按照前面说的路径走，你交付的就不只是一份毕设作业，更是一份拿得出手的作品集起点。