基于Python与Django的景区人流量预测系统设计与实现-开发者社区

这两年计算机毕设选题里，旅游和景点相关的题目热度一直很高，但很多同学做着做着就变成“展示景点信息的管理系统”，核心的人流量预测反而成了摆设。Python景点人流量智能预测系统这类题目，真正的主线是把Django后端、机器学习算法、数据可视化打通，做成一套从数据到预测再到展示的完整闭环。这篇就把这套系统的设计思路、核心代码、踩坑点一次性讲透，帮你从框架搭建到答辩都能拿得出手。

1. 项目到底做什么：选题定位与实用价值拆解

1.1 这类系统的核心需求到底是什么

景区人流量预测，本质上是时间序列预测问题。系统通过历史的人流量数据，结合日期特征（节假日、星期几、月份）、天气特征（温度、降雨、风力）、甚至是淡旺季因子，训练出一个模型来计算未来某天或某个时段景区会有多少游客。

这个需求在现实里是真实存在的。景区运营方需要提前预判人流高峰来安排安保力量、调配接驳车辆、做限流预警；文旅管理部门需要根据流量数据做区域调度。所以这类题目天然有业务逻辑支撑，不是凭空捏造的“作业系统”，答辩时评委问“你这个东西有什么用”，你完全可以给出落地场景。

从毕设角度看，这类题目的优势在于：技术栈覆盖面广但深度可控。Django是web后端必备技能，线性回归属于机器学习入门算法，可视化用ECharts等图表库实现，一个项目把大学四年主要课程都串联起来了。比起纯管理系统“只有增删改查没含金量”的尴尬处境，这种带算法模块的项目会好答辩很多。

1.2 为什么选线性回归而不是神经网络

很多人在选题时纠结：要不要上深度学习？用LSTM预测时间序列是不是更“高级”？我的建议是：毕设阶段优先考虑线性回归。首先是可解释性问题，线性回归的每个特征都有对应系数，评委问“为什么工作日流量就低”，你能直接说出“因为工作日特征项的权重是负的”；换成神经网络，黑盒模型很难讲清楚决策依据。其次是数据量问题，深度学习需要海量数据训练，大多数毕设拿到的景区数据就几百上千条，这个量级喂给神经网络大概率过拟合。

线性回归处理这类问题还有计算开销低的优势。训练时间秒级完成，一台普通笔记本就能跑，不用折腾GPU环境。而且在实际开发中，先用线性回归做基线模型（baseline）是业界标准做法——如果最简单的模型效果都不差，说明特征工程做得到位，这是个不小的加分点。后面如果真的想升（级），可以把回归替换成Prophet、LightGBM甚至LSTM，系统架构不用大改，这就是“算法替换”的设计思想。

1.3 适合谁学习和参考

如果你是计算机、软件工程、数据科学相关专业的学生，正处于毕设选题阶段，或者想知道这类系统怎么实现，这篇内容都可以给你一个相对完整的参考。文章会从技术架构、数据集构造、模型实现、可视化展示几个环节依次展开，每一部分都会给出可直接跑的方案。

我个人建议，在读这篇文章的时候，不要只看代码，更要琢磨每一个设计决策背后的原因。比如为什么数据集要自己构造而不是去爬真实数据？为什么模型要用均方误差做损失函数？这些想明白了，你答辩时的底气会完全不一样。

2. 系统架构设计：Django框架下的模块划分与数据流

2.1 整体功能与目录结构

这套系统的功能可以拆成四个大模块：用户管理、数据管理、预测算法、可视化展示。用户管理走Django自带的认证体系，扩展一个角色字段区分管理员和普通游客；数据管理负责接收并存储历史入流量数据，支持手动录入也可以批量导入CSV；预测算法的核心是特征工程加线性回归模型，通过接口接收请求返回预测结果；可视化页面用ECharts渲染各类图表。

项目的目录结构和命名建议这样设计：

