SpringBoot民航乘机管理系统设计与实现：从需求到答辩完整指南

又是一年毕业设计的冲刺期，后台私信里被问到最多的一类问题，十有八九都长这样：老师，SpringBoot做的民航乘机管理系统到底该怎么下手，拿到源码也不知道从哪看起，答辩被问就卡壳。这个题目确实很典型，前后端分离 + 民航业务 + 多角色权限，既能体现技术栈，又不会复杂到做不完。这篇我就结合带过的不少学生项目经验，把这个“SpringBoot民航乘机管理系统”从需求拆分、业务设计、技术选型到核心代码实现，完整拆开给你捋一遍。无论你是正要选这个题目、还是手里已经有一份编号32320的源码但不知道怎么讲清楚，这篇都应该能帮你真正把它变成自己的东西。

1. 民航乘机管理系统到底在做什么：需求拆解与模块规划

1.1 毕设选题为什么总爱选民航乘机管理

先明确一件事：民航乘机管理系统不是让你做一个机场运控中心，学校里的毕业设计题目也不会真的要求你对接中航信的黑屏系统。它本质上是一个典型的多角色信息管理系统，但套了一层“乘机流程”的业务壳子，这比普通的学生管理系统、图书管理系统在选题上更讨巧的原因有三个。

第一，业务链条天然完整。从航班发布、用户查询购票、在线值机、选座、行李托运、登机口信息查询，到后台对航班、旅客、订单、公告的管理，业务范围覆盖了“产生数据-处理数据-展示数据”的全过程。做出来的系统有故事线，介绍演示时有话可讲。

第二，角色权限划分清晰。普通增删改查项目最怕答不出“设计亮点”，但乘机系统天然有旅客、值机人员、管理员等多类用户，你一旦把权限控制讲透，答辩老师通常就不再纠缠CRUD本身。

第三，数据关系复杂程度适中。航班、舱位、旅客、订单、值机记录之间既有主外键关联，又有状态流转，关系型数据库设计有发挥空间，但又不至于像电商秒杀那样需要引入分布式事务、消息队列才能说清。作为本科毕业设计，难度和深度刚好卡在一个“能独立完成又能展示水平”的区域。

那这类系统的核心需求怎么理解？一句话概括就是：让旅客能在不同阶段完成乘机手续的线上办理，让工作人员能在后台高效管理航班和旅客信息。围绕这句话，系统天然分成前台门户和后台管理两大块，前后台共用一套用户体系但功能边界完全不同。

1.2 功能模块怎么拆：四类角色、八组用例

拿到标题里的“民航乘机管理系统”时，第一个动作绝对不是打开IDE写代码，而是把角色画出来。系统功能都长在角色身上。基于最常见的业务场景，我将这个系统拆成四种角色：旅客、值机员/地勤、航班管理员、系统管理员。这里我要多说一句，很多学生照着开源项目抄一遍，里面只有管理员和用户两种角色，问题也不大，但你答不出为什么值机柜台和后台管理员权限要分开。

实际更推荐按下面这样去拆分模块：

• 门户模块（面向旅客）：航班实时查询（按出发地、目的地、出发日期）、航班详情与舱位余票展示、在线购票与退票申请、在线值机与座位选择、行程单查看、个人乘机记录、公告与乘机须知。
• 值机管理模块（面向地勤人员）：核对旅客身份、办理值机操作、座位分配/改签、行李托运登记（记录行李重量与件数）、超重行李计费、值机旅客列表。
• 航班管理模块（面向运营管理）：航班计划录入（航班号、起降城市、起降时间、机型、总座位数）、舱位配置（头等舱/经济舱/公务舱座位数和票价）、航班状态管理（计划/开放值机/登机中/已起飞/到达/取消）、延误信息发布。
• 系统管理（面向管理员）：用户管理、角色权限分配、公告资讯发布、数据统计看板（旅客量、航班量、航班客座率、退票率）、操作日志查询。

