企业官网建设流程全解析

赶上要做毕业设计的那批人，十有八九会碰Java+SpringBoot这种经典组合。如果你抽到的方向是“机场航班起降调度”或者“机位动态管理”，第一反应可能是：这题听起来好大，地面保障协同到底从哪下手？说实话，这类题目的难度不在增删改查，而在“业务逻辑怎么建模”以及“调度状态怎么流转”。我见过不少同学拿到类似题直接往框架里堆 CRUD，结果代码写了一两千行，答辩时却被老师一句“你的系统核心逻辑在哪”问懵。

这篇文章我会从一个可落地的角度，把基于SpringBoot的机场航班机位调度与动态管理平台拆开讲，内容包括整体架构、核心数据模型、机位分配算法怎么设计不会过度复杂、航班动态的状态机怎么建模，以及最容易被忽略的“模拟数据与演示技巧”。不论你打算作为毕设项目，还是打算自己做一个智慧机场方向练手项目，这篇文章的思路都值得参考，也尽量避免那种“看起来功能很多、一深问就露馅”的情况。

1. 这套系统面对的调度困局与核心价值

先把业务场景说透。机场地面运行听起来不复杂——飞机来了，停到机位，上下客，加油，然后走了。但一旦数据量大起来，问题就非常现实：航班计划表排得密密麻麻，机位资源却只有那么多个，宽体机只能用 E 类以上的机位，廊桥机位谁先到谁用还是按优先级抢？临时取消的航班占着坑不放，延误的航班又把后续计划全部打乱。调度员要在几分钟内判断“这架飞机到底该放哪个机位、什么时候能推出”，这本身就是多约束条件下的资源分配问题。

这套机场航班起降调度信息管理系统，核心价值就是把这堆原本靠电话、便签、口头交接的调度经验，沉淀成一套可计算、可追溯、可预判的信息化流程。它把航班计划、进离港动态、机位资源、保障任务四个要素串起来，让“分配机位”不再是凭感觉，而是有规则、有冲突校验、有状态联动。

从一个毕设项目的角度来说，这个选题的切入点也比较合适。它既不算一个纯算法研究型题目（不需要把 SAT 问题研究到多深），也不至于只是简单的管理系统（你至少有“机位分配”和“状态流转”这两个可以讲出深度的业务核心）。对SpringBoot、MyBatis-Plus、Vue技术栈熟悉的同学，大概一个多月能打磨出一个相当完整的版本。

2. 技术选型与总体架构：为什么用 SpringBoot 单体就能解决问题

先回答一个很现实的问题：类似系统网上也能搜到很多版本，为什么我要自己选SpringBoot而非微服务或者 Python FastAPI？理由有三个，也是我建议你做毕设时可以参考的选择逻辑。

2.1 业务复杂度决定单体够用

机场调度涉及的模块看着很多——航班计划、机位管理、保障任务、统计报表，但本质上它们都是围绕同一个数据库核心做读写。用户量级按百计算，并发压力远没有互联网应用那么夸张。这种情况下引入微服务、消息队列、分布式事务，是用多余的复杂度换取并不存在的收益，尤其对于毕设评审来说，讲不清楚就是减分项。

SpringBoot单体应用在这个场景里其实非常合适：一个应用承载全部 REST API，内部用清晰的分层 + 模块分包来隔离业务领域即可。我见过有人硬把一个简单系统拆成四个微服务，部署的时候自己都绕不清楚，实际上单体 + 良好分包完全足够支撑“机场地面保障协同”的范围。

2.2 核心模块划分与职责边界

整个系统我建议按下面五个模块划分，这个划分方式也基本贴合机场地面运行的真实业务结构：

这五个模块中，最核心也最需要花心思的是第四个——机位分配。普通的增删改查表格是做不出“调度系统”的感觉的，你必须把“分配”这个动作变成一个可解释的决策过程。后面我会单独用一节来讲这个分配引擎怎么做。

2.3 后端技术栈清单与版本建议

技术栈不需要花哨，但要写清楚选型理由。我自己常用的搭配是：