scenic_flow/ ├── manage.py ├── requirements.txt ├── config/ # 项目配置 │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── apps/ │ ├── user/ # 用户模块 │ ├── data_manage/ # 流量数据管理 │ ├── prediction/ # 预测算法模块 │ └── dashboard/ # 可视化展示模块 ├── static/ │ ├── css/ │ ├── js/ │ └── echarts/ └── templates/ ├── base.html ├── login.html ├── dashboard.html └── data_manage.html

用apps目录把业务拆分成独立应用，是为了保证模块间低耦合。数据管理模块只管读写数据库，预测模块只负责训练和推理，两个之间通过数据模型传递信息。后期如果想换算法，只需要修改prediction应用内部代码，其他模块完全不用动。

2.2 数据模型的字段设计

流量数据表是整套系统的根基，字段设计直接决定特征工程能不能顺利开展。我建议至少包含以下几项：

日期（DateField），记录流量对应的日期
时段（CharField），一天分四个统计时段：上午、中午、下午、晚间
人流量（IntegerField），该时段的游客数量
天气状况（CharField），晴/多云/小雨/大雨等枚举值
温度（FloatField），当天平均气温
是否节假日（BooleanField），标记当天是否是法定节假日

有的同学会问，天气数据怎么来的？真实项目可以从天气API拉取历史数据，毕设阶段可以用模拟数据替代。但字段类型一定要设计到位，这就好比数据库的schema一旦定了，后面再改就很麻烦。

用户表直接用Django内置的AbstractUser扩展一个role字段就行，没有太多特殊设计。管理员可以录入和修改流量数据，普通用户只能查看。

2.3 前后端数据交互的接口约定

前后端分离已经是主流做法，即使Django自带模板渲染，也不建议把数据和HTML硬耦合在一起。我的做法是：Django端提供JSON接口，前端用Ajax拉取数据，渲染交给ECharts。

这里给出一个典型的JSON响应结构：

{ "code": 0, "msg": "success", "data": { "date": "2024-04-15", "predicted_flow": 15820, "actual_flow": null, "confidence_interval": [14300, 17340] } }

统一code/msg/data三层的响应格式，是为了让前端异常处理逻辑清晰。查询成功返回code=0，参数错误返回code=400，模型未训练完成返回code=500。前端拿到非0的code直接弹出错误提示，不用关心具体业务逻辑。

接口设计遵循RESTful风格，主要接口如下：

GET /api/flow/history?days=30，获取最近30天的景区人流量历史数据
POST /api/flow/create，新增一条景区人流量记录
GET /api/predict/next_day，预测明天分时段人流量
POST /api/predict/date，预测指定日期的人流量
GET /api/statistics/overview，获取可视化大屏所需的统计数据

2.4 Django ORM查询的优化细节

写这类系统的后端接口时，最容易被忽略的就是ORM查询性能。流量数据表一旦积累到几千条，遍历查询就会变慢。推荐做法是：视图函数里只查当前视图需要的数据，不要一次性把所有字段都加载进来，用only()或values()限定字段；需要对日期做分组统计时，直接用Django的TruncDate配合annotate完成数据库层面的聚合，而不是把数据全捞到Python内存再处理。

from django.db.models.functions import TruncDate from django.db.models import Sum daily_flow = ( FlowRecord.objects .filter(date__gte=start_date) .annotate(day=TruncDate("date")) .values("day") .annotate(total=Sum("visitor_count")) .order_by("day") )

这段代码查询出按天分组的总人流量，整个过程发生在数据库端，性能比逐条加载高效得多。

3. 机器学习核心：线性回归模型的原理、实现与优化

3.1 线性回归模型的数学原理

线性回归的基本假设是：目标变量和特征变量之间存在线性关系。放在景点人流量这个场景里，要预测的就是当天的总流量，特征变量可能有星期几、是否节假日、平均温度、上月同期流量等。模型表达式就是：

y = w1*x1 + w2*x2 + ... + wn*xn + b

其中w1到wn就是每个特征的权重，b是偏置项。训练的过程就是找到一组权重，让预测值和真实值之间的误差最小。这里用到的损失函数叫均方误差（MSE）：

MSE = (1/n) * Σ(y_true - y_pred)^2