可能你也注意到了，普通毕设源码里有的模块我没有提，比如“新闻资讯”这类纯粹为了把列表CRUD塞进去而无业务内涵的模块。有当然可以，但不要让它喧宾夺主。核心功能永远围绕航班、订单、值机这三张关键业务表展开。等到你讲系统设计时，重点讲清这三张表之间的数据流转，能解释清楚旅客从看到航班到完成值机这条链路里每一步系统做了什么，答辩基本稳了。

2. 技术选型和架构设计：SpringBoot是起点不是全部

2.1 为什么选SpringBoot而不是Spring、SpringCloud

热搜词里一大片都是“springboot配置、springboot版本、springboot框架介绍”，看来这个技术栈确实是很多人的一个心结。我直接说结论：这个系统的后端用**Spring Boot 2.7.x + MyBatis-Plus + MySQL 8.x + Redis（可选）**是当前最稳、最不容易翻车的组合，没有之一。

很多学生上来就问要不要上Spring Cloud微服务。千万别。一个毕设项目搞微服务，光服务注册发现、配置中心、网关就够喝一壶，而且答辩老师一定会追问“你拆分的各个微服务之间怎么通信、数据一致性怎么保证”，到时候很难圆回来。Spring Boot的优势恰恰在于它的自动配置和起步依赖：引入一个spring-boot-starter-web就拥有了嵌入式Tomcat和Spring MVC；引入spring-boot-starter-validation就拥有了参数校验；引入一个MyBatis-Plus-Boot-Starter，单表CRUD几乎不需要写SQL。它把那些原来要手动做的一大堆框架整合操作压缩到依赖和注解之后，开发效率直线上升，特别适合毕业设计这种需要在有限时间窗口内交付完整系统的场景。

那Spring Boot版本怎么选？热词里还有一条“springboot版本太高”和“springboot jdk1.8打包到docker desktop”，这两个一起说：建议使用Spring Boot 2.7.18 + JDK 1.8。Spring Boot 3.x要求JDK 17起步，很多学校机房和毕业设计评审环境装的还是JDK 8，而且不少旧版依赖在Boot 3.x下会出现兼容问题。不要为了追新版本给自己挖坑。等你以后参加工作，项目里遇到Spring Boot 3.x再升级也不迟。毕设的核心是稳定跑起来，代码能讲清楚。

2.2 架构分层与工程结构：一份看着就专业的Maven工程布局

拿到毕设源码后，很多同学第一反应是“这么多包到底从哪看起”。这里先给一个标准的工程目录参照，你自己写或理解别人的源码都能按这个思路走：

code复制com.airline.flight
├── controller          // 控制层：接收请求、参数校验、调用service
├── service             // 业务层：核心业务逻辑
│   └── impl            // service实现类
├── mapper              // 数据访问层：MyBatis-Plus的Mapper接口
├── entity              // 数据库实体类
├── dto                 // 前端交互对象，比如请求参数、视图对象
├── config              // 配置类：拦截器、跨域、MyBatis-Plus分页插件
├── common              // 通用返回结果、异常处理、常量
├── utils               // 工具类：JWT工具、日期工具
└── FlightApplication.java  // SpringBoot启动类

分层是最传统也最好讲的Controller-Service-Mapper三层结构。有些同学看网上项目喜欢把业务逻辑直接写在Controller里，图省事。这在个人小demo里没问题，但在一个要展示和答辩的系统里，我强烈不建议。因为当评委问“你对这个值机流程的业务逻辑怎么设计的”时，你只能说“写在Controller里”，没法体现层次感。分层架构最大的好处是逻辑复用边界清晰：Controller只负责“接参数、回结果”，Service只负责“算业务”，Mapper只负责“存取数据”。改动一个环节时，不会牵一发动全身。

顺便说一句接口风格。系统前后端交互建议统一使用RESTful风格，返回结构固定为：