• Spring Boot 2.7.x 或 3.x（JDK 1.8 对应 2.7，JDK 17 可选 3.x，毕设建议 2.7 + JDK8，省去环境折腾）
• MyBatis-Plus：动态查询很方便，分页、条件构造器可以减少大量样板代码
• MySQL 8.x：存储核心业务数据，建议数据库名 crc_airport
• Redis（可选）：缓存机位状态和航班热度，但不要为了用而用，后期有性能瓶颈再上
• Vue 3 + Element Plus：前端展示大屏和操作面板，适合演示
• Maven 管理依赖，统一构建

这个组合的好处是每一步都有非常成熟的社区资料，遇到报错基本一搜就有答案，关键时刻还能少掉点头发。

3. 航班机位与动态管理的核心数据模型

系统设计里最怕一上来就写代码。你要先能把业务物体映射成数据关系，这个关系建得烂，后面写再多代码也救不回来。下面是关键表结构的展开说明，也是我建议你直接落库的起点。

3.1 航班计划表 flight_plan

这张表存的是“计划内”的航班，即在航班起飞前一天甚至更早就排进系统的班次。字段设计上要区分“计划”与“实际”，后面做动态管理才不混乱：

CREATE TABLE flight_plan ( id BIGINT PRIMARY KEY AUTO_INCREMENT, flight_no VARCHAR(20) NOT NULL COMMENT '航班号', airline_code VARCHAR(10) COMMENT '航司代码', aircraft_type VARCHAR(20) COMMENT '机型，如 A320/B738', stand_class_required VARCHAR(10) COMMENT '所需机位等级，如C/D/E', plan_takeoff_time DATETIME COMMENT '计划起飞时间', plan_landing_time DATETIME COMMENT '计划降落时间', departure_city VARCHAR(50), arrival_city VARCHAR(50), terminal VARCHAR(10), status TINYINT DEFAULT 0 COMMENT '基础状态', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

注释一定要写清楚。你看stand_class_required这个字段，它代表的是“这架飞机需要多大的机位”，而机位表里会有一个对应的等级字段，比如 C 类适航机位只能停 C 类以下飞机。这就是之后分配校验的基石。

3.2 机位资源表 airport_stand

机位是物理资源，有属性，有状态。除了基本的编号和航站楼，还建议把“是否靠廊桥”“是否可夜航”“是否国际”这些属性做进去：

CREATE TABLE airport_stand ( id BIGINT PRIMARY KEY AUTO_INCREMENT, stand_no VARCHAR(10) NOT NULL UNIQUE COMMENT '机位编号，如 201', stand_class VARCHAR(10) COMMENT '机位等级', is_bridge TINYINT DEFAULT 0 COMMENT '是否廊桥', is_international TINYINT DEFAULT 0 COMMENT '是否国际区', status TINYINT DEFAULT 0 COMMENT '0空闲/1占用/2维修', current_flight_id BIGINT COMMENT '当前占用航班ID', last_release_time DATETIME COMMENT '最后释放时间', update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

current_flight_id这个字段很重要，查询“哪些机位被占用”时能直接关联到航班，不要每次去分配表里聚合。

3.3 航班动态表 flight_dynamic

这张表记录每个航班的实际运行事件，包括实际降落时间、实际上客时间、推出时间。它和 flight_plan 是一对一关联的，但是逻辑上必须独立，原因在于“计划”是可修改的基线，而“动态”是不断推进的状态事实。

CREATE TABLE flight_dynamic ( id BIGINT PRIMARY KEY AUTO_INCREMENT, plan_id BIGINT NOT NULL, flight_no VARCHAR(20), actual_landing_time DATETIME COMMENT '实际落地时间', actual_takeoff_time DATETIME COMMENT '实际起飞时间', boarding_time DATETIME COMMENT '开始登机时间', pushback_time DATETIME COMMENT '撤廊桥/推出时间', current_state VARCHAR(20) DEFAULT 'SCHEDULED' COMMENT '状态机字段', delay_reason TEXT COMMENT '延误原因备注' );

这里的current_state是我特别想强调的：不要用0/1/2这种数字枚举，直接用字符串。字符串在打印日志和调试的时候可读性极强，配合 Java 枚举类使用非常顺手。

3.4 机位分配记录表 stand_allocation

分配记录要保留历史，而不是只更新机位上的当前航班字段：

CREATE TABLE stand_allocation ( id BIGINT PRIMARY KEY AUTO_INCREMENT, plan_id BIGINT NOT NULL, stand_id BIGINT NOT NULL, allocate_time DATETIME, release_time DATETIME, allocator VARCHAR(50), remark VARCHAR(200), INDEX idx_plan_stand(plan_id, stand_id) );

为什么要保留历史？因为在演示和答辩的时候，老师很可能会问“这个机位两个小时内接了几个航班、每个航班停多久”。有这张历史表，你就能轻松拉出一条时间线来，这在真实机场运行中也是必须的——机位使用率、周转效率都依赖历史数据。

3.5 保障任务表 support_task

这个模块用来体现“地面保障协同”。航班落地后，摆渡车、加油车、行李车都要按时间节点干活。每项保障任务和航班关联，有负责人和状态：

CREATE TABLE support_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, plan_id BIGINT, task_type VARCHAR(20) COMMENT '加油/清洁/配餐/摆渡/行李', execute_hours VARCHAR(20) COMMENT '执行班组', status TINYINT DEFAULT 0 COMMENT '0未开始 1进行中 2完成', assign_time DATETIME, finish_time DATETIME, remark VARCHAR(200) );

4. 机位分配算法：从暴力匹配到可解释调度的实践思路

机位分配是这类系统里含金量最高、也最容易被人问细节的地方。大多数毕设的做法是“找到一个空闲机位直接分配”，这根本没有展示出调度思维。这里给你一个分阶段的演进思路，确保你能从简单版做到进阶版，每一版都有完整的逻辑链。

4.1 第一版：先到先得的空闲匹配

第一版以“能跑通”为目标。遍历机位表，找出符合等级条件且空闲的机位，挑第一个分配。这种算法码量少，胜在直观。

public StandAllocation allocateFirstFit(AssignRequest req) { LambdaQueryWrapper<AirportStand> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(AirportStand::getStandClass, req.getStandClassRequired()) .eq(AirportStand::getStatus, 0); AirportStand stand = standMapper.selectOne(wrapper); if (stand == null) { return null; // 没有可用机位 } // 执行分配，更新机位状态和分配记录 ... }

这个版本虽然简单，但它会暴露一个问题：如果所有航班都来抢同一个区域的优秀机位，其他机位利用率会很差。你得接受这一点，然后引出第二版。

4.2 第二版：按得分排序的最优匹配

改进思路是给机位加一个“适配度得分”，分配时不是选第一个，而是选最高分。比如：

• 机型等级刚好匹配，加分；
• 优先分配廊桥机位给中转时间短的航班，加分；
• 避免分配已经连续使用很久的机位（周转效率），减分；
• 国际航班必须匹配国际区机位。

这样就把一个简单的匹配问题，变成了一个可解释的排序问题。代码逻辑也从“直接返回第一个”变成：

List<AirportStand> candidates = standMapper.selectCandidates(req); candidates.sort((s1, s2) -> Integer.compare( scoreFor(s2, req), scoreFor(s1, req) )); AirportStand best = candidates.get(0);

每一票的评分规则写在一个独立的策略类里，答辩的时候你可以直接拿打印日志展示“为什么选这个机位”，那些分数就是你调度逻辑的证据。

4.3 时间冲突检测：不只是看机位是否空闲

真实调度里，机位“当前空闲”不代表接下来一小时都能空着。更严谨的做法是：根据航班的计划占用时间段去检查分配表中是否存在时间重叠。比如某航班计划 10:00 落地，预计 11:30 推出，那个机位如果 12:00 有另一个航班预分配，其实是可以接受的——只要时间不重叠。

public boolean hasTimeConflict(Long standId, LocalDateTime start, LocalDateTime end) { LambdaQueryWrapper<StandAllocation> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(StandAllocation::getStandId, standId) .isNull(StandAllocation::getReleaseTime) .or(w -> w.le(StandAllocation::getReleaseTime, end) .ge(StandAllocation::getAllocateTime, start)); return allocationMapper.selectCount(wrapper) > 0; }

这一步是很多初学者会忽略的：只看机位状态字段做分配，一旦有航班延迟推出、后续航班已经占用了同一机位，冲突就产生了。时间重叠检测是状态字段判断之外最重要的补充。

4.4 取消与延误：释放或顺延的兜底策略

现实中航班不会永远准点。系统里至少要处理两类异常：

1. 航班取消：把该航班对应的机位立刻释放，分配状态改为“已取消”，同时如果它有未完成的保障任务，标记作废。
2. 航班延误：如果航班还没落地，则顺延它的机位占用起止时间，但必须先做时间冲突检测，顺延后撞上后续计划，就得给后续航班重新分配机位。

我在项目里是建了一个FlightScheduleChangeListener，监听航班动态表的变化事件。只要flight_dynamic的状态发生更新，就触发调度器重新评估相关机位。用Spring的事件机制解耦这些操作，代码看起来也会干净不少。

5. 航班动态状态机：把起降过程变成可流转的节点

航班从计划到离场，中间要经历一串状态。很多项目把状态设计成0/1/2/3，但代码里到处是if status == 1，后期维护会非常痛苦。这里建议直接用状态机模式，将每个状态建模成独立枚举，并强制状态转移合法。

5.1 状态定义与流转闭环

一个完整航班动态的典型状态序列如下：

SCHEDULED（计划中） → ARRIVED（已落地） → BOARDING（登机中） → READY（准备完毕） → DEPARTED（已起飞） → FINISHED（完成）

异常分支包括：CANCELLED（取消）、DELAYED（延误）、DIVERTED（备降）。

这个流转关系用 Java 枚举可以写成这样：

public enum FlightState { SCHEDULED, ARRIVED, BOARDING, READY, DEPARTED, FINISHED, CANCELLED, DELAYED; private static final Map<FlightState, List<FlightState>> TRANSITIONS = new HashMap<>(); static { TRANSITIONS.put(SCHEDULED, Arrays.asList(ARRIVED, CANCELLED, DELAYED)); TRANSITIONS.put(ARRIVED, Arrays.asList(BOARDING, CANCELLED)); TRANSITIONS.put(BOARDING, Arrays.asList(READY, DELAYED)); TRANSITIONS.put(READY, Arrays.asList(DEPARTED, DELAYED)); TRANSITIONS.put(DEPARTED, Arrays.asList(FINISHED, CANCELLED, DIVERTED)); } public boolean canTransitionTo(FlightState target) { return TRANSITIONS.getOrDefault(this, Collections.emptyList()).contains(target); } }

配置好转移映射表之后，每次状态更新前先做合法性校验。这个方法的好处是：非法跳跃在入口就被拦截，不会出现“航班还没落地就推出”这种数据错乱。

5.2 状态变化触发联动事件

状态机不应该只做校验，更关键的是联动。比如航班从ARRIVED转到BOARDING时，系统应该自动触发“生成保障任务”或者“更新机位占用开始时间”。我建议用 Spring 的事件监听来做：

public class FlightStateChangedEvent extends ApplicationEvent { public final Long planId; public final FlightState before; public final FlightState after; public FlightStateChangedEvent(Object source, Long planId, FlightState before, FlightState after) { super(source); this.planId = planId; this.before = before; this.after = after; } }

然后写一个监听器：

@Component public class FlightStateListener { @EventListener public void onStateChanged(FlightStateChangedEvent event) { if (event.after == FlightState.ARRIVED) { // 自动创建保障任务，比如加油/清洁/摆渡 supportTaskService.createTasksForFlight(event.planId); } if (event.after == FlightState.DEPARTED) { // 推送统计事件、释放机位 standService.releaseStandByFlight(event.planId); } } }

这样做的好处肉眼可见：写业务逻辑的时候你只管触发“状态切换”，后续一连串动作都不会漏掉。这也正好回应了题目里“地面保障协同”的要求——保障任务不是人工每次去点新建，而是跟着航班动态自动生成。

5.3 状态管理界面的操作逻辑

管理端的航班列表，每行都是一个动态数据卡片。前端把状态流转做成交互按钮更直观：落地、登机、推出、起飞。每次按钮点击走一遍POST /api/flight/state接口，后端做校验，合法就更新并返回新的航班信息，非法就弹一个提示，比如“当前状态不可变更为目标状态”。前端的按钮实时用当前状态驱动，能显著提升演示时“系统感”的观感。

6. 工程化落地：分页、事务与数据导入

写业务逻辑只是系统的骨架，数据量大了之后，查询和批量操作才是体验的关键。这节讲几个我实际编码时踩过的点。

6.1 分页查询与动态条件过滤

航班列表、机位状态、任务列表，都要用分页。MyBatis-Plus 的分页插件配置比较简单，但要注意条件构造器的使用方式，尤其是and和or的优先级。

推荐给列表搜索加三个标准参数：pageNum、pageSize、keyword。keyword 做成通用模糊搜索，匹配航班号、航司、机位编号。接口返回结构统一为：

{ "total": 123, "rows": [ { "flightNo": "CA1234", "standNo": "201", "state": "ARRIVED" } ] }

6.2 分配机位的原子性保证

分配操作牵涉三张表：机位表、分配记录表、航班动态表。必须放同一个事务里。否则机位状态更新了、分配记录没插入，数据就脏了。

@Transactional(rollbackFor = Exception.class) public StandAllocationResponse assignStand(AssignRequest request) { // 1. 校验航班存在且处于可分配状态 // 2. 检查机位是否可用、时间是否冲突 // 3. 更新机位 status 和 current_flight_id // 4. 插入分配记录 // 5. 动态表标记开始占用 // 任一异常则整体回滚 }

写事务时建议显式声明rollbackFor = Exception.class，否则某些运行时异常不会被默认回滚规则捕获，会导致分配记录缺失但机位状态变了。

6.3 模拟数据的批量导入

机场项目的演示数据至关重要。靠手工一条条录，录 50 条航班就崩溃了。建议准备一个数据导入功能，支持 Excel 或者 CSV。至少生成三类模拟数据：

• 20 个机位，覆盖 C/D/E 等级，部分廊桥部分远机位；
• 80~120 条计划航班，分布在当天 06:00 至 24:00；
• 每个航班 1~3 条保障任务，按落地时间错开。

批量插入结合 MyBatis-Plus 的saveBatch，几千条数据也就几秒钟。为了保证时间分布合理，生成时建议以整点+随机分钟的方式打散，避免整点集中冲突。

6.4 REST API 设计框架

给前端用的接口建议统一返回体，例如Result<T>。具体接口按资源划分：

GET /api/plan/page 分页查询计划航班 POST /api/plan 新增计划航班 PUT /api/plan/{id} 编辑计划航班 GET /api/stand/list 机位列表及状态 POST /api/assign/stand 分配机位 POST /api/assign/release 释放机位 GET /api/flight/dynamic 航班动态查询 POST /api/flight/state 航班状态变更 GET /api/stat/stand-usage 机位利用率统计

每个接口的入参不要用裸 Map，定义一个 DTO，配合@Validated做参数校验。整体干净利落。

7. 避坑指南：这些细节决定答辩时能否顺畅操作

这部分整理一些我在做这类项目时实实在在踩过的坑。有些坑不算致命，但在演示环节一旦发生，非常影响印象分。

7.1 时间字段只用 LocalDateTime，别用 String

很多同学在 Excel 导入时图省事，把时间直接存成字符串。到了要做时间冲突检测、按时间排序、算机位周转率时就会非常痛苦。全部用LocalDateTime映射数据库的DATETIME，前端传 ISO 格式字符串，后端自动解析。

7.2 初始化分配的演示顺序

答辩演示时最尴尬的就是“点了分配，弹窗提示没有可用机位”。原因多半是模拟数据里所有机位都被之前的示例数据占了。解决方案是在系统启动时执行定时清理：把超过 24 小时没有任何更新的分配记录自动释放，同时提供一个“重置演示数据”按钮，一键清理分配记录并把所有机位恢复空闲。演示前手动点一下，不用紧张。

7.3 航班状态和机位状态的联动别忘一致性

最容易忽略的场景：把航班从动态列表里硬删，但机位状态没恢复。建议所有删除操作都做成逻辑删除（加deleted字段），同时删除时释放机位。物理删除在演示时确实能删掉数据，但也会把历史链路从统计报表里抹掉，非常不利于后续展示机位利用率。

7.4 预警提示：让系统看起来更“智慧”

机场调度系统不能只被动录入，还要有主动提示。一个轻量但出彩的功能是“预警面板”：低于三小时即将降落的航班、机位紧张率超过 80% 的时段、未完成保障任务的航班清单，这几个查询视图做出来之后，系统立刻显得像一个真正会“协同”的平台。实现也不复杂，无非是几条带聚合的 SQL 查询。

7.5 关注状态机的边界条件

DELAYED状态最容易被漏掉。很多演示或评审场景会问“航班延误了怎么办”，如果你的状态机里根本没有这个状态，或者从DELAYED不能转回ARRIVED，那现场会很难圆场。设计状态机时至少把“起飞前延误”“落地后延迟下客”两种情形考虑进去，哪怕代码逻辑只是延时几秒更新机位占用。

8. 演示与答辩视角：数据怎么准备才能讲出“调度感”

系统做完之后，怎么演示其实占很大比重。要让老师一眼看出这不是一个普通的数据管理系统，你得精心准备“剧情”。

8.1 准备三条故事线

第一，正常流程：导入航班计划，查看机位状态，手动/自动分配几个航班，观察机位占用情况，修改航班状态到落地、登机、起飞，看机位是否自动释放。

第二，冲突处理：故意挑一个已经占用相同时间段的机位，演示冲突检测提示，再手动调整到其他机位，说明系统的约束校验是真实生效的。

第三，异常场景：把一个航班的动态状态改成DELAYED，触发顺延逻辑，观察后续机位分配是否被重新规划。这三条线走完，从流程到异常处理都覆盖了。

8.2 报表上的“增量信息”

普通管理系统的报表是流水账，但调度系统的报表一定要有“率”的计算。推荐展示两个指标：机位利用率（某个机位当天被占用分钟数除以总营业分钟）和航班计划执行率（实际起飞航班数除以计划起飞航班数）。有了这两个指标，老师能立刻看出你理解了“调度管理”的本质，而不是只会写select * from table。

8.3 代码层面留几个“讲得出亮点”的点

答辩肯定会看代码。几个值得特意梳理的亮点：

• 分配算法中评分策略类StandScoreStrategy的结构，这是一个典型的策略模式应用；
• 状态转移的合法性校验，这是一个标准状态机的骨架；
• 事件监听器FlightStateListener触发保障任务生成，这是事件驱动解耦的体现。

这几处代码量不大，但都是“设计感”的来源，比堆砌Controller里的几十行if else有价值得多。

9. 最后分享两个实际开发中觉得很顺手的小技巧

第一个是关于机位编号的规划。机场机位编号并不是纯数字随便编的，可以按规则设计，比如 101-199 为 T1 航站楼 C 类机位，201-299 为 T1 航站楼 D/E 类机位，301-399 为远机位。带规则的数据比随机数据演示起来更真实，也方便老师理解机位资源的分布。

第二个是关于调度的“影子模拟”。如果你不想让正在进行的分配操作被演示时的误操作污染，可以单独建一个demo_mode参数，所有写入都在一个临时_demo后缀表上进行——但这更多只是演示策略，不属于核心功能开发，不必做得多完善。

这类机场调度项目，说到底是“资源管理 + 状态协同”的问题。把机位当成稀缺资源，把航班当成连续到达和离开的实体，把保障任务当成每个航班生命周期里的子事件，整个系统的结构就清晰地展开了。希望通过这篇拆解，你不仅能搭出一个能跑的毕设系统，更能理解每一步设计背后的业务原因。做这类项目最大的收获，往往不是框架熟练度，而是你用代码解决一个人为调度问题的思维过程。