Python航班数据可视化分析系统：从Django到MLP预测实战

1. 项目整体设计与技术选型思路

1.1 为什么选航班数据做可视化分析

毕业设计选方向的时候，我反复纠结了很久。最终定下“Python航班数据可视化分析系统”这个题目，核心原因有三个。

第一，航班数据是典型的结构化大数据样本。一份真实的航班记录通常包含航班号、出发到达城市、计划起飞时间、实际起飞时间、延误时长、航空公司、机型、天气状况等十几个字段，数据量动辄几十万条。这种数据规模非常适合用来演示大数据处理、数据清洗和可视化分析的全流程，既有业务意义又有技术深度。

第二，航班延误是每个人都遇到过的问题，业务场景贴近现实生活。用户想知道“哪个航空公司准点率最高”“哪个时段的航班最容易延误”“延误和天气到底有多大关系”，这些问题通过数据可视化可以直观回答。相比那些脱离实际业务需求的纯技术演示，这种选题在毕业答辩时更容易讲清楚，也更容易让评审老师快速理解项目价值。

第三，航班数据自带时间序列属性和多维度特征，既能做统计图表展示，又能作为机器学习预测模型的输入。利用历史数据训练MLP（多层感知机）模型来预测航班是否会延误，刚好把“数据可视化”和“机器学习”两个热点串了起来，正好覆盖了题目里所有关键词。

1.2 Django框架的选择逻辑：为什么不是Flask

做毕设之前我其实先学了Flask，因为它轻量、上手快，写个接口几行代码就完事。但真正做完整系统的时候，我还是换成了Django，理由非常实际。

Django自带Admin后台管理系统，这意味着我可以免费获得一个数据管理界面。航班数据在入库之后，如果发现某条记录有问题，直接在Admin后台改掉就行，不用自己写一堆增删改查的前后端代码。对于个人项目来说，这个效率提升非常明显。

Django的ORM（对象关系映射）层在操作大规模数据时也更有优势。几十万条航班数据的筛选、聚合、分组统计，用ORM的queryset可以链式表达，配合values()、annotate()这些方法，一条语句就能搞定复杂的统计逻辑。相比之下，Flask本身不带ORM，需要自己集成SQLAlchemy，配置成本更高。

另外Django的MTV架构（Model-Template-View）在做可视化大屏这种多页面项目时，结构边界很清晰。Model管理数据，View处理业务逻辑，Template渲染页面，三层各司其职，后期维护和扩展都更方便。

还有一个容易被忽略的点：Django的生态非常完善，Django REST Framework做API接口、Django Channels做WebSocket、Celery做异步任务，全部都有成熟方案。虽然毕设项目不一定用到所有功能，但选一个上限更高的框架，后面想扩展功能时不会捉襟见肘。

1.3 为什么MLP而不是LSTM或Transformer

看到标题里“深度学习”的时候，很多同学第一反应是上LSTM甚至Transformer。我问过自己这个问题，最终选了MLP而不是更复杂的模型，原因很实际。

航班延误预测本质上是一个表格数据分类问题，输入特征有起飞时间、航空公司、航线距离、天气状况、历史准点率等，输出是“延误”或“不延误”。这类问题的数据是结构化的表格，不涉及自然语言或序列建模，所以LSTM这种专门处理时序循环结构的模型反而不一定占优势。

MLP（多层感知机）虽然是神经网络里最基础的架构，但它在处理结构化数据时表现并不差。只要特征工程做得到位，数据标准化处理正确，两三层的MLP在航班延误预测这种问题上完全可以达到80%以上的准确率。而且MLP训练速度快，迭代调参方便，对硬件要求低，在普通笔记本上就能完成训练。

更重要的是，MLP的“可解释性”虽然不如决策树，但比LSTM还是好讲很多。毕业答辩的时候，你可以清清楚楚地画出网络结构图——输入层几个神经元、隐藏层几层、每层多少个节点、激活函数选的什么——评审老师一听就明白。你选LSTM就得解释记忆门、遗忘门、循环结构，反而容易把自己绕进去。

我的建议是：毕设模型的选择，第一原则是“能讲清楚”，第二原则才是“性能好”。MLP恰好是这两者的平衡点。

1.4 可视化方案全面对比：ECharts、Chart.js与Plotly