json复制{
  "code": 200,
  "message": "操作成功",
  "data": {}
}

所有返回都走这个统一结构。错误码规则可以约定好：200成功、400参数错误、401未登录/登录过期、403无权限、500服务端异常。这样前端拦截器只需要判断code就可以统一处理。这也会成为答辩时“工程规范性”的一个亮点。

2.3 数据库设计是重头戏：航班、订单、值机三张核心表

数据库设计这类毕设最容易踩的坑就是字段随意加、表之间该关联不关联。民航乘机管理系统里，就算你把表做成十几张，真正决定业务深度的核心表也就那么几张，我一句话概括：航班表管“有什么可以飞”，订单表管“谁买了票”，值机表管“谁已经办了手续”。这三张表串起来，就形成了系统的主线。围绕它们的还应有用户表、行李表、公告表和日志表。

先把航班表的核心字段列出来，这段数据模型在答辩中很常被深挖：

这里一定要设计好flight_status这个状态机字段。为什么强调它？因为航班的生命周期会推动后面所有业务。航班状态为“开放值机”时，旅客才能在线值机；状态为“已起飞”后，值机入口必须关闭；状态为“取消”时，所有关联订单都要可退改。状态控制不好，就会出现“飞机都起飞了旅客还能选座”这种逻辑硬伤，答辩会被一眼看穿。

订单表的核心字段设计就要考虑到“乘客信息冗余”。最简单的设计是用订单表关联用户表再关联乘客表。但真实业务里一张订单可能有多个乘机人，如果每张票都去关联表查询，会把列表接口拖慢。毕设级别我建议做一个拆开但不极端的设计：order表存订单主信息（订单号、用户id、总金额、状态），order_item表或ticket表存每一张客票（乘机人姓名、证件号、航班id、舱位等级、座位号、票价）。一次购票操作在订单主表生成一条记录，同时往客票明细表插入N条明细。这种“一对多”的订单-客票模型既能支持一个订单买两张票，又符合航空客票的业务习惯。

值机表则是业务亮点的集中载体。核心字段至少包含值机记录id、旅客id、航班id、座位号、值机柜台、办理时间、登机口、登机时间、行李托运状态。这张表把系统从“卖票的信息管理”提升到了“乘机流程的线上办理”，区别非常大。

关于表关联，我提醒一句：不要给每张表都设置外键约束。开发早期可以让Navicat或MySQL Workbench画一下逻辑外键关系方便自己理解，但实际建表时不建议加物理外键，原因很简单：MyBatis-Plus做分页、批量删除、批量插入时物理外键会影响性能，而且一旦数据顺序不对就插入失败，调试成本高。保持逻辑外键，靠Service层保证一致性，这是互联网开发的普遍实践，也符合主流项目习惯。

3. 把核心环节做稳：值机、购票到底该怎么实现

3.1 航班余票联动：别在余票字段上做裸加减

民航系统里有一个绕不开的问题，就是余票怎么不超卖。很多学生的第一版做法是：航班表里放一个remain_seats字段，用户买票时先查余票，大于0就把余票减1。这个逻辑单机、单人用没问题，但两个人几乎同时买最后一张票时，会对同一个航班同时读到余票是1，然后一起执行减1，最终余票变-1，超卖了。

解决思路有两个方向，都是可以直接写进论文和答辩的。

方向一是数据库乐观锁。在航班表增加一个version版本号字段，扣减余票的SQL写成：

sql复制UPDATE flight
SET remain_seats = remain_seats - 1, version = version + 1
WHERE id = #{flightId}
  AND remain_seats > 0
  AND version = #{version}

通过remain_seats > 0和version = #{version}两个条件，确保同一个版本只有一个人更新成功，受影响行数为0就说明没抢到票。在单机部署的毕设场景里，这一招足够应付并发量。