为什么用MSE而不是绝对误差？因为MSE在误差大时产生的梯度也大，反向传播时能更快速地修正权重的方向，收敛更快。另一方面，MSE在误差为0处是可导的，方便使用梯度下降法求解。

3.2 特征工程是模型效果的分水岭

线性回归模型本身很简单，它的上限完全取决于特征做得好不好。同样一份数据，有人把日期直接丢进去训练，出来的模型$R^2$可能只有0.2；有人做了完整的特征工程，$R^2$可以到0.8以上。这就是经验差距所在。

我的特征工程方案是这样做的，从原始数据中衍生出这些特征：

星期几（0到6）。景区人流量有很强的周周期性，周一少、周末多
是否周末（0或1）。在星期几的基础上再强化一下
是否节假日（0或1）。法定节假日是流量暴增的主要因子
月份（1到12）。旅游淡旺季的区分
温度。对自然风景区影响很大
天气评分。把晴、多云、阴、小雨、大雨映射为5、4、3、2、1分
前一日的流量。时序数据里昨天的流量和今天通常高度相关

这些特征组合在一起，组成了模型进入训练前最终的特征矩阵。要注意的是，类别特征不能直接当作数字喂给线性回归，比如天气的“晴”“多云”是类别，不能映射时用5、4、3这种有序整数吗？

可以映射，但这种做法隐含了一个假设：晴到多云的“距离”和多云到阴的“距离”是相等的。这个假设不完全成立时，就需要用独热编码（One-Hot Encoding）。但在毕设级别的项目里，天气映射成有序整数通常效果不差，而且保持特征维度小。

3.3 训练集与验证集划分的注意事项

毕设里最常见的错误就是直接用全部数据训练模型，然后用同一份数据算精度。这在学术上叫数据泄漏，结果虚高，答辩时评委问你泛化能力的时候会露馅。

正确的做法是拿最近20%的数据做验证集，前80%做训练集。原因很简单：时间序列数据的训练集必须是验证集之前的数据，不能随机打乱——预测未来，你用未来的数据训练，这个逻辑本身就说不通。

下面是模型训练核心代码，建议搭一个独立的model_service.py文件，不要让训练逻辑散落在视图函数里：

import pandas as pd from sklearn.model_selection import train_test_split from sklearn.linear_model import LinearRegression from sklearn.preprocessing import StandardScaler from sklearn.metrics import mean_squared_error, r2_score import joblib def train_flow_model(df): # df包含原始流量记录：date, visitor_count, is_holiday, weather_score, temperature等字段 # 构造特征 df["date"] = pd.to_datetime(df["date"]) df["weekday"] = df["date"].dt.weekday df["is_weekend"] = df["weekday"].apply(lambda x: 1 if x >= 5 else 0) df["month"] = df["date"].dt.month df["prev_day_flow"] = df["visitor_count"].shift(1) # 去掉缺失行 df = df.dropna() features = ["weekday", "is_weekend", "is_holiday", "weather_score", "temperature", "month", "prev_day_flow"] X = df[features] y = df["visitor_count"] train_size = int(len(df) * 0.8) X_train, X_test = X.iloc[:train_size], X.iloc[train_size:] y_train, y_test = y.iloc[:train_size], y.iloc[train_size:] model = LinearRegression() model.fit(X_train, y_train) y_pred = model.predict(X_test) mse = mean_squared_error(y_test, y_pred) r2 = r2_score(y_test, y_pred) # 保存权重文件和模型，方便后续加载 joblib.dump(model, "flow_model.pkl") return model, mse, r2

有同学会问，train_test_split不是自带shuffle参数吗，我是不是直接shuffle=False就行？也可以，但直接按位置切片更直观，一眼就能看出前80%是训练集、后20%是测试集，答辩的时候讲起来也清晰。

3.4 从Sklearn切换到Statsmodels做统计分析

如果你的答辩老师比较较真，会追问“你的模型系数有什么统计学意义”，这时候只跑Sklearn就不够看了。建议你额外用statsmodels库跑一遍同样的线性回归，它会输出每个特征的p值和置信区间。特征p值如果大于0.05，说明这个特征对目标变量的影响不显著，你就可以解释说“我基于统计显著性筛选了核心特征”。

