★ FEATURED ARTICLE 简介基于Java的机场航班起降与协调管理系统毕业设计资料包面向高校计算机专业学生及Java Web开发者可作为毕业设计选题参考、项目实训素材或答辩准备资料。压缩包总大小约84.93MB内含项目报告、答辩PPT、源代码、数据库脚本、系统截图及部署演示视频文件类型覆盖文档、代码、数据库表设计与影音资料其中项目报告完整记录了需求分析、系统架构设计、模块划分与测试优化思路答辩PPT提炼了项目核心亮点部署视频则演示了服务器环境配置、数据库导入和Web应用发布流程。已有495人学习下载是同类毕设资源中较受关注的一套。资源内容涉及Servlet/JSP、MVC设计模式、Spring框架、MyBatis持久层、MySQL数据库、前端页面、安全权限控制及部署运维等多个核心技术点通过实际航班管理业务将Java Web企业级开发流程完整串联。配合源代码与文档读者既可深入理解业务逻辑与数据交互也能按视频快速复现系统同时获得项目文档撰写和答辩表达方法资料包的各模块组织清晰整体实用性强。1. 拿到“机场航班起降与协调管理系统”这个毕设包先确认它值不值得花时间跑“机场航班起降与协调管理系统”这份基于 java 的毕设包把项目报告、答辩PPT、源代码、数据库、截图和部署视频一次配齐了属于毕设资源里包装完整、可以直接动手的类型。它的业务是航班起降动态管理、跑道与停机位资源分配、异常协调登记不复杂但足够撑起一篇毕业设计技术栈走 Spring Boot MyBatis MySQL 路线答辩老师熟悉、网上资料也好找。这份包能不能用、怎么部署、哪里容易翻车、答辩讲什么下面按实际动手顺序拆开讲。目标很直接让你一个晚上跑起来一周内改造成自己的项目样子。2. 技术栈与目录结构从项目骨架判断这份源码的成色2.1 Spring Boot MyBatis MySQL毕业设计最稳妥的三角组合机场航班起降与协调管理系统从本质上说是一个业务管理系统对这类项目选技术栈的第一原则不是新潮而是“老师能看懂、问题能搜到、部署不依赖复杂环境”。Spring Boot MyBatis MySQL 正好满足这三点。Spring Boot 把 Spring/Spring MVC 原本那些繁琐的 XML 配置收进了自动配置里项目启动只需要一个带SpringBootApplication的入口类和一个 application.yml对经验不多的学生来说出问题的概率比 SSM 时代低很多。MyBatis 则把 SQL 交回开发者手里mapper XML 里写着明确的 INSERT/UPDATE/SELECT答辩现场被问到“这条更新改的是哪张表”直接打开 XML 就能讲清楚比全自动的 JPA 映射更好解释。MySQL 更不用说几乎每台开发机器都有装起来快Navicat 连上就能看数据。相比之下纯 JSPServlet 方案在课堂练习里常见但有经验的答辩老师会追问“不用框架你自己管理连接池和事务的意义在哪”。Spring Boot 全家桶则能明确回答“它帮我处理了配置、连接池和事务管理”。前端方面这类项目常见做法是 JSP 或 Thymeleaf 配合 Bootstrap偶尔加入门级的 Vue方便做航班列表和状态标签的渲染也便于和数据库交互演示。不管压包里具体用的是哪种前端关键看后端分层是否规整接下来看目录就能判断。2.2 解压后先读哪几个文件三分钟判断项目可跑性拿到压缩包别急着双击启动先按下面这份典型的 Maven 目录结构核对一遍。缺少关键文件的项目跑起来的概率会低一半airport-management/ ├── pom.xml # Maven依赖清单看Spring Boot版本和MySQL驱动 ├── src/main/java/com/airport/ │ ├── AirportApplication.java # Spring Boot启动入口 │ ├── controller/ # 控制层接收页面请求 │ ├── service/ # 业务层状态流转与协调逻辑 │ ├── mapper/ # MyBatis的Mapper接口 │ └── entity/ # 与数据库表对应的实体类 ├── src/main/resources/ │ ├── mapper/ # MyBatis XML文件 │ ├── static/ # 前端资源含jsp页面或js/css │ └── application.yml # 端口、数据库连接、日志配置 ├── sql/ │ └── airport.sql # 建库建表与初始化数据脚本 └── 文档/ # 项目报告、答辩PPT与部署视频判断项目能不能跑我一般按三个顺序来。先看 application.yml 里的端口和数据库连接端口默认 8080数据库名、用户名、密码要和你本地对得上再看 pom.xml 里 Spring Boot 的父版本这直接决定你本机需要 JDK 8 还是 JDK 17最后打开 sql 目录下的脚本数一数建了几张表是否覆盖航班、跑道、停机位、协调日志这些核心对象。这三样都齐全项目大概率完整如果缺数据库脚本再怎么调代码都跑不通因为没有表结构MyBatis 一执行 SQL 就报 “Table doesnt exist”。另外要顺手看一眼静态资源目录里有没有截图里出现的 css 和图片。有些包会把前端资源精简过头页面能打开但样式全丢答辩现场观感很差。如果发现 static 目录几乎是空的优先补一套 Bootstrap 本地文件别依赖公共 CDN因为答辩现场不一定有外网。2.3 四类角色与业务边界先画清用例图再动手改代码毕业设计答辩时最容易被问住的一句话是“你这个系统的核心业务逻辑是什么”。机场航班起降与协调管理系统的核心业务不是普通管理系统里的单表增删改查而是“多个航班在有限的跑道、停机位资源上如何被安排和调整”。围绕这一点常见的用例设计是四类角色系统管理员维护用户账号、角色权限、机场基础数据航空公司、机场三字码。航务调度员录入航班计划执行到达/起飞动态更新分配跑道、停机位处理协调请求。值班经理查看协调记录对异常航班延误、取消、备降做最终确认。查询用户按航班号、日期、航空公司查询各班次的计划与实时状态。把这四类角色画成用例图放进项目报告答辩老师会认为你做过需求分析而不是凭空写了几个页面。后续所有代码和表结构都围绕这个边界检查有没有用户表、有没有区分角色、航班动态有没有记录操作人。只要这三点在项目报告的“业务分析”和“系统设计”两章就都能填满也方便你后期把这个骨架改造成其他领域的资源调度系统比如物流中转站或医院手术室排程换一下业务名词即可。3. 数据库设计航班起降系统的表结构与建表SQL脚本3.1 六张核心表的关系基础档案与实时动态为什么要分开这套系统的数据库设计最见功底的一点是“把航班的固定信息和实时信息分开存放”。固定信息比如航班号、所属航空公司、计划起降时间、起降机场录入航班计划后基本不变实时信息比如实际起飞时间、实际到达时间、当前占用的跑道和停机位、当前状态运行过程中会被频繁更新。如果混在一张表里每改一次状态就要更新整行既容易产生锁竞争也没法保留历史轨迹。常见做法是把核心表拆成六张用户表负责账号与权限航班信息表 flight_info 保存计划数据航班动态表 flight_dynamic 保存每一次状态变更与资源占用跑道表 runway_info 和停机位/登机口表 gate_info 是两种独立资源协调记录表 coordination_log 登记人为调整的资源分配。拆分的好处答辩时这样讲航班动态表记录了“什么时候、由谁、把什么资源从哪边变到哪边”这本身就是机场协调管理要求的审计需求也是这套系统区别于普通 CRUD 的重点。3.2 建表SQL与关键字段说明直接可以执行的初始化脚本下面是一份按 MySQL 8.0 编写的建库建表脚本取核心表为例。完整脚本一般按这个结构放在 sql 目录下字段注释都在 SQL 中写明了CREATE DATABASE IF NOT EXISTS airport_ms DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE airport_ms; -- 用户表登录账号与角色区分管理员/调度员/经理/查询用户 CREATE TABLE sys_user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE COMMENT 登录名, password VARCHAR(100) NOT NULL COMMENT MD5后的密码, real_name VARCHAR(50) COMMENT 姓名, role_code VARCHAR(20) NOT NULL DEFAULT QUERY COMMENT 角色: ADMIN/DISPATCH/MANAGER/QUERY, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, status TINYINT DEFAULT 1 COMMENT 1正常 0停用 ) ENGINEInnoDB COMMENT系统用户表; -- 航班基础信息计划数据随运行不频繁变化 CREATE TABLE flight_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY, flight_no CHAR(8) NOT NULL COMMENT 航班号如CA1234, airline VARCHAR(50) COMMENT 航空公司, depart_airport VARCHAR(10) COMMENT 起飞机场三字码如PEK, arrive_airport VARCHAR(10) COMMENT 到达机场三字码如PVG, plan_depart_time DATETIME COMMENT 计划起飞时间, plan_arrive_time DATETIME COMMENT 计划到达时间, aircraft_type VARCHAR(20) COMMENT 机型如B737, status TINYINT NOT NULL DEFAULT 0 COMMENT 0计划 1延误 2到达 3起飞 4取消, UNIQUE KEY uk_flight_no_depart (flight_no, plan_depart_time), KEY idx_depart_time (plan_depart_time) ) ENGINEInnoDB COMMENT航班基础信息表; -- 航班动态状态变更与资源占用的流水记录 CREATE TABLE flight_dynamic ( id BIGINT AUTO_INCREMENT PRIMARY KEY, flight_id BIGINT NOT NULL COMMENT 关联flight_info.id, old_status TINYINT COMMENT 变更前状态, new_status TINYINT COMMENT 变更后状态, runway_id BIGINT COMMENT 占用的跑道id, gate_id BIGINT COMMENT 占用的停机位/登机口id, operate_user_id BIGINT COMMENT 操作人对应sys_user.id, operate_time DATETIME DEFAULT CURRENT_TIMESTAMP, remark VARCHAR(200) COMMENT 变更原因如天气、流量控制, KEY idx_flight_id (flight_id), KEY idx_operate_time (operate_time), CONSTRAINT fk_dynamic_flight FOREIGN KEY (flight_id) REFERENCES flight_info (id) ) ENGINEInnoDB COMMENT航班动态与资源占用流水表;资源表的结构更简单跑道和停机位只差一个名称字段以跑道表为例CREATE TABLE runway_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY, runway_code VARCHAR(20) NOT NULL COMMENT 跑道编号如36R/18L, length_meter INT COMMENT 跑道长度单位米, occupied_flag TINYINT DEFAULT 0 COMMENT 1占用 0空闲, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINEInnoDB COMMENT跑道资源表;几个关键字段说明一下。航班号用 CHAR(8) 而不是 VARCHAR因为国际航班号通常是 2 位字母加 4 位数字的固定长度定长字符类型在等值查询上表现更好也避免 VARCHAR 尾部空格带来的匹配问题。计划时间全部用 DATETIME因为航班调度会跨天需要完整的日期时间而不是单纯的时分。状态用 TINYINT 数字枚举比字符串存储小、判断快Java 代码里对应定义一套常量。外键只建了必须的 flight_id资源表不强加外键因为协调操作会频繁更改资源占用强外键在批量更新时容易误伤业务层来做一致性控制更灵活。初始化数据建议至少插入三条一个 admin 账号密码用 MD5 或 BCrypt 加密后的字符串两条跑道记录比如 36R 和 18L以及 3 到 5 条不同状态的航班计划。有了这些数据导入后登录才能直接看到界面效果否则一进去全是空表会以为系统没跑起来。3.3 时间类型、状态枚举与索引三个容易在答辩时被追问的细节时间字段是这套系统里最容易被追问的设计点。MySQL 的 DATETIME 和 TIMESTAMP 都能存时间但 TIMESTAMP 的范围只到 2038 年而且会受时区转换影响部署时只要 MySQL 服务器和 Java 虚拟机时区不一致显示出来就会差 8 小时这就是很多项目在视频里看起来正常、到自己电脑跑就不对劲的根源之一。统一用 DATETIME 后后端按本地时区把 java.util.Date 存进去取值时按数据库字符串原样读出少一类玄学问题。状态枚举用数字做主键值。定义 0 计划、1 延误、2 到达、3 起飞、4 取消状态流转的判断逻辑收敛在 Service 层数据库里不散落字符串魔法值。索引方面航班信息的实时查询通常按“航班号 计划时间”或“起飞时间范围”来做所以建了联合唯一键 uk_flight_no_depart 和单列索引 idx_depart_time动态表随时间追加查某航班历史轨迹走 idx_flight_id查当天协调记录走 idx_operate_time。这两个查询就是项目报告“系统性能分析”那一节的两个典型用例讲清楚为什么建索引答辩基本能过关。4. 核心功能实现航班状态流转与资源协调的Java代码4.1 航班状态流转为什么单独建一张动态流水表航班从录入计划到实际起飞、到达、取消状态不是简单一个 UPDATE 就能了事。机场协调管理系统要交代“这个航班为什么会从计划变成延误”“是谁改的、什么时候改的”所以核心实现一定是一张动态流水表加一段状态机。常见做法是在 FlightServiceImpl 里写一个类似这样的方法项目包的源代码里可以对照找到Transactional public boolean updateFlightStatus(Long flightId, Integer targetStatus, Long operatorId, String remark) { FlightInfo info flightInfoMapper.selectById(flightId); if (info null) { throw new BusinessException(航班不存在); } Integer current info.getStatus(); // 状态机校验只有可流转的状态才放行 if (current 4) { throw new BusinessException(已取消航班不能再次变更状态); } if (current ! 0 targetStatus 0) { throw new BusinessException(状态不能回退到计划); } // 先写动态流水再更新主表两个操作在同一事务里 FlightDynamic dynamic new FlightDynamic(); dynamic.setFlightId(flightId); dynamic.setOldStatus(current); dynamic.setNewStatus(targetStatus); dynamic.setOperateUserId(operatorId); dynamic.setRemark(remark); dynamic.setOperateTime(new Date()); int i flightDynamicMapper.insert(dynamic); int j flightInfoMapper.updateStatus(flightId, targetStatus); return i 0 j 0; }这段代码的逻辑分三层看。第一层是事务边界方法加Transactional确保“写流水 改主表”要么都成功要么都回滚否则会出现动态表记录已经变了、航班主表状态还是旧值的不一致。第二层是状态机校验两个 if 拦截了最典型的非法流转取消的航班不许再改、已进入执行的航班不许退回计划。第三层是审计字段remark 记录变更原因答辩时可以说这是对接机场运行手册里“异常情况必登记”的规则。targetStatus 为 2 表示到达、3 表示起飞、1 表示延误Controller 层可以只开放按钮对应的目标状态保证非法值进不到 Service。4.2 跑道冲突检测一段可以直接抄的区间重叠判断这套系统最重要的业务价值是防止两架飞机在同一时间段被分到同一条跑道或同一个停机位。这个功能的代码层面就是一个时间区间重叠判断两个时间段出现重叠的充要条件是一个区间的开始时间早于另一个的结束时间同时一个区间的结束时间晚于另一个的开始时间。很多同学会写出一堆 if-else 分支其实核心就是下面这个方法public boolean checkRunwayConflict(Long runwayId, Date startTime, Date endTime, Long excludeFlightId) { // 查出该跑道当前处于占用状态的动态记录 ListFlightDynamic activeList flightDynamicMapper.selectActiveListByRunway(runwayId); for (FlightDynamic dynamic : activeList) { if (dynamic.getFlightId().equals(excludeFlightId)) { continue; // 排除自己处理改跑道但时间不变的场景 } Date occupiedStart dynamic.getPlanStartTime(); Date occupiedEnd dynamic.getPlanEndTime(); // 区间重叠判断的核心条件 if (startTime.before(occupiedEnd) endTime.after(occupiedStart)) { return true; // 存在冲突 } } return false; }这段代码有两个要点。第一selectActiveListByRunway 并不是查全表再遍历而是在 Mapper XML 里通过 SQL 条件只查出“当前占用中”的记录比如 WHERE runway_id #{runwayId} AND occupied_flag 1把过滤下推到数据库减少 Java 内存里的无效遍历。第二excludeFlightId 参数用来排除当前这趟航班自己因为在“给已经占用的航班调整跑道”场景中如果不排除自己系统永远会提示冲突这是个很容易复现的逻辑坑。页面层分配跑道时先调用此方法做预校验冲突就弹提示并拒绝提交不冲突才进入后面的协调事务。配套地在协调操作完成后要给冲突检测方法准备一个“释放时间”的更新入口。也就是跑道占用记录结束时把 occupied_flag 置回 0否则第一次分配后跑道永久显示占用后面所有航班都分不进去。毕业设计的演示环节里这一步最容易被评委点出来务必要在 Service 里闭环。4.3 协调操作的事务控制改资源、写日志必须是一个完整动作“协调”在业务上就是一次资源再分配。一次典型的协调操作把 CA1234 从跑道 36R 调整到 18L原跑道释放停机位从 3 号改到 5 号同时登记“流量控制”备注。这涉及对 flight_dynamic 插入新记录、对 runway_info 更新占用标记、对 gate_info 更新占用标记以及向 coordination_log 插入一条协调记录四步必须全部成功否则会出现“飞机已经换了跑道但数据库里还写着老跑道”的尴尬局面Transactional(rollbackFor Exception.class) public void assignRunway(Long flightId, Long runwayId, Long gateId, Long operatorId, String reason) { // 1. 业务校验目标资源是否存在且当前空闲 RunwayInfo runway runwayInfoMapper.selectById(runwayId); GateInfo gate gateInfoMapper.selectById(gateId); if (runway null || gate null || runway.getOccupiedFlag() 1 || gate.getOccupiedFlag() 1) { throw new BusinessException(目标跑道或停机位不可用); } // 2. 释放旧资源 Long oldRunwayId flightDynamicMapper.getCurrentRunwayId(flightId); if (oldRunwayId ! null) { runwayInfoMapper.updateOccupied(oldRunwayId, 0); } // 3. 占用新资源 runwayInfoMapper.updateOccupied(runwayId, 1); gateInfoMapper.updateOccupied(gateId, 1); // 4. 更新航班动态并登记协调记录 flightDynamicMapper.updateCurrentResource(flightId, runwayId, gateId); coordinationLogMapper.insert(new CoordinationLog(flightId, operatorId, reason, new Date())); }这里的rollbackFor Exception.class是很关键的参数。Spring 默认只在 RuntimeException 时回滚检查异常不会回滚。如果漏掉 rollbackFor自定义的 BusinessException 如果不继承 RuntimeException事务也会静默失效从而出现“日志没写但资源已变更”的隐患。我一般会把 BusinessException 直接继承 RuntimeException在全局异常处理器中转成 JSON 提示这样 Controller 层不用到处 try-catch。另外注意事务的调用边界这个事务方法写在 Service 类里外部 Controller 调用才生效。如果在同一个类里通过 this 调用另一个Transactional方法事务会失效这是 Spring AOP 代理的经典坑。答辩老师问到“事务为什么没生效”时你可以主动把这个机制讲出来反而会给项目加分因为这说明你踩过坑、知道底层原理。5. 部署与运行避坑从源代码到跑起来最常见的5个坎5.1 启动报错 Communications link failureMySQL版本与连接URL不匹配第一次运行最常见的失败是控制台刷出“Communications link failure”和“The last packet successfully received from the server was xxx milliseconds ago”。这行报错让不少同学误以为 MySQL 服务没启动其实绝大多数情况下是数据库连接参数不对。原因有两个层面项目里设置的是 MySQL 5.x 时代的连接方式而本地装的是 MySQL 8.0驱动类从 com.mysql.jdbc.Driver 变成了 com.mysql.cj.jdbc.Driver同时 MySQL 8 默认要求显式指定时区和 SSL 行为旧 URL 没带这些参数就会被拒绝。解决方式是打开 application.yml把连接字符串改成jdbc:mysql://localhost:3306/airport_ms?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8并确认 pom.xml 里的 mysql-connector-java 版本是 8.0 以上。顺手核对用户名和密码是否与本地一致。这里最直观的验证方式先用 Navicat 手工连一次同一个库Navicat 能连上而 Java 连不上重点排查 URL 参数两边都连不上那就是 MySQL 服务本身没起或密码错了。5.2 Tomcat端口被占用一个总能遇到的翻车现场Spring Boot 内嵌 Tomcat 默认占用 8080 端口。如果本机已经开了别的服务启动日志会明确报“Port 8080 was already in use”。排查路径比较固定Windows 下执行netstat -ano | findstr 8080找到占用端口的 PID再到任务管理器结束对应进程Linux 或 macOS 习惯用lsof -i:8080。嫌麻烦就直接改端口在 application.yml 里加一行 server.port: 8081改完重新启动。这里要顺带提醒一个部署视频里常见的认知混淆Spring Boot 项目打包成 jar 后用java -jar airport-management.jar直接启动即可不需要再装独立的 Tomcat。如果项目打成 war 包再丢进外部 Tomcat需要把 spring-boot-starter-tomcat 的 scope 设为 provided否则里外两个容器会起冲突。看到包里有部署视频先确认它演示的是 jar 启动还是 war 部署照对应方式操作别混着来。5.3 中文全部变成问号编码问题的三处检查点航班管理系统里的航空公司名称、机场名称全是中文部署后最常见的翻车现场是航班号里的英文和数字正常中文列在页面上全是“???”。这属于老生常谈的编码问题按三处位置依次检查。第一处是连接串上的 characterEncodingutf8缺这个参数时Java 到 MySQL 的传输环节可能用了默认字符集第二处是表和库本身的字符集建库脚本要明确写 utf8mb4如果建库时误选了 latin1后面想转回来就是一场数据清洗第三处是前端页面JSP 需要 pageEncodingUTF-8 和 contentType 里的 charsetUTF-8静态 HTML 看 meta 标签里的 charset。判断到底是哪一处的技巧先用 Navicat 往表里直接插入一条中文数据再用 Java 代码查询如果页面显示正常说明前端没问题而是写入链路编码错了如果 Navicat 手动插入也乱码问题出在表字符集需要执行ALTER TABLE xxx CONVERT TO CHARACTER SET utf8mb4。一次排查下来基本能消除这个看不见的黑匣子。答辩现场若被问到乱码能说出这三处检查点印象分不会差。5.4 SQL脚本导入一半失败先看字符集再看外键顺序把 sql 目录下的初始化脚本导入数据库时经常看到错误在某个位置中断前面的表建好、后面的表没建。最常见的两个原因一个是脚本文件本身是 UTF-8 编码而导入工具按 GBK 打开导致注释里的中文变成非法字符在中途报错另一个是脚本里有 DROP TABLE 和 CREATE TABLE 交织如果表之间存在外键后建的表引用了还没建成的表就会报外键相关错误。解决方式比较简单用 Navicat 导入时在高级选项里明确选择 UTF-8 编码如果报外键错误就手动调整执行顺序先建不依赖别人的基础表 sys_user、runway_info、gate_info、flight_info再建有外键的 flight_dynamic 和 coordination_log。更稳妥的做法是用命令行导入报错信息比图形化工具更直接能看到具体停在哪一行。常用命令就一条mysql -uroot -p airport_ms sql/airport.sql导入成功后马上用SHOW TABLES;数一遍表数量再执行SELECT COUNT(*) FROM sys_user;验证初始化数据是否写进去了。这一步能避免启动项目后因为某张表缺失而报 “Table airport_ms.flight_dynamic doesnt exist”那种错误排查起来比建表麻烦得多。5.5 本地JDK版本与项目不对应改配置三分钟排查两小时源代码导入开发工具后大量“程序包 org.springframework.boot 不存在”“Cannot resolve symbol Java”的红色报错十有八九不是代码问题而是 JDK 和项目要求不匹配。Spring Boot 2.7 系列的父依赖要求 JDK 8 或 11Spring Boot 3.x 必须 JDK 17 以上。如果你本地装 JDK 17却导入一个 Spring Boot 2.7 的项目Maven 编译会因为字节码版本问题报错但显示出来的现象却像依赖没下载完。这类问题的排查路径先看 pom.xml 里 parent 的版本号再打开 IDE 的 Project Structure 确认 Project SDK 和模块的 Java 版本最后在 Maven 面板点 Reimport让项目按正确的 JDK 重新解析依赖。这里还要提醒一个细节JAVA_HOME 环境变量和 IDE 内部 SDK 经常不一致。命令行执行 java -version 是 17IDE 里配置的却是 8两边各管各的所以不能只看一个地方。我一般把 IDEA 的 Maven Runner 的 JRE 设置也改成与 Project SDK 一致三处统一这类由 java 环境配置引起的编译问题一次清干净。6. 答辩演示技巧把“管理系统”讲成“资源协调系统”答辩演示不是把每个页面点一遍而是按一条“发现问题 → 解决问题”的故事线走。我建议演示顺序固定为管理员登录后新增一条航班计划说明数据从哪来列表查询航班展示搜索条件与分页给该航班分配跑道和停机位演示成功占用再造一条时间段重叠的航班再次提交分配系统弹出冲突提示并拒绝进入协调日志页面展示刚才两次操作的完整记录与操作人。这条线在 5 分钟内讲完全程突出“冲突检测”和“审计日志”这是普通管理系统没有、而机场协调系统必须有的两个差异化点。演示前用一张对照表准备现场照着走不容易乱演示操作预期界面反馈对应答辩提问点新增航班 CA1234列表出现新纪录计划与实时数据为什么分两张表分配跑道 36R跑道状态变为占用资源表与动态表如何联动再分配同段跑道给 CA5678系统提示冲突并拒绝区间重叠判断算法怎么写的查看协调日志可见操作人、时间、原因事务如何保证数据一致性准备时记住一个习惯提前在数据库里预置几组“计划、延误、到达、取消”状态的航班演示时用真实数据切换状态而不是现场录入现场录数据一旦日期选错就会卡壳。我自己第一次答辩就吃过顺序颠倒的亏后来把演示写成半页纸脚本、对着预置数据跑三遍才踏实。这套系统能跑起来、能把冲突检测讲清楚已经超过大多数只做普通增删改查的同期同学了。希望这份拆解能帮到你动手前多看一遍部署视频数据库脚本先导成功大概率就能顺利落地。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