方向二是Redis原子减库存。如果你系统里已经引入了Redis，可以把航班的余票在航班开放售卖时预热到Redis，购票时使用decr命令做原子扣减，扣减后小于0则回滚。这种方案会在论文里更亮眼，但需要额外处理Redis和MySQL的双写一致性问题，对于基础薄弱的同学有一定成本。因此我的建议是：毕设想求稳，用乐观锁；想冲优秀，再上Redis。

还要提醒一个很多源码里你看不到的细节：余票应该是根据舱位等级分别维护。总不能经济舱满了但公务舱有票，系统却提示“本航班无票”。你可以把remain_seats拆成remain_economy_seats和remain_business_seats两个字段，也可以在舱位配置表里按flight_id + cabin_class为粒度维护库存。前者简单，后者更规范，看你想给系统的复杂度定位在哪个级别。

3.2 在线值机的座位分配：一个典型的冲突检测场景

值机选座这个功能，真正核心的不是“保存了一条座位记录”，而是“怎么保证同一个座位号在同一个航班里不会被两个旅客选到”。这是典型的唯一约束+事务控制问题。

数据库层面最简单可靠的办法是给值机表加唯一索引：

sql复制ALTER TABLE checkin
ADD UNIQUE KEY uk_flight_seat (flight_id, seat_no);

这样哪怕代码里并发没处理好，数据库也会拦住重复分配。这是最底线的防线，一定得有。业务代码层面，选座时要先检查座位是否已被占用，再执行插入，插入时捕获数据库唯一键冲突异常，把这一整套操作放在一个事务里。事务的意义在于：选座成功的同时更新值机状态、记录行李信息，任何一个环节失败全部回滚，不会出现“座位选了但值机没办上”的中间状态。

座位号本身怎么生成？民航客机座位布局一般是“排号+列号”，过道分开。比如经济舱一排6座，编号ABC DEF，其中A和F靠窗。毕设系统如果需要一个座位图，可以在前端按机型配置渲染一个二维布局，后端只存“舱位区域+排数+列号”。判断一个座位是否靠窗：经济舱A列和F列靠窗，公务舱A列和D列靠窗。不过，考虑到毕设更偏重流程逻辑，不必把机型座位布局做得非常精细，重点在于座位分配时的冲突检测逻辑，要能答清楚。

乘客值机的状态流转也要做。值机通常包含几个状态：未值机、已值机、已托运、已登机。你在值机表里可以加一个checkin_status字段，0表示未值机，1表示已值机，2表示已登机。查询航班旅客列表时，直接按标签展示是让评委一眼看懂业务的关键。

3.3 登录鉴权与多角色权限控制：可以用JWT但别滥用

民航乘机管理系统的用户分三类，接口得控制好什么角色能调什么接口。如果你在每个方法里写“如果当前用户role等于1才允许”，也不是不行，但会显得非常业余。推荐做法是Spring Boot + Spring Security或拦截器 + JWT。

先解决登录无状态问题。用户登录成功后，后端生成一个JWT令牌，令牌里放入用户id、用户名、角色编码，设置一个合理的有效期。前端请求受保护接口时在请求头带上Authorization: Bearer <token>，后端写一个拦截器统一解析令牌并放行。令牌里带角色就是权限判断的依据。在Spring Boot项目中，JWT解析和生成可以直接用io.jsonwebtoken:jjwt库，封装一个工具类大概几十行就够。

那Spring Security要不要上？我的观点比较务实：如果你的安全知识储备足够，用它没问题；如果本身对Security的过滤器链不熟，建议还是用HandlerInterceptor + 注解的方式实现权限控制。自己做拦截器就几十行配置，你能控制每一个细节，答得上“为什么这么写”；用Security出问题时，你连异常日志都看不懂，答辩非常被动。我辅导学生做毕设，很少推荐他们硬上Spring Security，除非是有经验的在工作人士。