可视化是整个系统的门面，选型时必须谨慎。我实际对比过三种主流方案，说下我的真实体验。

Chart.js胜在轻量，压缩后只有几十KB，上手门槛极低，画个折线图柱状图基本是复制粘贴级别的难度。但它的图表类型偏基础，做交互式仪表盘、热力图、地图这种复杂图表时支持有限，做大屏展示会显得单调。

Plotly的交互性很强，图表可以缩放、悬停、联动，而且Django后端可以用plotly.io直接把图表渲染成HTML插入页面，不用写一行前端代码。但它是重型库，图表渲染速度慢，数据量大时有明显卡顿，而且做“数据可视化大屏”这种高密度信息展示时，风格更像研究型图表，不够炫酷。

最终我选了ECharts，原因有三。

一是图表类型极其丰富。折线图、柱状图、饼图、散点图、热力图、地图、雷达图、关系图应有尽有，而且支持多图表联动，做可视化大屏绰绰有余。

二是性能优秀。ECharts基于Canvas渲染，加载10万级数据点依然流畅，配合dataZoom组件还能做局部缩放，完美匹配航班数据的大数据量场景。

三是配置灵活，可定制程度高。不管是配色方案、动画效果还是交互事件，都能通过配置项控制。做出来的图表天生带“互联网大厂风”，视觉效果好，答辩时加分明显。

技术方案的最终组合是：Django + ECharts + SQLite/MySQL + scikit-learn的MLPClassifier。前端页面用Django模板引擎渲染，数据接口用Django视图返回JSON格式，前端通过Ajax请求接口拿数据后交给ECharts绘制。

2. 数据准备与预处理实战

2.1 数据集来源与原始数据形态

做数据分析，最头疼的不是怎么写代码，而是从哪拿数据。如果你在学校，最稳妥的方案是去Kaggle下载美国航班延误数据集，里面有几百万条记录，字段完整，质量也还行。如果网络不方便，也可以在国内的第三方数据共享平台找一些脱敏后的航班样本数据。

我最终用的是Kaggle上的Flight Delay数据集，选它有几个理由：字段丰富、规模适中（几十万条）、自带明确的分类标签，而且网上相关教程多，遇到问题好解决。

原始数据的CSV文件长这样：

拿到数据的第一步就是别急着写代码，先打开CSV文件摸一遍数据。看看哪些字段缺失、哪些字段类型不对、有没有异常值。这一步虽然枯燥，但能避免后面很多返工。

2.2 字段理解与业务含义映射

做数据清洗之前，必须先理解每个字段的业务含义，不然清着清着就会迷失方向。航班数据分析的场景里面，有几个字段需要特别注意。

DepartureDelay和ArrivalDelay是核心目标字段，后面做MLP预测时就是拿这两个字段定义“是否延误”的标签。我定义的规则是：延误超过15分钟算作“延误”，否则算“准点”。这个15分钟阈值不是随便拍的，民航业务里通常把15分钟作为准点率统计的分界线，用业务标准定义标签，答辩时也站得住脚。

WeatherDelay字段在很多数据集中缺失率很高，要单独处理。如果直接删除，会丢失天气因素的信息；如果填充为0，又会引入偏差。我最后采用的方法是：将WeatherDelay转成布尔特征has_weather_delay，缺失值统一填充为False，这样既保留了信息又不影响模型输入。

Distance字段在不同数据集中单位不统一，有的是公里有的是英里。换算统一之后，我把它分桶成短途、中途、长途三个类别，用于后面的分组统计分析。分桶之后的数据更符合可视化展示的需求，画饼图时不会因为数值太分散而看不清楚。

2.3 数据清洗的三个关键步骤

数据清洗是整个项目里最花时间但价值最高的环节，每一行代码都值得认真对待。

第一步是缺失值处理。我用pandas的isnull()方法逐列统计缺失率，处理策略是这样的：缺失率低于5%的数值型字段用中位数填充，分类字段用众数填充；缺失率高于30%的字段直接删除。注意这里有个细节：填充数值型字段时优先用中位数而不是均值，因为航班延误数据往往有长尾分布，均值会被极端值带偏，中位数更稳健。

