基于Spring Boot和Vue的航班分析管理平台源码解析与实战

简介：这套天津滨海机场航班分析及管理平台源码，基于Java后端与Vue等前端技术整合开发，面向机场运营管理场景，可支撑航班数据实时分析、状态动态展示及高效管理，适合希望掌握前后端分离项目实战的开发者研读。压缩包共164个文件，以155个Java源码文件为主体，涵盖实体、数据访问、业务逻辑等层次，辅以XML、YML配置及Maven构建脚本、运行配置等工程化文件，包体仅237KB，结构紧凑精炼。平台前端通过Vue组件和JavaScript实现交互，后端利用分层架构处理航班数据，并配有LICENSE开源许可，方便合法复用与二次开发。目录中已包含构建脚本、说明文档及版本控制配置，能直观了解一个完整Java项目的组织方式。目前已有285人学习下载，适合中高级开发者借鉴其航班管理模块设计思路，或作为毕业设计、课程项目的起点。

1. 这源码解决什么问题：上手即用的航班分析闭环

做Java课程设计或毕设的人，十个里有九个拖到最后一两周才动手，真上手才发现：航班这类信息管理系统，后端Java怎么组织、前端图表怎么画、数据库里的模拟航班数据从哪来，全是坑。这套基于Java和前端技术的天津滨海机场航班分析及管理平台设计源码，解决的正是这几件事，它把Spring Boot + MyBatis + MySQL的后端体系、Vue + ECharts的页面可视化，以及航班管理、统计分析所需的数据链路完整串在了同一个工程里。适合Java课程设计、毕业设计，以及想快速看一套前后端分离项目内部怎么衔接的从业者。拿到手能直接看到起降架次统计、准点率计算、航班信息管理这些功能的真实实现，而不是零散的知识点demo。

2. 技术选型与前因后果：为什么是Java + Spring Boot + Vue

2.1 从课设到真实系统的三层结构：Spring Boot、MyBatis 与 MySQL 的边界

这套源码的后端骨架是Spring Boot + MyBatis + MySQL，属于Java EE里最成熟、资料最多、翻车时最容易搜到答案的组合。Spring Boot把Spring MVC原本那一堆XML配置压进自动配置里，内嵌Tomcat，打成jar包直接跑，不用单独部署Web容器，这对第一次接触Java Web的人省掉很大一块心智负担。MyBatis是半自动ORM，只帮Java对象和SQL结果集之间做映射，SQL本身要自己写。航班分析里最重的操作不是增删改查，而是按日期、按航空公司、按起降城市做聚合统计，手写SQL反而比Hibernate这类全自动ORM更直观。

我一般会建议选MyBatis而不是Spring Data JPA，因为管理平台的查询条件多、报表SQL变化频繁，SQL集中在Mapper文件里可维护性更好。MySQL负责建库建表、存航班基础数据和经停数据，表结构并不复杂，但字段设计直接影响后面统计SQL能不能写顺。拿到工程后，建议先看三样东西建立整体认知：pom.xml里有哪些依赖、application.yml的数据源配置、resources/mapper目录下的XML查询语句。这三样看完，整个工程的数据流基本就清楚了。

2.2 前端负责什么：Vue 与 ECharts 在航班可视化里的分工

前端用Vue + ECharts，这几乎是航班分析类平台的标配。Vue管页面组织、表单交互、路由跳转，ECharts管图表渲染。起降架次的柱状图、准点率的折线图、热门航线的分布图，这些都是ECharts的老本行。为什么不直接用HTML + jQuery写几个图表？因为航班管理平台不止一个页面，航班信息、机票价格、统计报表、用户管理，页面之间共享状态，Vue的组件化在后期改需求时会轻松很多。

ECharts的数据接收方式很直白：后端返回JSON数组，前端setOption喂给图表。这套源码的可视化维度主要有三个：按天统计的起降架次柱状图、按航空公司对比的准点率、以及按航线汇总的热度排序表。真正需要仔细核对的是后端返回结构里的字段名和ECharts里series.data的字段名一致，很多对接失败都卡在大小写或别名上。这些字段名一旦定下来，就是前后端之间的契约，后面改任何一头都要同步另一头。

2.3 接口契约与数据流：一张航班表如何支撑全平台