用拦截器做权限控制的基本结构是：注册一个AuthInterceptor拦截所有/api/**请求，放行登录接口和查询航班的公开接口，然后从Header取出Token并解析，把用户信息放进ThreadLocal或Request Attribute。接着写一个@RequireRole("admin")之类的方法级注解，再配一个AOP切面或者让拦截器根据请求路径前缀判断角色，例如/admin/**必须管理员、/checkin/**必须是地勤或管理员、/order/**需要登录用户。这种方式在答辩时很容易讲清楚，面试官也比较认可。

3.4 数据统计与分析接口：别小看这几行SQL

系统管理后台如果只有用户列表和日志列表，没有统计功能会很单薄。一个客座率统计就是很好的加分项。所谓客座率，就是已售客票数除以总可售座位数。计算方式可以按航班分组统计：

sql复制SELECT f.id, f.flight_no,
       COUNT(t.id) AS sold_count,
       f.total_seats,
       COUNT(t.id) / f.total_seats AS load_factor
FROM flight f
LEFT JOIN ticket t ON f.id = t.flight_id
   AND t.ticket_status IN (1, 2)   -- 已支付或已使用
WHERE f.departure_time BETWEEN #{startTime} AND #{endTime}
GROUP BY f.id, f.flight_no, f.total_seats
ORDER BY load_factor DESC;

再配合一个ECharts前端图表把每日航班量和旅客量趋势、热门航线Top10展示出来，系统在演示阶段会非常加分。数据统计这类功能做起来不难，但很能体现你的“数据意识”。

4. 从0到1快速落地：如何把源码变成可运行项目再内化成自己的

4.1 引入依赖、配置文件的坑位怎么避

如果你手头正好拿到了32320版本的源码，先别急于双击运行。第一件事，检查pom.xml。一个标准民航乘机管理系统的核心依赖如下：

xml复制<dependencies>
    <!-- Web模块 -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <!-- MyBatis-Plus -->
    <dependency>
        <groupId>com.baomidou</groupId>
        <artifactId>mybatis-plus-boot-starter</artifactId>
        <version>3.5.3</version>
    </dependency>
    <!-- MySQL驱动 -->
    <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <scope>runtime</scope>
    </dependency>
    <!-- Lombok -->
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <optional>true</optional>
    </dependency>
    <!-- JWT -->
    <dependency>
        <groupId>io.jsonwebtoken</groupId>
        <artifactId>jjwt-api</artifactId>
        <version>0.11.5</version>
    </dependency>
</dependencies>

这里说一下MyBatis-Plus版本。3.5.x是当前比较稳定的版本，低版本的3.1.x在JDK8下虽然能用，但自动填充和分页插件的API已经过时，照着新教程写时容易出现方法找不到的报错。另外，如果你在pom里看到spring-boot-starter-data-jpa同时存在，要问自己一句：项目里到底用JPA还是MyBatis-Plus？两个一起上不是不行，但映射关系容易混乱，很多源码为了兼容不同教程把两份都引进来，完全是隐患。我在检查源码时通常会把不用的ORM依赖直接删掉。

然后是application.yml的配置。几个容易踩坑的点提醒一下：MySQL驱动的类名，MySQL 8.x对应com.mysql.cj.jdbc.Driver，如果你用的是5.x数据库，则对应com.mysql.jdbc.Driver，配错了启动直接报ClassNotFoundException。另外时区必须显式加上，否则数据库日期和时间会相差8小时，推荐配置为：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/airline_system?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
    username: root
    password: 你的密码
    driver-class-name: com.mysql.cj.jdbc.Driver

MyBatis-Plus的逻辑删除和自动填充也建议配上。逻辑删除字段deleted统一为0未删、1已删，对用户表、订单表做删除操作时就不会真的把数据物理删掉，这也是一个可以讲的安全设计点。自动填充则把create_time、update_time这两个字段的赋值交给MyBatis-Plus在插入和更新时自动完成，不需要每个Service里手动set当前时间。

配置类里还要给MyBatis-Plus加分页插件，否则你调用selectPage时会发现分页不生效：

java复制@Configuration
public class MybatisPlusConfig {
    @Bean
    public MybatisPlusInterceptor mybatisPlusInterceptor() {
        MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
        interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));
        return interceptor;
    }
}

4.2 关键代码示例：一个值机接口如何写才不业余

在手写或改编代码时，我建议把“值机办理”这个核心接口实现得足够规范。前端调用时提交航班id和乘机人信息，后端接口逻辑大概是：先校验航班是否存在且状态是否允许值机，再校验旅客的订票信息是否属于这个航班，然后选座并插入值机记录，最后更新客票状态。Controller层写法要简洁，异常交给全局处理器。

java复制@PostMapping("/api/checkin/doCheckin")
public Result<?> doCheckin(@RequestBody @Valid CheckinRequest request,
                           @RequestAttribute("currentUser") UserDTO currentUser) {
    // 校验该订单是否属于当前登录用户，避免越权
    checkinService.doCheckin(request, currentUser);
    return Result.success("值机成功");
}

Service里的实现，是面试官和答辩老师最关注的地方。核心业务必须用@Transactional包裹：

java复制@Service
public class CheckinServiceImpl extends ServiceImpl<CheckinMapper, Checkin> implements CheckinService {

    @Override
    @Transactional(rollbackFor = Exception.class)
    public void doCheckin(CheckinRequest request, UserDTO currentUser) {
        // 1. 查询航班并校验状态：必须处于“开放值机”状态
        Flight flight = flightMapper.selectById(request.getFlightId());
        if (flight == null || flight.getFlightStatus() != FlightStatus.OPEN_CHECKIN.getCode()) {
            throw new BusinessException("航班不存在或当前不可值机");
        }
        // 2. 查询客票，确认该乘客确有此航班的未值机票
        Ticket ticket = ticketMapper.selectOne(new LambdaQueryWrapper<Ticket>()
                .eq(Ticket::getFlightId, request.getFlightId())
                .eq(Ticket::getPassengerId, request.getPassengerId())
                .eq(Ticket::getTicketStatus, TicketStatus.PAID.getCode()));
        if (ticket == null) {
            throw new BusinessException("未找到该乘客的有效客票");
        }
        // 3. 查询座位是否已占用
        Long occupied = checkinMapper.selectCount(new LambdaQueryWrapper<Checkin>()
                .eq(Checkin::getFlightId, request.getFlightId())
                .eq(Checkin::getSeatNo, request.getSeatNo()));
        if (occupied != null && occupied > 0) {
            throw new BusinessException("该座位已被占用，请重新选择");
        }
        // 4. 插入值机记录
        Checkin checkin = new Checkin();
        checkin.setFlightId(request.getFlightId());
        checkin.setTicketId(ticket.getId());
        checkin.setPassengerId(request.getPassengerId());
        checkin.setSeatNo(request.getSeatNo());
        checkin.setCheckinStatus(CheckinStatus.DONE.getCode());
        checkin.setCheckinTime(LocalDateTime.now());
        this.save(checkin);
        // 5. 更新客票状态为已值机
        ticket.setTicketStatus(TicketStatus.CHECKED_IN.getCode());
        ticket.setSeatNo(request.getSeatNo());
        ticketMapper.updateById(ticket);
    }
}

你注意看这段代码的每一步，其实都在对应一个业务规则。这就不是流水账CRUD，而是能站得住脚的“业务实现”。面答老师问“值机时座位冲突怎么处理”，你就能把这里唯一索引和事务控制的思路讲出来。多写这样几个有业务含义的接口，代码量自然上去了，而且质量密度也高。

4.3 前端联调与接口文档：让系统真正跑起来的最后一公里

很多毕设源码的后端单独看没问题，但联调时会出现跨域报错。前端开发服务器跑在5173或8081端口，后端跑在8080，浏览器默认会拦截跨域请求。解决方案最简单的是后端配置一个全局CORS：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

注意allowedOriginPatterns("*")和allowCredentials(true)要配合使用，不能写allowedOrigins("*")再加allowCredentials(true)，否则部分浏览器会拒收带Cookie的跨域请求。大部分后台系统用的是Token而不是Cookie，但很多接口库和前端请求拦截器还是会默认带上凭证，这个坑我见过很多次。

如果对于接口风格还没有拿定主意，可以用springdoc-openapi自动生成Swagger文档。不过实践中有个教训：在正式演示环境要关掉Swagger，或者给Swagger路径也加上登录拦截白名单，避免暴露接口信息。之前就有学生的项目因为Swagger没关闭，演示时被提问“接口都暴露了怎么办”，一时答不上来。

5. 拿源码做毕设会遇到的坑：高频问题与答辩提醒

5.1 运行期最容易报的错以及排查路径

学生把源码拿回去跑，来问我的问题常年集中在这几个。我整理成一个排查速查表，你可以直接截图存起来。

这里多说一句数据库导入的事。源码包里通常附带一个.sql文件，导入前务必用文本编辑器打开看一眼里面的建库语句。常见的坑是源码里的CREATE DATABASE名字可能叫airline或flight_system，和你application.yml里写的不一致，直接导入后项目依然连不上库。正确做法是以application.yml里的url中数据库名为准，要么修改SQL文件里的建库名，要么修改配置文件，二者必须保持一致。

5.2 答辩高频问题：你不能只会说“这段代码是网上找的”

答辩时评委一般不会真让你从头敲代码，但他们会随机抽几个点验证你到底懂不懂。下面是民航乘机管理系统项目最容易被问的问题和思路方向：

• 航班余票怎么防止超卖？ 答乐观锁加库存字段条件更新，或者Redis原子扣减。说明清楚为什么不能只查再减。
• 值机业务流程里为什么需要事务？ 答插入值机记录和更新客票状态两步操作必须同生共死，任一步失败都应该回滚，否则会出现状态不一致。
• 系统中你设计了几种角色？同一个接口不同角色访问如何控制？ 答JWT中包含角色编码，由拦截器或自定义注解根据用户角色校验访问权限。
• 座位号怎么校验合法性？ 答座位图由前端机型配置驱动，后端校验座位是否存在并且未被占用。
• 订单和票的关系是怎样的？ 答一个订单可以包含多个乘机人，所以拆成订单主表和客票明细表，一对多关系。
• 退票后余票要不要加回来？ 答要，并且要在同一个事务内完成客票状态修改和余票字段恢复，保证数据一致性。

很多学生容易栽在“退票后余票加回来”这种小逻辑上，因为源码里它不一定有。所以我特别建议，你在熟悉源码基础上，至少自己在里面加一个“退票申请与余票回补”的功能。这能直接说明你确实是理解业务而且在原项目上做了增量开发，而不是完全照搬。

另外，软件工程过程文档和数据库设计文档最好同步准备。数据库表结构要能在Navicat中画出ER图，答辩时展示出来，哪怕老师不问，也会觉得这个学生下了功夫。系统里至少要有注释写清楚核心表字段含义，这也方便你自己回看代码时快速回忆业务。

5.3 让系统看起来有亮点的三个低成本优化

第一，给管理后台加一个数据仪表盘。统计航班的客座率、每日旅客量、航班准点率。数据不要求完全真实，可以用定时任务或脚本造一批模拟数据，重要的是图表要能跑起来。这会让项目演示的第一屏就有冲击力。

第二，给值机提醒加一个简单的短信或邮件通知（集成第三方短信在毕设里通常不用真做，但可以模拟）。比如值机办理成功后，把结果写入系统消息表，前端轮询或WebSocket推送提醒旅客。讲方案的时候说“考虑到成本，我采用了站内信方式实现”，比干巴巴的JSON返回成功显得功能更完整。

第三，日志切面。用AOP统一记录操作日志，保存到operation_log表。拦截器里记录访问的接口、用户名、IP、时间、耗时等信息。这属于工作量不大但明显提升系统“成熟感”的功能，也是体现工程能力的一个亮点。

6. 项目扩展：从毕设到可展示作品，还差哪几步

如果时间充裕，我建议在这个选题上再做两个方向的延伸，哪怕只完成其中一条，项目含金量都会上去一截。一个方向是完善线上值机流程的异常处理，比如航班延误后旅客的自动通知、值机后的退改签限制规则、行李超重的费用计算逻辑。这些功能在原系统源码里往往是缺失的，而你补上了，论文的“特色功能”章节就有了独属于你的内容，而不是全抄别人的功能列表。

另一个方向是引入缓存优化查询性能。航班的查询是系统中频率最高的操作，把热门航线、固定日期的查询结果缓存到Redis中，设置合理的过期时间，并在航班变更后主动删除缓存，降低数据库压力。写代码时重点解释为什么缓存过期时间不能太长、为什么更新航班后要清理缓存而不是修改缓存，这些都是能体现水平的技术细节。如果在此基础上再用定时任务定期同步航班状态、用WebSocket向前端推送航班状态变化，那你这个项目在本科毕设里基本达到优秀档了。

不过最后还是要提醒一句，任何扩展都要建立在把现有核心流程吃透的前提下。不要一上来就堆Redis、MQ、Elasticsearch，最后问起来哪一个都说不清。先把登录权限、订票值机、余票扣减、后台统计这条主线讲顺，再在其中选一个点深入，效果要远远好过做十个半吊子功能。系统的复杂度到能体现你的工作量为止，过多的“技术表演”只会让评委盯住你的薄弱点。

code复制### 6.1 如何把项目变成自己的作品而不是雷同源码

最终演示前，建议你把项目名字改掉、包名改掉、页脚版权改掉。这听起来土，但对答辩很关键。包名里的`com.xxx.xxx`如果和网上流传的模板一模一样，老师随手一查就撞车，而且从源码学习的角度来说，改包名、改项目名的过程本身也是帮你重新理解项目结构的过程。你会在改名时被迫看清每个类放在哪个包、哪些地方引用了旧包名、启动类扫描路径怎么配。

数据库方面也建议做一轮清理。源码自带的数据库里通常残留测试账户、测试航班和一堆脏数据。建议删除所有测试数据，重新录入一套自己能讲清楚的干净数据，比如6个航班、3个注册用户、若干订单和值机记录，数据量不大但足够演示，每个数据都能讲出业务来源。你介绍项目时如果能说“这是我录入的一个从北京到上海的航班CA1831，其中有两位乘客已值机，一位旅客选了3A靠窗座位”，远比对着满屏乱糟糟的测试数据的演示有说服力。

## 写在最后

民航乘机管理系统看起来只是普通的管理系统，但它把用户权限、订单状态机、资源冲突控制、流程状态流转这些后端开发里的基础功都用上了，这也是为什么这类选题年年在毕业设计里都不过时。踩过几次坑之后，我的体感是，完成这个项目的关键不在代码量有多大，而在于你有没有把“航班、客票、值机”这条主链路彻底理清，并让每一次状态变更都经得起老师一句“为什么”。希望你拿到源码之后，别急着交差，先按这篇把它拆开、跑通、改造，让系统最终能真正代表你的能力和思考。

最后分享一个实用小技巧：演示之前，把系统里所有涉及时间的字段统一核对一遍，起飞时间、值机开放时间、创建时间这些很容易因为本地和服务器时区不一致显示错乱。这种细节有时候比一个复杂功能更让老师印象深刻。