第二步是异常值检测。航班数据里经常会出现延误几千分钟的极端记录，这种数据要么是录入错误，要么是极端天气导致的特殊情况。我通过IQR（四分位距）方法检测：计算ArrivalDelay的Q3和Q1，超过Q3 + 1.5 * IQR的记录标记为异常。处理方式不是直接删除，而是设置一个上限（比如延误超过300分钟的按300分钟算），这样既保留了极端样本的存在性，又不会让它们干扰模型训练。

第三步是时间字段拆解。CSV里ScheduledDeparture是“08:30”这种字符串格式，直接用于分析非常不便。我把计划起飞时间拆成“小时”和“星期几”两个新特征，因为航班延误和时段有很强的关联——早班机准点率高，晚班机由于航班积压延误概率更大。这一步小小的特征工程，对后面MLP模型的准确率提升帮助很大。

清洗完成之后，数据从原始的几万条变为可用的结构化数据表，我用Django的ORM定义了对应的模型类，通过脚本批量导入数据库。MySQL和SQLite我都试过，如果你的数据量在几十万条级别，SQLite完全够用，部署时还省去配置数据库的麻烦；如果数据量超过百万，建议直接用MySQL，否则查询会明显变慢。

2.4 数据存储与Django ORM模型设计

Django的ORM模型设计直接决定后续开发的效率，这里的关键是为“统计查询”而不是“单条操作”设计表结构。

我定义的Flight模型核心字段包括：航班日期、航空公司、航班号、出发到达机场、计划起飞时间（整数类型，存24小时制的数值）、实际起飞时间、延误分钟数、是否延误（布尔类型）、航线距离（公里）、天气延误标志。所有字段都加上db_index=True索引，因为后面可视化页面要频繁按日期、航空公司做分组统计，没有索引的大表查询会慢到让人怀疑人生。

模型定义好之后，跑python manage.py makemigrations和python manage.py migrate建表，再写一个import_data.py脚本读取清洗后的CSV，批量写入数据库。强调一下：导入数据时一定要用bulk_create()批量写入，一次提交1000条左右的记录，几十万条数据一分钟内就能导完。如果你一条一条save()，可能要等十几分钟。

导入完成后，在Django Admin后台看一眼数据量和数据样例，确认无误后再开始写可视化页面。

3. 可视化模块的实现：从接口到图表

3.1 后端接口设计：高效返回统计聚合数据

可视化页面需要的数据不是原始数据表，而是聚合统计结果。我不建议直接在Django视图里写一堆pandas代码处理数据再返回，正确做法是先把聚合逻辑写在视图里，用ORM的annotate()和values()直接完成分组统计。

举个例子，要统计“各航空公司平均延误时长”的柱状图数据，我写了一个独立的Django视图，核心代码只有几行：

from django.db.models import Avg from django.http import JsonResponse from .models import Flight def airline_delay_api(request): result = ( Flight.objects .values('airline') .annotate(avg_delay=Avg('delay_minutes')) .order_by('-avg_delay') ) data = [ {'airline': item['airline'], 'avg_delay': round(item['avg_delay'], 1)} for item in result ] return JsonResponse({'code': 200, 'data': data})

这段代码的原理是让数据库完成分组聚合计算，只把统计结果返回给前端，而不是把几十万条原始记录全部传到浏览器端再计算。这一点非常关键，很多同学做出来的系统页面卡顿，八成都是因为后端返回了太多冗余数据。

为了提高接口复用性，我设计了统一返回格式，固定包含code、message、data三个字段，前端拿到code === 200再渲染。后续扩展新图表时，只需要新增视图和URL路由，前端页面通过Ajax请求对应的接口就能拿到数据，不用改动已有代码。

3.2 核心图表类型选择与业务场景匹配

不同的业务问题适合不同的图表类型，我在做可视化的过程中积累了一些经验。

对比类数据用柱状图。比如“各航空公司准点率排名”用横向柱状图就很直观，图表上航空公司名称放左侧，准点率数值放右侧，一眼就能看出谁高谁低。

趋势类数据用折线图。比如“每日航班量趋势”“工作日与周末延误率对比”，折线图能清晰展示随时间变化的规律。我做了两个折线图放在大屏中间位置：一个是近N天的航班量走势，一个是每小时的准点率变化，访客一眼就能看到“早上8点的航班准点率最高”这种有意思的结论。