管理平台的核心表设计是这套源码里最值得抄的部分。航班表持有航班号、起飞机场、降落机场、计划起飞时间、计划降落时间、实际起飞时间、实际降落时间、航班状态和航空公司代码，基本覆盖了管理侧和分析侧两类需求。管理侧直接对这些字段做增删改查，分析侧用SQL聚合后返回统计结果，两边从同一张表读数据，不会出现口径不一致的问题。

字段选型有几个细节值得注意。时间字段全部用DATETIME而不是字符串存储，因为准点率计算要比较实际降落和计划降落两个时间点，字符串比较会在格式不一致时翻车。起降机场用三字码存储，展示名称单独做映射表，避免界面显示和存储结构耦合。航班状态用TINYINT整数（0计划、1延误、2到达、3取消），前端用统一字典翻译，这样要加新状态时不用改表结构。

接口设计上，管理端走REST风格，/flight/page做分页查询，/flight/statistics/day做按天聚合，/flight/statistics/rate做准点率统计。这些接口返回的JSON结构是固定的，比如统计接口统一返回包含日期数组和数值数组的对象，前端图表组件直接消费，不用在页面里做二次清洗。

3. 把工程跑起来：环境、配置与首屏数据的完整链路

3.1 环境准备：JDK、Maven 的版本搭配与安装注意

先讲版本搭配。这套源码对应JDK 1.8或11都可以跑，Maven用3.6以上版本即可。很多人在环境上翻车，不是没装JDK，而是JAVA_HOME没配或者PATH顺序被其他JDK干扰。配置JAVA_HOME时，路径里不要有中文和空格，配好后打开命令行验证一下：

# 显示Java版本，1.8或11均可 java -version # 显示Maven版本，3.6以上即可 mvn -v

java -version如果提示不是内部或外部命令，先确认JAVA_HOME指向的是JDK安装目录而不是JRE目录，再把%JAVA_HOME%\bin追加到PATH最前面，注意Windows和Linux路径分隔符的区别。mvn -v如果找不到命令，通常是Maven解压目录的bin路径没加进PATH。

环境变量配置的完整教程很多，这里只提醒这两个跟这套源码直接相关的点：PATH里同名的java.exe来自完全不同的JDK安装目录，以及Maven镜像源没配置导致依赖下载卡住。如果拉依赖特别慢，在Maven安装目录的conf/settings.xml里配置阿里云镜像仓库，把jar下载地址换成国内源，速度会改善不少。

3.2 数据库初始化：建库建表与初始航班数据的导入

数据库用MySQL 5.7或8.0都能跑，建库时指定utf8mb4字符集，否则后面导入中文航班城市名容易变问号。方案自带的init.sql完成了建库、建表和模拟航班数据的导入，核心航班表的建表语句大致是下面这种结构：

