做毕设选题目的时候我见过太多人一头扎进XX管理系统里数据库里塞几张表前端做个增删改查美其名曰毕业设计。说实话这种项目做完了除了能毕业写进简历里连个水花都溅不起来。同样是Python栈同样是Django如果你把选题换成旅游人流量预测分析那你的项目就同时拥有了Web开发、机器学习、数据分析、可视化四条技术线随便挑一条都能在面试里聊半小时。这篇文章我就把这个系统的技术链路拆开讲透从数据怎么准备、线性回归模型怎么落地、Django怎么把模型包装成服务到ECharts怎么做可视化大屏最后再把毕设里最容易踩的坑挨个点名。不管你是要用这套思路自己做毕设还是单纯想学一下Django 机器学习怎么打通这篇都应该能给你省下大量瞎试的时间。1. 这套旅游人流量预测系统解决的是什么问题先说清楚这个项目到底是干嘛的。它不是景区票务管理系统不是旅游推荐系统核心功能只有一件事给定一个未来的日期结合天气、节假日、历史流量等条件预测某个景区那一天大概会来多少人。听起来不复杂但对毕设来说这个选题有几个天然优势。第一问题边界清晰输入输出都非常明确不会做着做着失控。第二它是一个预测类项目天然适合套机器学习模型不像管理系统那样硬凑一个朴素贝叶斯上去答辩时逻辑是顺的。第三预测结果可以用可视化的形式展示出来ECharts大屏配上去演示效果直接拉满。1.1 为什么预测分析比信息管理更值钱管理系统的本质是数据的增删改查技术含量主要集中在CRUD的工程实现上。而预测分析系统的本质是从历史数据中找规律然后用它回答未来的问题这中间涉及数据处理、特征构造、模型训练、结果评估、系统集成每一个环节都能单独拿出来讲。更重要的是这套逻辑是可以迁移的。电商预测销量、外卖预测单量、共享单车预测调度量底层链路一模一样。所以做完旅游人流量预测你简历上写的其实是我具备从数据到模型再到产品化的完整经验而不是我熟悉框架的增删改查。1.2 项目整体技术链路拆解整个系统从数据到展示走通一条完整流水线数据层Pandas做数据清洗与特征工程数据源包括景区历史客流、天气信息、节假日信息模型层scikit-learn的LinearRegression做流量预测通过joblib完成模型持久化服务层Django处理HTTP请求接收前端传入的预测日期与景区ID返回结构化JSON展示层ECharts绘制历史流量曲线、未来预测曲线、景区热度对比组合成可视化大屏这里有一个很多人搞混的点Django和机器学习模型的关系。模型不是在Django里训练的训练是离线完成的生成一个.pkl文件Django只是把这个文件加载进来调用predict方法。这种训练与推理分离的设计非常重要后面我会详细说为什么。2. 数据建设预测的灵魂在特征不在算法如果只能给一句忠告我会说这个项目花在数据上的时间至少要和花在代码上的时间一样多。线性回归模型的数学过程很简单但喂给它的数据干不干净、特征全不全直接决定预测结果能不能看。2.1 数据来源的三条路毕设场景下获取景区历史客流数据没那么难常见有三种思路。第一种找公开统计。很多旅游网站和省市文旅局的月度数据是公开可查的拿来做年度维度的预测没问题。第二种用官方提供的开放数据集Kaggle上也有不少景区客流相关的数据。第三种如果实在找不到合适的数据可以根据景区容量和淡旺季规律人工构造一份仿真数据但一定要在论文里明确标注这是模拟数据不能拿去当真实结论。天气和节假日数据则简单得多。天气可以用常见的天气API节假日直接用chinese_calendar这个Python库就能判断某一天是不是法定节假日。这些都是现成的轮子不见得非得自己爬。2.2 特征工程该做哪几类特征模型预测质量的上限其实在你构造特征时就定下来了。我实际用下来这几类特征对景区流量影响最大。时间特征年份、月份、几号、星期几、是否周末、是否节假日。节假日是流量暴增的核心因素五一、国庆这种长假前后流量曲线完全是另一个形态天气特征最高温、最低温、天气类型晴/雨/阴。下雨天景区流量断崖下跌这个特征不能缺历史状态特征前一天的客流量、最近7天平均客流量。景区客流有很强的惯性昨天人多今天通常也不少这类滞后特征对线性回归的收益非常明显类别特征景区ID或景区容量分档。如果系统支持多景区必须把景区差异编码进特征里否则模型会混淆不同景区的量级特征不是越多越好。我见过有同学把农历日期也塞进去结果对线性回归来说这只是一个没有意义的数字。特征要有业务含义要能解释得通答辩时老师问为什么选这个特征你得答得出来。2.3 数据清洗一场让线性回归差点翻车的经历说个我实际踩过的坑。当时做某景区的数据有一天的客流量突然冲到历史平均值的8倍原因是当地办了一场音乐节。如果不对这个异常值做处理线性回归的拟合曲线会被这根刺整个拉偏导致普通日子的预测值全部偏高。我的处理方式是先画折线图看肉眼异常再用3倍标准差或者IQR四分位距方法做定量筛查。对超过阈值的样本如果是大型活动导致的可解释异常可以单独标记而不是直接删除如果查不到原因直接剔除更稳妥。另一个容易被忽略的点是节假日表的维护。千万不要手工维护一份节假日清单每年节假日时间都变手工维护必出问题。直接用chinese_calendar.is_holiday(date)调用判断几行代码解决。3. 线性回归模型数学原理、实现与够用的边界模型选型上线性回归是这类时序预测的基准选择尤其适合做毕业设计。原因很现实它足够简单简单到你有精力把原理吃透答辩时能讲清楚同时它又足够有效在景区流量预测这种场景下能给出一个相当不错的结果。不要一上来就上LSTM、Transformer第一模型难调第二如果连线性回归的预测效果都搞不明白换了复杂模型更容易失控。3.1 最小二乘法从公式到直觉线性回归要拟合的目标函数是y w1x1 w2x2 ... wnxn b其中x1到xn就是前面构造的特征w是每个特征的权重b是偏置。权重越大说明对应特征对客流的影响越大。这就是线性回归最大的优点——可解释性。模型训练的过程就是要找一组w和b让预测值和真实值之间的误差平方和最小。这就是最小二乘法这个名字的由来。令损失函数L Σ(yi - ŷi)²对每个w求偏导并令其等于0就能解出最优权重。sklearn底层封装的就是这套过程但原理必须自己会推因为答辩老师几乎必问。3.2 sklearn实现训练、评估、保存一条龙直接上核心代码训练部分一共也没几行import pandas as pd from sklearn.model_selection import train_test_split from sklearn.linear_model import LinearRegression from sklearn.metrics import mean_absolute_error, r2_score import joblib df pd.read_csv(attraction_flow.csv, encodingutf-8) features [month, day, weekday, is_holiday, is_weekend, temp_high, weather_code, prev_flow, week_avg] X df[features] y df[flow] # 注意时序数据必须按时间顺序切分不能随机打乱 X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, shuffleFalse ) model LinearRegression() model.fit(X_train, y_train) y_pred model.predict(X_test) print(MAE:, mean_absolute_error(y_test, y_pred)) print(R2:, r2_score(y_test, y_pred)) joblib.dump(model, flow_model.pkl)这里有一个很多新手会犯的致命错误时序数据切分时用了默认的shuffleTrue。表面上看训练集和测试集都挺正常但测试数据实际上混进了未来信息评估指标会虚高等你拿去预测真正没见过的未来时效果立刻露馅。时间序列数据必须用shuffleFalse严格按时间先后切分。3.3 评估指标怎么理解R²不是唯一标准我用了一组真实仿真数据测过包含时间、节假日、天气特征后线性回归的R²大概在0.82到0.88之间MAE大约在800到1200人左右。对这个场景来说已经属于能讲故事的水平。评估指标要综合看。R²反映了模型对整体方差的解释程度越接近1越好但对客流这类噪声很大的数据0.8以上就说明趋势抓得挺准。MAE则是更直观的指标——平均误差1000人对于一个日均2万人的景区来说就是5%的偏差完全可以接受。我还建议额外加一组对比实验把随机森林模型也跑一遍和线性回归的结果做对比。哪怕随机森林略好一点你可以在论文里分析线性回归的优势在于可解释性和稳定性随机森林的优势在于非线性拟合但对异常值更敏感。这一组对比实验是答辩加分的常见操作。3.4 线性回归的边界什么时候该换模型线性回归的问题也很明显它对特征和目标的线性关系敏感无法处理复杂的非线性交互。比如周末、节假日、雨天这三个因素叠加在一起对客流的影响就不是简单相加了——节假日的作用会被雨天大幅削弱这种交互效应线性回归抓不住。如果实测发现线性回归的误差很大或者残差图有明显模式下一步可以尝试梯度提升树XGBoost/LightGBM或者Prophet。但我的建议是先跑通线性回归把整套系统做完整再按需引入更复杂的模型。大部分毕设的完成度问题不是模型不够先进而是工程链路没打通。4. Django工程落地从训练好的模型到可视化页面模型训练好了文件也存下来了接下来就是把它包装成一个Web服务。Django在这一环节最大的优势就是全家桶ORM处理数据库、URL路由做接口、模板系统渲染页面一个框架全包了。4.1 项目结构与URL路由初始化工程django-admin startproject tourism_forecast cd tourism_forecast python manage.py startapp forecast建议拆两个app一个forecast放预测相关的接口一个core放首页和大屏页面。别把所有功能都堆在一个app里哪怕毕设也一样代码分模块放后面改起来才知道香。URL层面的核心路由from django.contrib import admin from django.urls import path from forecast.views import forecast_api from core.views import dashboard urlpatterns [ path(admin/, admin.site.urls), path(api/forecast/, forecast_api, nameforecast_api), path(, dashboard, namedashboard), ]4.2 视图层如何调用机器学习模型这是Django和机器学习集成最关键的代码。视图收到前端请求后要把日期参数转换成模型需要的特征向量再调用加载好的模型做推理。import joblib from datetime import datetime from django.http import JsonResponse from django.views.decorators.csrf import csrf_exempt from chinese_calendar import is_holiday, is_workday # 模型只加载一次避免每个请求都重新读文件 model joblib.load(ml_models/flow_model.pkl) csrf_exempt def forecast_api(request): date_str request.GET.get(date, ) temp_high float(request.GET.get(temp_high, 20.0)) weather_code int(request.GET.get(weather_code, 0)) prev_flow float(request.GET.get(prev_flow, 0)) week_avg float(request.GET.get(week_avg, 0)) try: date_obj datetime.strptime(date_str, %Y-%m-%d).date() except ValueError: return JsonResponse({error: 日期格式错误应为YYYY-MM-DD}, status400) features [ date_obj.year, date_obj.month, date_obj.day, date_obj.weekday(), int(is_holiday(date_obj)), int(date_obj.weekday() 5 or is_holiday(date_obj)), temp_high, weather_code, prev_flow, week_avg, ] predicted model.predict([features])[0] return JsonResponse({ date: date_str, predicted_flow: round(float(predicted), 2), })注意模型加载体应该放在模块顶层而不是视图函数内部。如果放在函数里每来一个请求就重新读一次磁盘上的pkl文件性能会很难看。放顶层的话进程启动时加载一次后面所有请求共用内存里的模型实例。4.3 CSRF、跨域与数据库选型前端页面如果和Django同源部署跨域问题不存在但如果你的前端开了单独的开发服务器比如用Vite或直接双击打开HTML文件就会出现跨域请求被拦截的情况。这时候装一个django-cors-headers在settings.py里配置允许的域名即可毕设阶段用放开模式就够了。数据库这块没有复杂关联查询需求SQLite完全够用。你甚至可以把预测结果历史记录、票务基础信息都放进SQLite一份文件备份带走答辩演示环境迁移非常方便。5. 可视化大屏ECharts接入与前端交互设计预测结果如果只是返回一个JSON数字演示效果会大打折扣。把数据图表化、大屏化之后整个项目的气质立刻就不一样了这也是这个项目在答辩现场看起来厉害的关键一环。5.1 大屏的信息架构我建议参考常见的TOP级数据大屏布局深色渐变背景顶部放系统标题和当前时间中间主区域放未来7天客流量预测折线图左侧栏放TOP5热门景区客流柱状图右侧栏放关键指标卡片今日预测量、本周累计、同比变化底部放景区热度热力图。页面上所有数据都不是写死的而是通过fetch请求后端的/api/forecast/接口拿到。这就把Django后端和前端串成了一个整体。5.2 让ECharts动起来的核心代码引入ECharts之后关键是数据格式的对接。折线图的数据一般需要两组数组一组是日期字符串一组是对应的预测值fetch(/api/forecast/?date2025-05-01temp_high26weather_code1prev_flow18000week_avg15200) .then(res res.json()) .then(data { myChart.setOption({ xAxis: { type: category, data: data.dates }, yAxis: { type: value, name: 客流量(人) }, series: [{ type: line, smooth: true, data: data.values, areaStyle: { opacity: 0.3 } }] }); });我实际做完之后的经验是前端重点不是堆酷炫效果而是保证数据链路通。先让一张折线图根据接口数据渲染出来再把柱状图、热力图逐步加上去。大屏页面适合用grid布局切分区域每个图表一个独立容器各图表通过resize()监听窗口变化防止缩放时图表变形。5.3 交互细节按日期预测与历史对比只展示未来预测还不够建议加一个日期选择器。用户可以选择任意日期前端把日期、天气参数组装成请求参数发给后端后端实时返回预测结果图表随之更新。这一套交互逻辑能让老师在答辩现场亲自动手操作——参与感上来了分数自然不会低。一个我后来补上的功能是历史真实曲线 vs 未来预测曲线同图对比。把过去30天的真实客流画成实线未来7天的预测客流用虚线接在后面视觉上会有一条连贯的延伸感业务上的解释也变得更好讲这是基于历史规律外推得到的趋势。6. 毕设顺利跑通的最后防线环境、细节与答辩技巧系统功能都做完了最后真正卡住人的往往是一些不起眼的环境问题。我把自己经历过和帮别人排查过的坑列在这里每一项都是血泪经验。6.1 环境配置翻车重灾区Python版本问题排第一。sklearn和Pandas对Python版本有要求在Windows上尤其容易出幺蛾子。建议统一用Python 3.10或3.11创建独立的虚拟环境后再安装依赖。尽量用requirements.txt锁定版本django4.2,5.0 scikit-learn1.2 pandas2.0 chinese-calendar1.9 django-cors-headers4.0Django版本影响很大。Django 4.x的URL写法倒是向后兼容但一些第三方组件的兼容性不一定跟得上所以务必锁住版本。我见过有人用Django 5.0跑旧教程的代码结果url()函数都变了排查了半天。6.2 中文乱码、时区与跨域问题数据文件里有中文比如景区名称Pandas读取时要指定encodingutf-8如果遇到读取报错多半是文件实际是GBK编码改成encodinggbk试一下。Django写入数据库前页面加上meta charsetutf-8一般不会出现乱码。时区配置方面在settings.py里把USE_TZ False、TIME_ZONE Asia/Shanghai设置好。默认的UTC时间在Windows下配合SQLite偶尔会出现时间偏移8小时的怪问题直接关掉时区转换最省事。还有个细节训练好的pkl模型不要在项目运行期间频繁覆盖。我在本地重训练模型后Django的dev server因为热加载会重新读取文件有时候读到一半的文件会报EOFError出现这种问题首先想到重启dev server确认模型文件完整。6.3 答辩演示的黄金三分钟演示流程要提前演练到肌肉记忆。我建议这样安排先打开大屏页面展示整体效果挑一个真实节假日比如国庆输入系统看到预测流量明显高于平时这时候顺势解释模型捕捉到了节假日的强特征然后再切换到一个普通工作日预测值回落到平时水平。两组对比演示比任何口头解释都直观。导师大概率会问三个问题为什么选线性回归、特征怎么来的、预测误差多大。对应答案我已经在前面讲过了线性回归可解释性强特征来自时间周期性和业务经验误差看MAE和R²误差大的样本主要集中在大型活动日等异常情况。答得出来这个项目的完成度基本上就立住了。最后说点实际体会如果你照着这套链路把项目跑通收获最大的不是我会用Django或者我调过sklearn而是你亲手建立了一条完整的数据流水线从拿到原始数据开始经过清洗、特征构造、模型训练、系统集成最后到可视化呈现和答辩讲解每一步你都清楚自己在做什么、为什么这么做。我做这套系统的最大感受是数据质量永远比模型调参更值得投入时间把特征工程做扎实线性回归也能给出让人满意的预测结果。后续如果你想继续扩展可以考虑引入更细粒度的天气数据做非线性模型对比或者把客流预测按小时维度拆解再到接入更丰富的数据源做区域热度分析——方向很多但核心技术骨架就是这篇文章里的这套链路。