构成类数据用饼图。比如“延误原因分布”——天气、空中管制、航空公司和前序航班晚到的占比，用环形饼图展示非常合适，中心留白区域还可以放总数标注。

分布类数据用直方图。比如“延误时长的频率分布”，能直观看出延误大多集中在15到60分钟区间，长延误是小概率事件，这种分布形态用直方图表达最准确。

关系类数据用散点图。比如“航线距离 vs 延误时长”，可以观察两者之间是否存在相关性。这里有个代码细节：数据量较大时，ECharts的scatter类型配合large: true配置项会开启大规模散点图模式，渲染性能提升非常明显。

为了让大屏不显得单调，我还加入了一个地理分布可视化：用ECharts的中国地图展示各航线出发城市的航班量热力分布。地图需要引入GeoJSON数据，ECharts 5版本之后地图数据需要单独下载，这里有个坑后面再说。

3.3 可视化大屏的布局与交互设计

大屏布局是整个可视化模块的视觉核心，直接决定评审老师的第一印象。我的布局方案是经典的“三列式”：顶部一行放系统标题和核心KPI指标卡片（航班总数、准点率、平均延误时长、受天气影响航班数），中间部分左、中、右三列分别放图表，底部放数据表格或时间筛选器。

KPI卡片是最容易出效果的地方，花五分钟用CSS写几个彩色卡片，数据用大号数字展示，一眼就能抓住注意力。我用Django模板变量直接渲染KPI数据，后端在视图函数里通过ORM聚合计算出这几个数值，模板里用{{ total_flights }}这种变量占位输出，等同于在服务端完成了数据注入。

图表的配色我统一用了深色主题，背景是深蓝灰，柱状图和折线图用亮色系（橙色、青色、绿色），重点数据用高亮色。这种配色方案在投影演示时非常醒目，而且视觉上比纯白背景更有科技感。ECharts的color配置项可以直接控制调色板，不用每张图单独配置。

交互方面做了三个关键设计。第一个是时间筛选联动，页面顶部放了日期范围选择器，切换时间段后所有图表通过Ajax重新请求对应接口并更新，实现全局联动。第二个是图表间的联动高亮，在ECharts中配置legend和dataZoom组件，用户在折线图上缩放日期范围，柱状图和饼图的数据也会同步过滤。第三个是tooltip优化，鼠标悬停到数据点时展示详细信息，比如“6月5日 8:00-9:00 时段，航班量568架次，准点率87.5%”，让用户能深挖数据。

工期和代码量节省方面，我给所有图表封装了一个统一的初始化函数，传入配置对象即可生成图表。不同图表之间只改type（bar/line/pie/scatter的切换）和data部分，其余样式配置复用。实际做下来，写5张图表的代码量和写2张图表差不多。

3.4 前端模板与静态资源组织

Django模板的组织方式直接决定项目后期维护的难易程度。我的做法是：templates目录下按功能分子目录，index.html是大屏总页面，chart_data.html是数据表格页面，manage.html是数据管理页面。静态文件（CSS、JS、图片）统一放在static目录下，ECharts的CDN和本地包我都试过，最后选择下载到本地，避免答辩现场网络掉链子。

模板中渲染数据的核心方式是“Django模板变量 + JavaScript全局变量”。后端视图将KPI数据通过render()传入模板，模板里用{{ kpi_data | safe }}把字典转成JavaScript对象，前端脚本再读取这个对象填充到页面上。这种方式比异步请求更简单直接，首次加载页面时数据就已经展示出来了，体验更流畅。

对于图表区域，则统一采用Ajax请求接口的方式动态加载。这样有一个额外的好处：页面初始加载不会因为等待全部图表数据而阻塞，用户看大屏时图表是一个个“跳”出来的，视觉上反而更生动。

4. MLP模型在航班预测中的应用

4.1 从零理解多层感知机（MLP）

MLP全称Multi-Layer Perceptron，多层感知机，是最基础的人工神经网络结构。它的结构可以拆成三部分：输入层、隐藏层和输出层。每一层由若干个神经元组成，相邻层之间的神经元通过带权重的连接线互相连接。

可以把它理解成一个“多层决策流水线”。输入特征进入第一层神经元，每个神经元把输入值乘以对应权重再加一个偏置，经过激活函数后输出给下一层。信息从输入层流经隐藏层，逐层提取特征模式，最后到达输出层得到预测结果。用大白话说，MLP就是一堆简单的计算单元堆叠起来，通过学习调整连接权重来拟合输入和输出之间的复杂映射关系。