这个方法在毕设里是很有辨识度的亮点，大部分学生只会调包，你如果会说“我通过p值剔除了不显著特征”，在答辩时给人感觉专业很多。

import statsmodels.api as sm X_const = sm.add_constant(X_train) # 添加截距项 sm_model = sm.OLS(y_train, X_const).fit() print(sm_model.summary())

3.5 数据集构造：从模拟数据到真实数据

真实景区的流量数据并不容易获取，有很多景区根本不会对外公开历史客流数据。与其去爬那些不完整的公开数据，不如自己构造一套基于真实分布规律的模拟数据——这样做的另一个好处是，你可以完全控制趋势变化，验证模型是否学到了你设计的模式。

构造模拟数据的逻辑也很简单：先设计一个基础函数，包含年度季节性（5月到10月旺季高，12月到2月淡季低）、周周期性（周末高工作日低）、节假日暴涨（五一、国庆翻2到3倍），再叠加受天气影响的随机浮动。最后加一点随机噪声模拟真实波动。

import pandas as pd import numpy as np from datetime import datetime, timedelta def generate_synthetic_data(start_date, end_date): date_list = [] flow_list = [] np.random.seed(42) for d in pd.date_range(start_date, end_date): month = d.month # 基础流量：7-8月暑假旺季，11-12月淡季 season_factor = 1.2 if month in [7, 8] else 0.7 if month in [11, 12] else 1.0 # 周末效应：周五到周日流量高于工作日 weekday_factor = 1.3 if d.weekday() >= 4 else 0.85 # 节假日效应 holiday_factor = 1.8 if d in pd.to_datetime(["2024-10-01", "2024-10-02", "2024-10-03"]) else 1.0 base_flow = 8000 * season_factor * weekday_factor * holiday_factor # 加入天气扰动和随机噪声 weather_effect = np.random.uniform(0.85, 1.1) noise = np.random.normal(0, 500, 1)[0] flow = max(500, int(base_flow * weather_effect + noise)) date_list.append(d) flow_list.append(flow) df = pd.DataFrame({"date": date_list, "visitor_count": flow_list}) return df

这种构造方法背后的逻辑是：你在给模型“出题”的时候就已经埋好了答案，如果特征因子都设置到位，模型理应在验证集上表现不错；如果你的特征工程缺失了某个关键因子（比如忘了节假日），那你就能直观地看到预测误差集中出现在节假日附近——排查问题的线索一下就清楚了。

4. 可视化大屏的实现：从数据到图表的最佳实践

4.1 可视化模块的设计原则

景区人流量预测系统的可视化部分，核心目标是让观者一眼看懂三个问题：历史流量走势如何，模型预测值是多少，历史预测和真实流量的偏差多大。切忌一股脑儿堆图表，每张图表都要有明确的信息承载任务。

我建议的可视化大屏布局是：顶部区域放总览卡片，显示今日实时流量、明日预测流量、本周日均流量和本月累计流量；中间主体区域放本周流量趋势折线图，同时叠加预测值和真实值的双线对比；右侧放时段分布热力图，展示一天四个时段（上午、中午、下午、晚间）的流量分布；底部放节假日效应柱状图，对比2024年各节假日的流量差异。

4.2 Django视图传递JSON数据给ECharts

先说后端怎么组织数据。预测模块训练出的模型文件flow_model.pkl，在Django启动时懒加载——第一次调用预测接口时加载模型，后续直接复用。视图函数大体长这样：

import json import joblib from django.http import JsonResponse from django.views.decorators.http import require_GET from .model_service import prepare_features, build_next_day_features _model = None def get_model(): global _model if _model is None: _model = joblib.load("prediction/flow_model.pkl") return _model @require_GET def predict_next_day(request): model = get_model() # 构造明天的特征：今天日期加1天 tomorrow = datetime.now() + timedelta(days=1) features = build_next_day_features(tomorrow) pred_value = model.predict([features])[0] pred_value = int(round(pred_value)) return JsonResponse({ "code": 0, "data": { "date": tomorrow.strftime("%Y-%m-%d"), "predicted_flow": pred_value } })