CREATE TABLE `flight_info` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `flight_no` VARCHAR(10) NOT NULL COMMENT '航班号', `airline_code` VARCHAR(5) NOT NULL COMMENT '航空公司二字码', `departure_code` CHAR(3) NOT NULL COMMENT '起飞机场三字码', `arrival_code` CHAR(3) NOT NULL COMMENT '降落机场三字码', `scheduled_departure` DATETIME NOT NULL, `scheduled_arrival` DATETIME NOT NULL, `actual_departure` DATETIME DEFAULT NULL, `actual_arrival` DATETIME DEFAULT NULL, `status` TINYINT NOT NULL DEFAULT 0, PRIMARY KEY (`id`), KEY `idx_departure` (`departure_code`), KEY `idx_arrival` (`arrival_code`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='航班信息表';

建表语句里三个点值得注意。ID用BIGINT自增，不要省成INT，数据量上来后不容易踩到上限。起降机场三字码字段都建了索引，后面按天聚合和按城市过滤时会频繁走索引。状态字段用TINYINT存整数而不是直接存字符串，这样前端可以做统一的字典映射，也方便后期扩展新状态。

导入数据时，先建库再建表最后导入数据。用Navicat执行init.sql时，选择utf8作为导入字符集，如果导入后中文显示为问号，说明数据库连接或表字符集不是utf8mb4，需要重新建库再导。

3.3 后端启动参数梳理：端口、数据源与日志配置

后端核心配置文件是application.yml，里面决定本机能否一次跑通的是数据源三件套：URL、用户名、密码。常见做法是单独建一个本地数据库账号，不直接拿root用，权限只要够用就行。下面这份是整理后的关键配置：

server: port: 8080 # 后端服务端口，被占用时改成8081 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/tj_airport?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: flight_user password: flight123 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis: mapper-locations: classpath*:mapper/*.xml configuration: map-underscore-to-camel-case: true

URL里的serverTimezone=Asia/Shanghai必须加，MySQL 8.0驱动默认时区是UTC，不加会导致时间字段偏移8小时。map-underscore-to-camel-case设为true，数据库的scheduled_arrival字段才能自动映射成Java实体的scheduledArrival属性，不用在每段SQL里写别名。连接池默认用HikariCP就好，如果你习惯Druid，引入druid-spring-boot-starter之后加一行type: com.alibaba.druid.pool.DruidDataSource即可。

配置参数优先级说明如下，方便你改端口和数据源时知道动哪一行：

3.4 前端启动与联调：跨域、代理和首个请求验证

前端工程启动后默认跑在8081端口，避免和后端8080冲突。vue.config.js里必须配devServer代理，否则浏览器直接请求localhost:8080会触发跨域报错。代理配置如下：

module.exports = { devServer: { port: 8081, // 前端开发服务端口 proxy: { '/api': { // 匹配以/api开头的请求 target: 'http://localhost:8080', // 转发到后端服务 changeOrigin: true, pathRewrite: { '^/api': '' } // 去掉/api前缀再转发 } } } }

代理的原理是前端本地服务把以/api开头的请求转发给后端8080端口，浏览器始终只和8081通信，不直接跨域。pathRewrite把/api前缀去掉后，后端Controller里不需要加统一前缀，少一层维护成本。联调验证方式很直接：依次启动后端和前端，浏览器打开页面，先看Network面板，如果航班列表接口返回200且能看到JSON数据，说明前后端链路已经通了。

如果接口返回404，检查代理的target端口是不是写成了后端实际端口；如果返回500，多半是数据库连接串里用户名密码不对，回到3.3的配置里核对一遍。

4. 航班分析核心模块：聚合统计、准点率与前端图表的联动实现

4.1 数据聚合的实现：日期分组统计的SQL写法

航班分析平台最有价值的部分是统计模块。以按天统计起降架次为例，后端Mapper里写一个分组查询，把航班表按DATE(actual_departure)分组，统计每天的起飞架次。下面是一个可靠的XML Mapper写法：

<select id="selectDailyTraffic" resultType="map"> SELECT DATE(actual_departure) AS stat_date, COUNT(*) AS total_count FROM flight_info WHERE actual_departure IS NOT NULL AND actual_departure BETWEEN #{startTime} AND #{endTime} GROUP BY DATE(actual_departure) ORDER BY stat_date ASC </select>

这里最关键的是时间过滤条件写在WHERE里而不是HAVING里。GROUP BY之前过滤可以减少分组的数据行数，日期范围拉大时性能差距非常明显。DATE()函数把DATETIME截断成日期，这样同一航班按天归拢；如果你的业务需要按小时或按星期统计，改成HOUR()或WEEK()即可。返回类型用map而不是实体类，因为聚合结果没有对应的Java bean，Map<String, Object>最省事，前端怎么取都灵活。

4.2 准点率计算的边界：晚于计划时间15分钟算延误

准点率是民航系统的核心指标，通用标准里航班实际到达时间晚于计划到达时间15分钟以上视为延误。这套源码把计算逻辑放在Service层，而不是直接写进SQL，是因为边界处理用代码表达更清楚。计算过程要覆盖三种边界：实际到达时间为空、实际到达时间早于计划时间、实际晚点超过15分钟。核心逻辑如下：

// 准点率计算，需要import java.time.* private static final long DELAY_THRESHOLD_MINUTES = 15L; public double calcOnTimeRate(LocalDateTime scheduledArrival, LocalDateTime actualArrival) { if (actualArrival == null) { // 实际到达时间为空时按延误处理，避免空指针 return 0.0; } long delayMinutes = Duration.between(scheduledArrival, actualArrival).toMinutes(); // 早到按准点处理，晚到超过阈值才按延误处理 if (delayMinutes > DELAY_THRESHOLD_MINUTES) { return 0.0; } return 1.0; }

注意阈值边界用的是>而不是>=，恰好晚15分钟整不算延误。这个细节如果在论文答辩或技术评审里被问起，能说清楚为什么这么定。Duration.between计算的是两个时间的差值，会自动处理跨天的情况，比如计划23:55到达、实际00:10到达，差值算出来是15分钟而非23小时多。聚合时把每次返回的1.0和0.0累加，再除以统计总架次，就得到该时间段内的准点率。

把这份计算逻辑落到Service方法里，还有一个好处：统计维度可以随时切换。按天算就把每天的航班列表交给方法逐条判断，按航空公司算就换成按航空公司分组，不需要改核心判断逻辑，只改上层组织方式。

4.3 ECharts数据对接：把后端聚合结果渲染成柱状图和折线图

前端拿到JSON后怎么喂给图表，是很多刚接触Vue + ECharts的人最容易卡住的地方。拿不到数据大多数不是后端没返回，而是字段名对不上。前端组件里常见做法是把统计数据转换成ECharts需要的结构：

// 从后端拉取按天统计结果 const resp = await fetch('/api/flight/statistics/day').then(r => r.json()); // 把后端返回的stat_date和total_count拆进x轴和y轴 const statDates = resp.data.map(item => item.stat_date); const totals = resp.data.map(item => item.total_count); option = { xAxis: { type: 'category', data: statDates }, yAxis: { type: 'value' }, series: [{ type: 'bar', // 柱状图，折线图改成line并加smooth:true data: totals, name: '起降架次' }] };

从代码里能看到，后端返回的字段名stat_date、total_count与前端option里映射完全一致，这就是接口契约的约束。折线图渲染准点率时，series里的type换成line，再配一个smooth: true就能变成平滑曲线，接口返回值结构不用改。ECharts的setOption支持增量更新，切换统计维度时不用重新创建图表实例，直接setOption新数据即可。

提示：前后端字段名对齐是图表显示的关键。改后端SQL别名时，记得同步改前端resp.data.map里的字段引用，漏一个就会渲染出空图，还不报错。

5. 避坑指南：从数据库中文乱码到航班时刻映射的五条踩坑记录

5.1 中文城市名导入后变问号

现象：执行init.sql后，数据库里天津、北京等中文城市名显示为??，前端页面加载城市列表时全是乱码。

原因：建库时没有指定utf8mb4字符集，MySQL实例的默认字符集不是utf8mb4，或者JDBC连接串没带characterEncoding=utf8。这两个条件缺一个，中文在写入和读取之间就会丢失。

解决：删除原库重建，建库语句写成CREATE DATABASE tj_airport DEFAULT CHARSET=utf8mb4，再确认JDBC URL里同时带上characterEncoding=utf8和useUnicode=true。用Navicat导入数据时，左下角高级选项里选择utf8mb4字符集，再执行导入，避免工具层二次转码。

5.2 前端图表白屏但后端接口正常

现象：Network面板里能看到接口200返回，JSON数据完整，页面上的图表区域却是空白，或者只显示一个点。

原因：图表容器DOM元素初始化时高度为0，或者容器本身是display:none状态，ECharts在不可见元素上初始化，拿不到正确的尺寸。

解决：给图表容器设置显式高度，比如style="height: 400px"，在Vue的mounted钩子里再调用echarts.init初始化。如果图表在弹窗里，还需要在弹窗打开后再init，不能提前在页面加载时就初始化，或者初始化后手动调用一次chart.resize()强制重新计算尺寸。

5.3 日期查询差8小时

现象：按天统计的结果和预期对不上，比如某天清晨0点到1点的航班被归到了前一天，或者查询某一天的数据时首尾时间交叉。

原因：JDBC URL里漏了serverTimezone参数，MySQL 8.0驱动默认按UTC解析DATETIME，与东八区产生8小时偏移。

解决：在连接串末尾加上serverTimezone=Asia/Shanghai，重启后端服务。检查方法是在数据库客户端里执行SELECT NOW()，如果返回时间和本地一致，MySQL实例时区没问题，问题就出在驱动连接参数上。同时确认Spring Boot的JVM时区设置，必要时在启动参数里加-Duser.timezone=GMT+8。

5.4 MyBatis动态SQL里的日期参数报错

现象：接口入参传时间范围时，后端抛出日期解析异常，或者SQL里日期条件没生效，查出来的数据是全量。

原因：前端传来的日期字符串没有绑定到LocalDateTime参数上。Spring MVC在绑定请求参数时，不知道字符串和LocalDateTime之间的转换格式。

解决：在Controller接收参数上补@DateTimeFormat(pattern = "yyyy-MM-dd HH:mm:ss")，RequestBody里的JSON时间字段还要加@JsonFormat，两种注解职责不同，不能混用。如果实体类属性是LocalDateTime，加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")统一序列化格式，前端拿到的时间就是标准的日期字符串，不用再手动转换时间戳。

5.5 打包后前端页面404

现象：本地开发一切正常，mvn package后访问页面首页能打开，但一刷新或刷新子路由就直接404。

原因：Vue是history模式路由，刷新时浏览器按URL请求后端，Spring Boot对非接口路径返回404，没把前端路由转发到index.html。

解决：添加一个WebMvcConfigurer配置，把非接口路径统一转发到前端入口。配置类代码如下：

// WebMvcConfig.java import org.springframework.context.annotation.Configuration; import org.springframework.web.servlet.config.annotation.ViewControllerRegistry; import org.springframework.web.servlet.config.annotation.WebMvcConfigurer; @Configuration public class WebMvcConfig implements WebMvcConfigurer { // 非接口路径统一转发到前端入口，支持history路由刷新 @Override public void addViewControllers(ViewControllerRegistry registry) { registry.addViewController("/{path:[^\\.]*}").setViewName("forward:/index.html"); } }

这段配置的正则[^\\.]*匹配不包含点号的路径，排除了静态资源文件，只把前端路由转发给index.html。如果你用nginx部署，也可以在nginx里配置try_files $uri $uri/ /index.html，效果等价，但Spring Boot里加配置类更便于本地打包后直接验证。

6. 进阶用法：把按天统计改成可下钻的“机场-航线-时刻”三级分析

前面几章跑通之后，这个平台还能再往前一步：把静态统计图表改成可交互的下钻分析。思路是给柱状图加点击事件，点击某一天，把该天的航班按航线维度聚合，展示出当天各航线的架次；再点击某条航线，就展示该航线当天的完整航班时刻表。三个接口分别是/statistics/day、/statistics/day/route?date=xxx、/flight/page?date=xxx&route=xxx。后端改动量不大，就是把已经写好的聚合SQL复用，新增一个date参数。前端ECharts的click事件绑定到图表实例：

// 点击柱状图数据项，按日期下钻到航线维度 chart.on('click', async (params) => { if (params.componentType !== 'series') return; const selectedDate = params.data; // 拿到被点击的日期字段值 const resp = await fetch(`/api/flight/statistics/day/route?date=${selectedDate}`).then(r => r.json()); routeChart.setOption({ xAxis: { type: 'category', data: resp.data.map(item => item.route_name) }, series: [{ type: 'bar', data: resp.data.map(item => item.route_count) }] }); });

点击事件的回调里，params.data对应的是xAxis传入的日期字符串，不是series里的索引，这是很多同学第一次写时最容易搞错的地方。下钻到时刻表时，只需要再监听航线图表的click事件，把选中的航线代码拼进查询参数，调用分页接口即可。验证方法很朴素：手工从数据库里查SELECT COUNT(*) FROM flight_info WHERE DATE(actual_departure) = '2024-06-01' GROUP BY CONCAT(departure_code, '-', arrival_code)，对比前端点击当天显示的数字，逐项一致就说明链路是通的。

做这个功能时我学到的最深一课是：后端聚合参数和前端点击事件的字段，一定要在动手写代码前定好。以前我做过一个含时间维度分析的功能，后端接口参数叫date，前端点击事件里取的字段是params.data，恰好两者值一样，定位了很久才发现是接口字段名不一致。从那以后，每次接手含时间字段的分析项目，都先把“按天→按小时→按星期”的维度全列出来，让前后端照着同一张字段约定表核对，确认无误再写代码。这套源码本身不复杂，真正容易出问题的反而是维度字段名的约定，希望帮到你。

本文还有配套的精品资源，点击获取