为什么MLP能处理航班延误预测这种问题？核心在于隐藏层的非线性变换能力。航班延误的影响因素是复杂的：天气、流量、前序航班状态、机场保障能力之间不是简单的线性关系。MLP通过ReLU、tanh这类激活函数引入非线性，理论上可以逼近任意连续函数，所以能够学习到延误背后的非线性规律。

对于“MLP和BP网络有什么关系”这个问题，我在准备答辩时专门理清了：BP（Back Propagation，反向传播）是MLP训练时使用的优化算法，它根据输出层误差从后往前逐层修正网络权重。MLP指的是网络结构，BP指的是训练方法，二者是“被训练的模型”和“训练方法”的关系，常说的“BP神经网络”其实指的就是用BP算法训练的多层感知机。

4.2 特征工程：决定模型上限的关键因素

做MLP预测航班延误，我踩过最大的坑就是一开始把所有原始字段直接塞进模型，效果惨不忍睹。后来才明白，特征工程的质量直接决定模型性能的上限。

我的特征体系包括三部分：

第一是时间特征。起飞小时（0-23的数字）、星期几（0-6）、是否周末（布尔值）。这三个特征价值很大，因为航班延误有明显的时段效应和星期效应。

第二是业务数值特征。航线距离（公里）、前序航班准点率。前序航班准点率这个特征算起来比较麻烦，需要先按航线分组统计历史准点率，再回填到当前数据。这个特征对模型贡献非常明显，因为前序航班晚到会直接导致后续航班延误。

第三是分类特征编码。航空公司、出发机场、到达机场这三个字段都是字符串类别，不能直接喂给MLP，我用了两种编码方式。航空公司字段类别数量少，用LabelEncoder做序号编码就够。出发机场和到达机场类别多且无天然顺序，用OneHotEncoder做独热编码。这里有个细节提醒：用了独热编码后特征维度会暴涨，所以我对机场只取出现频率最高的前30个做编码，其余归为“其他”类别，控制维度在合理范围内。

特征准备好之后，千万不能忘记标准化。MLP对输入特征的尺度非常敏感，距离的数值范围是几百到几千，而小时是0到23，如果不做标准化，距离特征就会主导权重更新，模型很难收敛。我用StandardScaler把每个特征转换为均值为0、标准差为1的分布，这个操作对MLP来说几乎是必选项。

4.3 模型训练与调参实战

我用的是scikit-learn的MLPClassifier，原因很简单：接口成熟、文档完善、不需要写复杂的训练循环。