前端用JavaScript获取接口数据并渲染。下面是ECharts折线图的关键部分：

$.getJSON("/api/predict/next_day", function (res) { if (res.code === 0) { // 更新预测卡片 $("#predictedFlow").text(res.data.predicted_flow.toLocaleString()); // 刷新趋势图 trendChart.setOption({ series: [{ data: res.data.trend_data }] }); } else { toast.error("获取预测数据失败：" + res.msg); } });

需要注意的是，ECharts的setOption默认是值替换模式，直接重新赋值时旧数据会丢掉。如果希望保持动画过渡效果，要在设置之前加上trendChart.clear()，或者使用merge: true参数。这个细节看起来小，但实际图表显示异常时，很多同学会一头雾水。

4.3 核心图表的配置要点

折线图适合趋势展示，但要注意两个细节。第一，数据点标签不要全显示，否则数据一多图上密密麻麻全是数字，非常劝退。我用label: { show: false }隐藏标签，只在鼠标悬浮时通过tooltip展示具体数值。第二，x轴数据如果太密集，一定要加dataZoom组件，支持拖拽缩放，这是大数据可视化最基本的交互能力。

热力图用ECharts的heatmap系列实现。x轴放日期，y轴放时段（上午、中午、下午、晚间），色块颜色从浅蓝到深红渐变，直观看出哪几天哪个时段是客流高峰。这里有个小坑：ECharts热力图的数据格式是[x, y, value]三元组，x和y需要是索引数字而不是字符串，所以后台要把日期和时段先map成索引，或者在前端做一次转换，否则图表会空白。

4.4 大屏适配与小屏兼容的处理

毕业设计演示时，很多同学是在自己的笔记本上进行的，屏幕小、分辨率不确定。如果可视化页面按固定像素写死，换一台电脑就会错位。我的做法是：页面容器使用百分比布局，ECharts实例初始化时读取容器宽度，同时监听window的resize事件。

window.addEventListener("resize", function () { trendChart.resize(); heatmapChart.resize(); });

如果时间允许，建议用rem单位做字体适配，让整体大屏在不同尺寸的屏幕上保持视觉比例。实测下来，1680和1920宽度的显示器上效果都还可以。

5. 完整实操过程：从环境搭建到跑通第一版预测

5.1 环境准备与依赖安装

先把运行环境交代清楚。Python版本建议用3.9或3.10，新版3.12偶尔有依赖包还没适配的情况，没必要冒险。用virtualenv或者conda建一个独立环境，再安装依赖：

pip install django==4.2 pip install pandas numpy scikit-learn matplotlib pip install statsmodels joblib pip install requests

关于版本，Django 4.2是目前比较稳妥的长线支持版本，和Python 3.10搭配没有兼容问题。数据库直接用Django默认的SQLite就行，几千条记录完全够用，不要过度设计去上MySQL，给自己增加部署负担。

5.2 创建项目和应用目录

django-admin startproject scenic_flow cd scenic_flow python manage.py startapp user python manage.py startapp data_manage python manage.py startapp prediction python manage.py startapp dashboard

创建完成后，在settings.py里的INSTALLED_APPS注册四个应用，顺带配一下模板路径和静态文件路径。到这里基本的项目框架就搭起来了。

5.3 定义数据模型并迁移数据库

数据模型的完整代码建议这样的字段设计：

from django.db import models class FlowRecord(models.Model): date = models.DateField(verbose_name="日期") period = models.CharField(max_length=10, choices=[ ("morning", "上午"), ("noon", "中午"), ("afternoon", "下午"), ("evening", "晚间") ], verbose_name="时段") visitor_count = models.IntegerField(verbose_name="人流量") weather = models.CharField(max_length=10, verbose_name="天气") temperature = models.FloatField(verbose_name="温度") is_holiday = models.BooleanField(default=False, verbose_name="是否节假日") class Meta: db_table = "flow_record" ordering = ["date", "period"]

定义好之后运行：

python manage.py makemigrations python manage.py migrate

5.4 编写数据导入脚本

系统上线后，管理员可以在页面上手动录入数据，但开发测试阶段一条条录效率太低。写一个management command批量导入CSV：

from django.core.management.base import BaseCommand from data_manage.models import FlowRecord import csv class Command(BaseCommand): help = "批量导入人流量CSV数据" def add_arguments(self, parser): parser.add_argument("csv_file", type=str) def handle(self, *args, **kwargs): with open(kwargs["csv_file"], "r", encoding="utf-8") as f: reader = csv.DictReader(f) count = 0 for row in reader: FlowRecord.objects.create( date=row["date"], period=row["period"], visitor_count=int(row["visitor_count"]), weather=row["weather"], temperature=float(row["temperature"]), is_holiday=row["is_holiday"] == "1" ) count += 1 self.stdout.write(self.style.SUCCESS(f"导入成功：{count} 条"))

执行方式：python manage.py import_flow_data path/to/flow_data.csv。

5.5 模拟数据生成与模型训练接口

为了让系统在演示时有数据可跑，我写了一个generate_demo_data的管理命令，内部调用之前那个generate_synthetic_data函数生成365天的流量数据并写入数据库。然后用Django的ping命令触发训练，或者直接在管理后台加一个“训练模型”按钮，点击后调用train_flow_model并展示MSE和$R^2$指标。

一个值得注意的点是，这些管理命令本身就是很好的演示素材。答辩时可以现场跑一遍命令，看到生成数据和训练输出的整个日志过程，比单纯对着已经生成好的界面讲更有说服力。

6. 常见问题与避坑指南

6.1 时间序列数据泄漏问题

在写码过程中，我最常看到的问题是同学直接用train_test_split(X, y, test_size=0.2)而不加shuffle=False。Sklearn里的train_test_split默认会打乱数据，用在时间序列上就是灾难——训练集里有未来数据，验证集里有过去数据，模型是在“作弊”。

判断方法很简单：训练完成后打印验证集预测值和真实值的对比表，如果误差极小（比如几十以内），而训练集误差也差不多，你就要警觉是不是数据泄漏了。一旦确认，立即改成按时间切分的方式。

6.2 特征尺度不一致影响模型效果

温度动辄30多度，星期几只有0到6，这些特征量纲差异巨大。线性回归内部计算时，量纲大的特征会对损失函数产生不成比例的影响，梯度下降会比较震荡。必须做标准化处理。

scaler = StandardScaler() X_train_scaled = scaler.fit_transform(X_train) X_test_scaled = scaler.transform(X_test)

注意fit的标准scaler是只在训练集上拟合的，测试集只调用transform，不能重新fit。否则测试集的均值方差参与计算，又是一种信息泄漏。

在模型保存时，要连scaler一起保存。这样才能保证web接口在接收到新数据特征时，用同一套标准化参数处理。

6.3 Django更新数据后模型没重新训练的bug

系统在开发测试阶段，你会频繁改模拟数据或者补充真实数据。如果模型只在第一次启动时训练一次，之后新增的数据永远不会被学习到，预测结果始终是旧模型给出的。

解决方案是在数据管理后台的“新增记录”操作里，加一个异步训练触发器。数据量小的时候直接同步调train_flow_model就行，不过要注意给线程加锁，否则多个请求同时触发训练会写出脏数据。数据量大时可以用Django-Celery做异步任务队列。

6.4 节假日特征提取的边界坑

判断某天是不是节假日，绝对不能只靠周末判断。五一、国庆、春节这种长假期间，工作日的流量可能比普通周末还高。我建议在模拟数据生成时显式指定节假日列表，而不是靠爬虫或者硬编码。

如果你希望更通用，可以使用chinese_calendar这个库，它内置了每年的法定节假日安排（包括调休上班日），一行代码就能判断：

import chinese_calendar def is_legal_holiday(dt): if chinese_calendar.is_holiday(dt): return True if chinese_calendar.is_workday(dt): return False return False # 非工作日但也非法定假日，一般是普通周末

6.5 模型泛化能力不足的补救

如果验证集$R^2$只有0.3左右，先不要急着换模型，按顺序排查这三件事：特征是否完整覆盖了已知的流量影响因素（节假日有没有进来？天气有没有进来？）；数据是否有明显的异常值（比如某天因为景区关闭流量为0，这种记录要剔除）；训练集和验证集划分是否合理（前80%和后20%的数据分布是否差异过大，比如验证集刚好覆盖了黄金周）。

如果排查完还是不行，这时候才考虑升级算法。建议按这个顺序尝试：先加多项式特征（PolynomialFeatures），再试随机森林回归，最后才上Prophet或LSTM。毕设不需要一步到位，能证明你具备完整的优化思路就够了。

7. 扩展升级：从毕业设计到可落地的智能预测系统

7.1 从线性回归到Prophet和LightGBM

如果你的题目带有“大数据”或“大模型”关键词，或者你希望在项目中展示更多算法对比，建议在现有线性回归基础上增加一个对比实验模块。我实测过的方案是Facebook Prophet，它对节假日建模非常友好，自带节假日和季节性组件，在处理时间序列预测方面几乎是为这个场景量身定制的。

Prophet的使用方式不多展开，核心思路是：把数据构造成ds（日期）和y（流量）两列，然后调用Prophet().fit(df)，一行代码完成训练。如果你在论文里准备写“本文对比了线性回归和Prophet模型的预测效果”，那现有的架构几乎不需要改动，只要在prediction应用里加一个新的service文件就可以。

LightGBM这类树模型也可以考虑，它处理非线性交互特征能力更强，但对时间序列的外推预测不一定比线性模型好，需要实际对比。

7.2 引入多维数据源的接入设计

真实景区人流预测还会考虑更多数据：景区门票预约量、酒店入住率、周边交通拥堵指数、历史同期数据、网络搜索热度。如果后续要做改进，可以考虑在模型的特征矩阵里增加这些变量，然后把数据源接入模块单独抽象出来，统一走接口拉取。

这样做的好处是，你的系统从“单一历史数据预测”变成了“多源数据融合预测”，在技术难度和业务价值两个维度上同时提升。毕设里可以做一个模拟数据源管理页面，用表单配置外部数据源的地址和更新频率。

7.3 从人流量预测到区域承载预警

另一个值得扩展的方向是预测结果的分级预警。将预测值映射到景区承载率区间——绿色（承载率低于60%）、黄色（60%到85%）、红色（超过85%）。当预测流量超过阈值时，系统自动向管理员推送预警消息，页面上也会高亮显示。

实现本身并不复杂，在预测接口返回的数据里加一个alert_level字段就行。关键是这个功能把预测结果和景区安全管理实际业务串联起来，答辩时讲“我不仅预测了流量，还对接了管理决策”，是一个很加分的叙事。

8. 实操体验：这套系统的运行效果与个人心得

全部模块写完后，跑起来的效果大概是这样的：登录系统进入可视化大屏，顶部显示出本周的预测流量数字，折线图上真实流量和预测流量两条曲线基本贴合，在节假日附近有明显抖动。切换不同日期范围，趋势图和数据卡片会同步刷新。

我印象比较深的是节假日预测的偏差调整环节。最初版本的模型没有把“五一前两天”这种节前效应考虑进去，结果4月30日这种日期预测值明显偏低。后来在特征里加了“距最近节假日天数”这个变量，误差立刻降了一截。这类细节才是真正体现算法调优能力的地方，也是答辩时可以细讲的故事。

还有个体会是管理命令在调试中的价值。我习惯把所有耗时操作都写成management command，比如导入数据、训练模型、生成演示数据，这样不仅能自动化测试，而且每当需求变化时，只需要在原有命令上增加参数，不用到处修改页面入口。这套工作习惯同样适用于以后的企业开发。

最后提个建议：代码里所有注释都写清楚为什么这么做，而不是“这一段实现什么功能”。深层次的注释对后续代码维护的帮助会大很多。答辩时你可以理直气壮地说：“我不只写出来了，我还知道自己每一步为什么这么写。”这才是计算机毕业设计最应该达到的高度。