from sklearn.neural_network import MLPClassifier from sklearn.model_selection import train_test_split from sklearn.preprocessing import LabelEncoder from sklearn.metrics import accuracy_score, classification_report X_train, X_test, y_train, y_test = train_test_split( X_scaled, y, test_size=0.3, random_state=42 ) model = MLPClassifier( hidden_layer_sizes=(64, 32), # 两个隐藏层 activation='relu', # 激活函数 alpha=0.001, # L2正则化系数 learning_rate_init=0.001, # 初始学习率 batch_size=256, max_iter=200, random_state=42 ) model.fit(X_train, y_train) y_pred = model.predict(X_test) print(accuracy_score(y_test, y_pred))

隐藏层结构我做了多轮对比实验。最开始用单层32个神经元，准确率在76%左右；改成两层(64, 32)后，准确率提升到82%；再往上加到(128, 64, 32)三层时，准确率没有明显提升，反而训练时间翻倍。最后敲定使用(64, 32)两层结构——性能和数据规模匹配，不容易过拟合。

学习率是另一个需要仔细调的关键参数。0.01的学习率训练速度快但损失震荡明显，0.0001太慢而且容易困在局部最优。0.001配合adam优化器是我测试下来最稳的组合。这里说句题外话：很多同学喜欢去调max_iter（最大迭代次数），但是其实模型收敛质量和学习率、批大小的关系更大，不建议一上来就堆迭代次数。

调参过程中我还刻意做了数据降采样。因为原始数据中“准点”样本远多于“延误”样本，直接训练的话模型会偷懒，把所有样本都预测成“准点”，准确率看似很高其实毫无意义。我采样出正负样本大致均衡的训练集，确保模型真正学到了延误的规律，而不是只会“猜多数类”。

最终模型在测试集上达到了82.3%的准确率、79.6%的F1分数（这里是示例数值），在答辩演示中完整展示了训练过程、评估指标和混淆矩阵，效果很不错。

4.4 模型结果反向赋能可视化页面

模型训练完不能孤零零躺在那里，要让它成为系统的一部分。我开发了两个功能把MLP预测结果接入可视化系统。

第一个是“延误预测”表单页。用户在页面上选择航空公司、出发时间、出发到达机场，填写航线距离，点击预测按钮，后端接收参数后做同样的特征编码和标准化，调用训练好的MLP模型输出预测概率，返回“预计准点”或“预计延误”以及置信度，前端把结果显示在卡片上。这个功能交互性强，答辩时能让评委亲手操作，印象分直接拉满。

第二个是把模型的特征重要性可视化。虽然MLP不像决策树那样自带特征重要性属性，但我通过“置换重要性”（Permutation Importance）方法估算：每次随机打乱一个特征列，观察模型准确率下降多少，下降越多说明该特征越重要。把计算结果用条形图展示出来，能直观告诉用户“哪个因素对航班延误影响最大”。用这个方法展示后，整个项目的技术层次就从“会训练模型”提升到了“理解模型”。

5. 常见问题与排查技巧实录

5.1 后端接口与静态文件的踩坑记录

开发过程中最常见的错误之一是Django的跨域问题。如果前后端分离部署，前端页面和Django服务在不同端口上运行，Ajax请求默认会被浏览器阻断。用django-cors-headers这个库可以解决：

pip install django-cors-headers

然后在settings.py中添加应用和中间件，配置允许的来源。

INSTALLED_APPS = [ 'corsheaders', # 其他应用 ] MIDDLEWARE = [ 'corsheaders.middleware.CorsMiddleware', # 其他中间件 ] CORS_ALLOW_ALL_ORIGINS = True

毕设演示阶段直接允许所有来源即可。但如果你打算上线，建议改为明确的域名白名单。

第二个高频坑是Django静态文件404。开发环境调试时要在settings.py里设置STATIC_URL和STATICFILES_DIRS，然后在项目的urls.py里加一行：

from django.contrib.staticfiles.urls import staticfiles_urlpatterns urlpatterns += staticfiles_urlpatterns()

如果不加这行，Django默认不会在开发服务器上托管静态文件，ECharts.js、自定义CSS都会加载失败，页面样式全丢。

第三个坑是JsonResponse遇到datetime类型数据报错。航班数据里有日期字段，直接放在JsonResponse里会报“Object of type date is not JSON serializable”。解决办法是使用Django自带的DjangoJSONEncoder，或者统一把日期转成字符串格式。我选择了后者，视图里处理数据时就将日期格式化为YYYY-MM-DD字符串，简单粗暴。

5.2 大数据量下页面卡顿的优化方案

可视化页面加载慢是毕设答辩时的高频翻车点，我至少遇到了三种情况。

第一是查询慢。几十万条数据全量查询耗时几秒，用户体验极差。优化方案是给常用查询字段加上组合索引，比如('flight_date', 'airline')组合索引。另一个思路是建立AgGRID汇总表：提前用cron或管理命令跑好每日聚合，把统计结果存入单独的数据表，前端查询只搜汇总表，响应时间从秒级降到毫秒级。

第二是前端渲染卡顿。一次加载上万条数据点渲染在ECharts上，浏览器会明显掉帧。解决办法：后端接口做过数据抽样，返回给前端的数据上限控制在1000条左右。比如折线图按响应用户请求返回聚合后的数据，就降低了绘图压力。

第三是页面初始化重复请求过多。大屏页面上有六七张图表，每张图表一个独立Ajax请求，页面加载时全部并发发出，服务器压力大。我给每个图表接口都加了Redis缓存，前端请求时Django优先按缓存key读Redis，命中就直接返回缓存数据。首次加载后，后续请求均走缓存，几乎无延迟。

5.3 MLP模型训练中的若干坑

第一个坑是数据泄漏。如果先对全量数据做标准化再划分训练集和测试集，相当于测试集的信息已经“泄漏”到了训练过程中，准确率虚高但实际部署时表现很差。正确做法是只用训练集拟合StandardScaler，再用同样的参数转换测试集。这个细节我在答辩时专门提到，评委老师直接点头示意认可。

第二个坑是特征工程必须保持一致性。训练时用了LabelEncoder对航空公司编码，预测时新数据也必须用同一个编码器实例，不能重新fit()。解决办法是用joblib.dump()把训练好的模型和编码器打包保存到本地文件，需要时再加载，确保部署环境下的处理方式与训练时完全相同。

第三个坑是正负样本不平衡导致模型“学废了”。如果不做数据均衡，模型大概率会学成“永远预测准点”，因为准点样本占比高，这样预测“准点”的总体损失最小。我的解决方案是结合正负样本数量和偏差，使用class_weight参数或者过采样少样本。毕设场景下建议用简单方法，比如直接对少数类样本做复制重采样。

第四个坑是MLP对特征缩放敏感。这个前面提过，这里再说一遍是因为真的太容易忽略。有次我把标准化步骤写漏了，模型loss直接不收敛，排查了半小时才发现是这个小问题。新手做MLP，请把特征标准化刻在脑子里。

5.4 部署阶段的环境问题汇总

部署到服务器是整个项目中最后一个大坑集中地。我搜集了几个最典型的场景。

如果要在麒麟或国产Linux系统上跑Django，python版本兼容性是第一道坎。建议使用python3.8及以上版本，先确认系统自带的pip环境，再创建虚拟环境，然后用requirements.txt逐个安装依赖。Django版本尽量选3.x以上（推荐3.2/4.2），和Python新版本的兼容性更好。

如果遇到ModuleNotFoundError: No module named 'pip'，说明Python环境里pip没装好，执行python -m ensurepip --upgrade可修复。渗透测试环境如果连不上外网，就下载对应离线whl包手动安装。

用宝塔面板部署Django是很多人的首选，可视化操作省心。把Django项目传到服务器后，配置Python项目管理器，设置启动方式为gunicorn，然后在站点管理中做反向代理，把域名或IP的80端口转发到gunicorn监听的127.0.0.1:8000端口。部署完成后记得放行安全组端口，否则外部访问不通。

数据库方面，如果在服务器上切换到了MySQL，需要安装mysqlclient或pymysql驱动。推荐使用pymysql，因为它在很多Linux环境下免编译直接安装。在项目的__init__.py中加入：

import pymysql pymysql.install_as_MySQLdb()

最后，部署完成后视频演示时偶尔会出现“图表加载不出来”的尴尬情况，多数是因为浏览器控制台有跨域或静态资源404。提前用无痕模式打开系统，确认全部资源和接口正常工作后再开始录屏或演示。

6. 总结心得与个人经验分享

做这个毕设项目的整个过程，从数据分析到可视化呈现，再到MLP模型搭建，踩过的坑远比想象中的多。我个人印象深刻的有三点体会。

第一，毕业设计不要贪大求全，关键是把一条主线做透。我最终做的是“数据采集-清洗-存储-可视化-模型预测”的完整闭环，每个环节都有实际产出。相比那些堆砌了十个功能但每个都是半成品的项目，这种闭环更容易让评委感受到你的工程能力。

第二，模型越简单越好，但数据处理绝不能简单。MLP本身只是几十行代码的事情，真正拉开差距的是特征工程和数据清洗的质量。有时候甚至不需要复杂的调参，只要数据处理好、特征做干净，模型性能自然就上去了。

第三，项目的讲解能力要“刻意练习”。我在正式答辩前自己模拟了至少三遍：快速打开系统、依次展示各页面图表、现场跑一次延误预测、对着混淆矩阵解释模型效果。整个流程熟练之后，答辩时就不会因为紧张而卡壳。

最后向各位同学分享一个扩展思路：这个系统的可视化模块和模型模块是解耦的，想升级的话，可以把数据源换成真实API接口实现实时数据展示。

我建议，如果你是对Python、数据分析、机器学习感兴趣的学生，这个选题方向非常值得尝试。你不需要成为每个领域的专家，只要把Django框架、数据可视化、MLP这三个点吃透，做出一个能上台演示的完整系统是完全可行的。

加油，期待你们的作品比我做得更好。