基于Python的城市交通流量数据可视化分析系统设计与实现

简介面向具备Python编程基础的数据分析、后端或GUI开发人员及交通相关专业学生这套城市交通流量数据可视化分析系统项目实例完整覆盖了从多源数据采集、清洗、存储、多维统计到交互式可视化与预测建模的全流程。项目采用分层架构整合pandas、NumPy、Matplotlib、Plotly、FastAPI等工具并围绕数据质量、性能瓶颈和系统扩展性给出具体对策可服务于交通管理决策、道路规划优化、智能出行及高校教学等场景也可作为课程设计与毕业设计的参考范本。项目实例以单个docx文档提供大小116KB内含详细代码、MySQL数据库设计、系统架构图和完整目录结构从项目背景、技术选型、架构设计到部署运维均有讲解。文档重点展开基础设施层、数据预处理层、统计建模层与可视化交互层的核心代码示例并配合缺失值清洗、时间粒度重采样、路段高峰识别、Plotly交互图表及预测模型对比等可复现环节便于读者按章节依次实践与二次扩展。目前已有115人学习下载适合希望系统掌握Python在数据科学和Web系统中综合应用的读者。1. 城市交通流量数据可视化分析系统先搞清楚它解决什么问题早高峰的十字路口信号灯配时明明执行了方案拥堵指数还是拉满夜间潮汐流量、节假日景区周边值班员翻几十页报表也看不出规律。“基于Python的城市交通流量数据可视化分析系统”要做的事就一件把卡口、地磁、微波检测器产生的通行数据取出来用图表呈现流量、速度和拥堵程度让值班员扫一眼就知道哪条路在打结。它包含完整的程序、数据库和GUI设计常见做法是Python做数据处理、MySQL做存储、PyQt5做桌面界面内网部署比Web方案更省心。适合要交课程设计和毕业设计的学生也适合想快速搭一套内网可视化工具的交通数据岗位从业者。2. 系统架构与数据模型流量数据从哪来、怎么存才不翻车2.1 三层架构选型为什么是PythonMySQLPyQt5而不是纯Web方案很多第一次做数据可视化的人会直接选FlaskECharts像农产品价格可视化、校园大数据可视化那样在浏览器里出图。这个路线确实前端效果好但放到城市交通流量这个场景里有三件事会逼你回头第一交通数据系统大多跑在公安内网或专网里浏览器要访问的图表服务、WebSocket推送都要过安全审计桌面GUI反而容易被接受。第二值班员的操作是“查询一个路口→看趋势→切换时间粒度→对比排名”这类强交互用PyQt5的信号槽机制写起来非常直接不需要维护一个HTTP接口的数据结构。第三城市交通流量数据本身是分钟级甚至秒级的事实数据查询大多按检测器ID时间范围走把聚合逻辑放SQL里、把画图逻辑放GUI里分层清楚比在Web前端做几十个接口清爽得多。我一般会把系统拆成三层存储层MySQL 8.0、数据访问层PyMySQL DBUtils连接池、表现层PyQt5 QtCharts。中间再加一个模拟数据生成器用于在没有真数据时先把界面调通。这套结构对“基于Python的城市交通流量数据可视化分析系统设计”这样的项目来说是最稳的起点数据量在百万级时不需要引入Hadoop或时序数据库单机MySQL完全能扛住。2.2 城市交通流量数据表设计事实表、维度表和指标字段交通流量的核心数据不是一张大宽表而是“维度表事实表”。这样设计的好处是检测器坏了只需要改一条维度记录历史流量事实不需要动。我常用的建库建表脚本长这样CREATE DATABASE IF NOT EXISTS traffic_system DEFAULT CHARACTER SET utf8mb4; USE traffic_system; -- 路口维度表 CREATE TABLE intersection ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL COMMENT 路口名称, district VARCHAR(20) COMMENT 行政区, longitude DECIMAL(10,6), latitude DECIMAL(10,6) ) ENGINEInnoDB; -- 检测器表一个路口可能有多个方向、多个车道检测器 CREATE TABLE detector ( id INT PRIMARY KEY AUTO_INCREMENT, intersection_id INT NOT NULL, lane_no INT COMMENT 车道编号, direction VARCHAR(10) COMMENT 北/南/东/西, detector_type VARCHAR(20) COMMENT 地磁/微波/视频, KEY idx_intersection (intersection_id), CONSTRAINT fk_detector_intersection FOREIGN KEY (intersection_id) REFERENCES intersection(id) ) ENGINEInnoDB; -- 交通流事实表分钟级聚合数据 CREATE TABLE traffic_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, detector_id INT NOT NULL, stat_time DATETIME NOT NULL COMMENT 统计时间(分钟级), flow INT NOT NULL COMMENT 通过车辆数, speed DECIMAL(5,1) NOT NULL COMMENT 平均速度km/h, occupancy DECIMAL(4,2) COMMENT 时间占有率%, saturated_degree DECIMAL(4,2) COMMENT 饱和度0-1, KEY idx_detector_time (detector_id, stat_time), CONSTRAINT fk_flow_detector FOREIGN KEY (detector_id) REFERENCES detector(id) ) ENGINEInnoDB;为什么把流量事实表按分钟存而不是按秒存秒级数据量会被放大60倍而交通信号配时和拥堵研判的粒度用分钟级足够。字段方面flow看“排队长度”speed看“路段畅通度”occupancy看“车道占用”saturated_degree是饱和度大于0.8就要注意拥堵风险。这三个指标是交通工程里的基本功设计可视化时它们是要被分开展示的千万不要把速度当唯一指标。需要特别注意的是联合索引(detector_id, stat_time)。这个系统90%的查询都长这样“查某个检测器在某个时间段内的流量”SQL过滤条件只要命中这两个字段走联合索引就能把百万行范围缩到几千行。如果你把detector_id和stat_time各建一个单列索引MySQL只能选择其中一个另一个字段做全表过滤数据量一大界面就会卡。2.3 数据生成与入库脚本跑通最小数据流没有真实卡口数据时项目没法推进。常见做法是先写一个模拟数据生成器按交通流规律生产有说服力的数据。早高峰和晚高峰流量要明显抬升夜间要降下去周末要低于工作日还要带一点随机波动否则图表看起来像鬼画符。# generator.py import random from datetime import datetime, timedelta import pymysql def add_peak_factor(hour: int, weekday: int) - float: 返回该小时相对平均流量的倍率 if weekday 5: base 0.7 # 周末整体降三成 else: base 1.0 # 早高峰7-9点、晚高峰17-19点倍率拉高 if 7 hour 9: return base * 1.8 if 17 hour 19: return base * 1.6 if hour 22 or hour 5: return base * 0.3 # 夜间低流量 return base * 1.0 def generate_flow(detector_id: int, start: datetime, days: int): conn pymysql.connect( host127.0.0.1, port3306, userroot, password123456, databasetraffic_system, charsetutf8mb4, ) cursor conn.cursor() base_time start for _ in range(days * 1440): # 1440分钟/天 hour base_time.hour weekday base_time.weekday() peak add_peak_factor(hour, weekday) # 用正态分布制造波动流量不会是一条直线 flow int(60 * peak random.gauss(0, 15)) flow max(0, flow) # 流量大时速度下降流量小时速度恢复 speed round(random.gauss(35, 5), 1) if flow 40: speed round(random.gauss(25, 8), 1) speed max(10, min(80, speed)) occupancy round(flow / 200, 2) saturated_degree round(occupancy / 0.8, 2) cursor.execute( INSERT INTO traffic_flow (detector_id, stat_time, flow, speed, occupancy, saturated_degree) VALUES (%s, %s, %s, %s, %s, %s), (detector_id, base_time, flow, speed, occupancy, saturated_degree), ) base_time timedelta(minutes1) conn.commit() cursor.close() conn.close()这段脚本的核心是add_peak_factor函数它把“小时星期几”映射成流量倍率。注意我特意用了random.gauss而不是random.uniform因为正态分布才能让图表出现自然的波动uniform会生成一条充满锯齿但毫无特征的流量线。参数里days * 1440是循环次数days越小跑得越快调试时可以先用2天数据把GUI流程打通再生成整月数据。真实接入卡口数据时这个脚本可以当清洗器用只需要把INSERT部分换成“读上游文件→过滤无效检测器→批量写库”整个系统其他部分不用动。3. 用Python做交通流量可视化PyQt5面板与图表的联动实现3.1 GUI布局设计主窗口、工具栏和视图切换这部分是“数据库和GUI设计”里的重头戏。我见过很多项目把GUI做成“一个大窗口塞十个控件”结果是用户不知道该点哪里。交通流量可视化系统的常见布局是“左列表右图表”左侧用QListWidget放路口列表支持按行政区过滤顶部放QDateEdit日期选择器、QComboBox时间段选择器中间用QTabWidget切换“流量趋势”“拥堵排名”“路口对比”三张视图主窗口代码先把骨架搭起来# ui/main_window.py from PyQt5.QtWidgets import ( QMainWindow, QWidget, QHBoxLayout, QVBoxLayout, QListWidget, QTabWidget, QTableWidget, QComboBox, QDateEdit, QTableWidgetItem, ) from PyQt5.QtCore import Qt from PyQt5.QtChart import QChart, QChartView, QLineSeries class TrafficMainWindow(QMainWindow): def __init__(self): super().__init__() self.setWindowTitle(城市交通流量数据分析系统) self.resize(1280, 800) self._init_ui() def _init_ui(self): central QWidget(self) root QHBoxLayout(central) # 左侧路口列表 self.road_list QListWidget() self.road_list.currentRowChanged.connect(self.on_road_selected) root.addWidget(self.road_list, 1) # 右侧筛选栏 right QVBoxLayout() right.addWidget(QDateEdit()) self.time_combo QComboBox() self.time_combo.addItems([全天, 早高峰(7-9), 晚高峰(17-19), 夜间(22-5)]) right.addWidget(self.time_combo) # 图表区用Tab切换 self.tabs QTabWidget() self.trend_view QChartView() self.rank_table QTableWidget() self.tabs.addTab(self.trend_view, 流量趋势) self.tabs.addTab(self.rank_table, 拥堵排名) right.addWidget(self.tabs, 1) root.addLayout(right, 4) self.setCentralWidget(central)布局里最关键的是currentRowChanged.connect(self.on_road_selected)。这个信号槽让“用户点击左侧路名→右侧趋势图刷新”不需要写额外事件循环PyQt5的信号槽机制天然适合这类联动。右侧筛选器我用了QComboBox预设时间段比让用户手动输入起止小时更防呆——交通分析的表征时间就那么几段没必要给自由输入。3.2 流量趋势图、路口热力图和拥堵排名表怎么画QtCharts提供的QLineSeries和QBarSeries足够画90%的交通图表不需要引入matplotlib嵌入PyQt那套复杂封装。常见做法是SQL按小时聚合出平均速度画成折线按路口汇总流量画成柱状再把饱和度大于0.8的路口挑出来放排名表。def update_trend_chart(self, road_id, stat_date): # data_access.py 返回聚合后的数据 rows query_hourly_stats(road_id, stat_date) series QLineSeries() series.setName(平均车速) for row in rows: # row: {hour_label: 2025-06-01 08:00, avg_speed: 32.5} hour int(row[hour_label].split( )[1].split(:)[0]) series.append(hour, row[avg_speed]) chart QChart() chart.addSeries(series) chart.setTitle(f路口 {road_id} 小时平均速度变化) chart.setAnimationOptions(QChart.SeriesAnimations) axis_x QValueAxis() axis_x.setRange(0, 23) axis_x.setLabelFormat(%d时) chart.addAxis(axis_x, Qt.AlignBottom) series.attachAxis(axis_x) axis_y QValueAxis() axis_y.setRange(0, 80) axis_y.setTitleText(车速(km/h)) chart.addAxis(axis_y, Qt.AlignLeft) series.attachAxis(axis_y) self.trend_view.setChart(chart)这里有个经验交通流量分析里速度比流量更能反映拥堵。流量小也可能是堵死的车都停着不动速度一旦掉到20km/h以下基本可以判定为拥堵。所以趋势图主指标选平均车速流量用柱状图做副图。QValueAxis适合连续的时间轴能直接按0-23小时铺开如果按路口名画柱状图则改用QBarCategoryAxis否则路名会被自动截断。热力图我建议放在“路口对比”页里用QTableWidget按饱和度着色饱和度0.6-0.8 黄色0.8-1.0 红色。表格比散点热力图更适合值班员精确读取数字散点图在大屏场景才更有冲击力。表格配色用setBackground(QColor(...))效率高且代码简单。3.3 数据库连接池与查询性能别让界面卡在SQL上PyQt5 GUI最容易被吐槽的就是“点一下卡两秒”。这个项目里主要卡点在数据库连接上——每次按钮点击都新建一个pymysql.connect()握手和鉴权要花费几十毫秒加上查询和绘图界面自然转圈。解决方法是引入DBUtils连接池让长连接复用。# db.py from dbutils.pooled_db import PooledDB import pymysql.cursors POOL PooledDB( creatorpymysql, maxconnections20, # 最多同时20个连接 mincached2, # 空闲时保留2个连接 maxcached10, blockingTrue, # 连接不够时排队等待而不是抛异常 host127.0.0.1, port3306, userroot, password123456, databasetraffic_system, charsetutf8mb4, cursorclasspymysql.cursors.DictCursor, ) def get_conn(): return POOL.connection()这里三个参数值得细说。maxconnections20不是越大越好PyQt5界面通常只有1-3个并行查询20足够开太多反而占用MySQL的线程数。blockingTrue很重要查询高峰时多出来的请求会排队而不是直接抛Too many connections让界面弹错。DictCursor让cursor.fetchall()返回字典列表这样 SQL 里的字段名可以直接当字典 key 用代码可读性提高很多。查询 SQL 本身也要调优常见做法是让聚合尽量在 MySQL 完成不要拉全表到 Python 再groupbySELECT DATE_FORMAT(stat_time, %Y-%m-%d %H:00) AS hour_label, ROUND(AVG(speed), 1) AS avg_speed, SUM(flow) AS total_flow FROM traffic_flow tf JOIN detector d ON tf.detector_id d.id WHERE d.intersection_id %s AND DATE(tf.stat_time) %s GROUP BY hour_label ORDER BY hour_label;这段 SQL 的聚合条件走联合索引DATE(tf.stat_time)会在索引上做计算数据量大时可能失效。更稳的做法是用闭区间查询stat_time %s AND stat_time %s把日期计算留在 Python 参数里索引就能完整命中。我实际测过百万行表用前者慢 2-3 倍改闭区间后查询稳定在 100ms 内。4. 完整的系统工程落地数据库、GUI和代码怎么串成可运行的实例4.1 工程目录结构与主程序入口很多人拿到项目标题以为重点在某个单独的算法文件其实“设计与实现”的门道在工程组织。我把目录按职责拆成这样路径作用main.py程序入口初始化环境后启动GUIdb.py数据库连接池与公用查询方法generator.py模拟交通数据生成脚本sql/schema.sql建库建表语句可重复执行ui/main_window.py主窗口与信号槽逻辑ui/trend_widget.py趋势图组件ui/rank_widget.py拥堵排名表组件requirements.txt依赖清单这样拆分的好处是数据库变更不动GUI换数据源不动界面新来的人看main.py就能顺着入口摸到整个业务流程。入口文件写得很短# main.py import sys from PyQt5.QtWidgets import QApplication, QMessageBox from db import get_conn from ui.main_window import TrafficMainWindow def init_db(): 启动时检查数据库连接连不上直接给用户可见的报错 try: conn get_conn() conn.ping() conn.close() except Exception as exc: QMessageBox.critical(None, 数据库连接失败, str(exc)) sys.exit(1) if __name__ __main__: app QApplication(sys.argv) init_db() win TrafficMainWindow() win.show() sys.exit(app.exec_())init_db()是我强烈建议保留的一个函数。别嫌它多余——真实交付时目标机器上 MySQL 经常没启动或者建表语句没执行如果把异常留在后面弹窗用户会以为程序坏了。现在启动时先探活错误信息直接写明“数据库连接失败Cant connect”排障成本直线下降。4.2 GUI与数据库交互的核心代码点击列表、刷图表、防误操作系统最重要的交互链路是“选中路口→加载数据→刷新图表”。完整代码里这部分最容易写脏我把它拆成两个函数一个负责查询一个负责画图def on_road_selected(self, row: int): if row 0: return # 从路口列表项的文本里取出 id item_text self.road_list.item(row).text() road_id int(item_text.split(id)[1].rstrip())) # 查询数据真实项目里这里应放进 QThread见避坑章节 rows query_hourly_stats(road_id, self.date_edit.date().toString(yyyy-MM-dd)) if not rows: self.trend_view.setChart(QChart()) # 空白图避免残影 return self.update_trend_chart(road_id, self.date_edit.date().toString(yyyy-MM-dd))item_text.split(id)[1]这段稍微有点脆但它换取了列表显示和主键查询的解耦。你也可以把 road_id 直接用setItemData存进列表项取的时候用data(Qt.UserRole)推荐后者代码更优雅。不管哪种方式都要处理row 0的边界——用户还没选中任何项时Qt 会发一个currentRowChanged(-1)信号不挡掉就会下断言错误。查询函数我放在db.py里统一收口def query_hourly_stats(road_id: int, stat_date: str): conn POOL.connection() try: with conn.cursor() as cur: cur.execute( SELECT DATE_FORMAT(stat_time, %%Y-%%m-%%d %%H:00) AS hour_label, ROUND(AVG(speed), 1) AS avg_speed, SUM(flow) AS total_flow FROM traffic_flow tf JOIN detector d ON tf.detector_id d.id WHERE d.intersection_id %s AND tf.stat_time %s AND tf.stat_time %s GROUP BY hour_label ORDER BY hour_label , (road_id, f{stat_date} 00:00:00, f{stat_date} 23:59:59), ) return cur.fetchall() finally: conn.close()注意 SQL 里的%%是 PyMySQL 的转义写法因为datetime.strftime里的%会和 SQL 参数占位符冲突。如果你不用DATE_FORMAT直接传%s让 Python 格式化日期同样可行但查询结果里时间字段就是个datetime对象画图时还要再拆一遍不如在 SQL 里一次性格式化出来。4.3 打包发布与运行环境配置给目标机器做后悔药项目交付不是代码能跑就行得让目标机器上双击就能打开。常见做法是用 PyInstaller 打包命令如下pyinstaller --clean --windowed --name TrafficSystem \ --collect-data PyQt5 \ --add-data sql/schema.sql;sql \ main.py--windowed去掉控制台黑窗--collect-data PyQt5会把 Qt 的 qml、translations 等资源收进来不加这个参数常常会做出一个“本地能跑、换机器报 Could not find Qt platform plugin”的包。--add-data把建表脚本带进依赖目录第一次启动时让程序自动执行。依赖清单requirements.txt我一般写成pymysql1.0.2 DBUtils2.0 PyQt55.15 PyQt5-Charts5.15这里有一点要给准备照着做的人交底PyQt5 和 PyQt5-Charts 的版本要配套装的时候不要一个用 5.15 另一个用 5.9否则QtChart模块会静默导入失败界面起来但图表面板整个消失非常难排查。5. 避坑指南交通流量可视化项目最常见的5个翻车点5.1 中文乱码界面和图表里的汉字全变问号现象路口名称、图表标题、表格内容在 Windows 上显示为“???”在 Linux 上显示为乱码方块。原因两个层面都有坑。Python 源码文件没有声明 UTF-8或者 MySQL 连接参数漏了charsetutf8mb4PyQt5 默认字体在 Windows 下对中文支持不好用默认字体时中文字符会被替换成问号。解决三件事一次做完。第一所有.py文件开头写上# -*- coding: utf-8 -*-虽然 Python3 默认 UTF-8 源码但 PyQt5 某些版本解析中文字符串时仍可能受系统编码影响。第二MySQL 连接串必须显式加charsetutf8mb4少了这个参数中文写入数据库时会变?查出来再怎么设置字体都救不回来。第三在主窗口里统一设置中文字体from PyQt5.QtGui import QFont app.setFont(QFont(Microsoft YaHei, 10))5.2 界面卡死点击查询后窗口直接“转圈”现象点一个路口窗口立刻无响应需要等一两秒才恢复数据量大时甚至转 10 秒。原因把耗时操作写在了 GUI 主线程。SQL 查询和图表刷新都占着 PyQt5 的事件循环主线程被阻塞窗口自然无法响应鼠标键盘。解决把查询丢进QThread查询完成后用信号把结果发回主线程。一个通用写法class QueryThread(QThread): result_ready pyqtSignal(object) def __init__(self, road_id, date_text): super().__init__() self.road_id road_id self.date_text date_text def run(self): rows query_hourly_stats(self.road_id, self.date_text) self.result_ready.emit(rows)在窗口里创建线程并连接信号self.query_thread QueryThread(road_id, date_text) self.query_thread.result_ready.connect(self.on_query_finished) self.query_thread.start()pyqtSignal(object)可以在线程之间安全传递 Python 列表。注意不要在线程里直接操作self.trend_view.setChart(...)Qt 要求 UI 更新必须在主线程所以on_query_finished里才真正刷新图表。5.3 PyInstaller 打包后图表空白或闪退现象本地命令行运行一切正常用 PyInstaller 打成 exe 后窗口能打开但图表区空白或者直接闪退。原因PyQt5-Charts 在打包时不会被自动收集。PyInstaller 的静态分析能发现PyQt5.QtWidgets却抓不到PyQt5.QtChart的插件和资源文件。解决打包命令必须加--collect-data PyQt5有时还要显式--hidden-import PyQt5.QtChart。我一般同时加两个参数pyinstaller --clean --windowed --name TrafficSystem \ --collect-data PyQt5 \ --hidden-import PyQt5.QtChart \ --add-data sql/schema.sql;sql \ main.py5.4 时间统计差一小时流量曲线整体平移现象查某天 0 点到 23 点流量画出来的曲线高峰在凌晨 1 点明显不对。原因MySQL 的DATE_FORMAT(stat_time, %H:00)使用会话时区如果目标机器的系统时区不是东八区stat_time的 DATETIME 字符串虽然没变但聚合按会话时区解释后小时边界整体偏移。Python 的datetime.now()和 MySQL 的NOW()也可能不在同一个时区。解决生成数据时统一用无时区的datetime字符串写入查询时在 SQL 里用CONVERT_TZ指定时区或者更简单地在连接参数里加init_commandPooledDB( ... init_commandSET time_zone 08:00, )这个坑在开发机上不会出现因为系统时区恰好正确一旦你把代码部署到云服务器服务器默认 UTC 时区曲线就开始漂。做系统设计时把时区参数放进配置文件不要让它默认依赖操作系统。5.5 模拟数据太“均匀”图表看起来假领导不信现象流量曲线平滑得像教科书早晚高峰一模一样周末和工作日没有区分和真实路况明显对不上。原因生成数据用了random.uniform(0, 100)或者固定倍数缺少两个真实特征一是逐日随机波动二是有事故、管制时的异常值。模型能跑通但拿去给决策者看会被一眼识破。解决在生成脚本里加两个变量每日浮动系数和异常事件概率。每日浮动系数用random.gauss(1.0, 0.15)表示某天整体比平均高或低 15%再以 2% 概率把某时段流量直接压低 40%模拟临时管制。这样画出来的趋势图有正常的“毛刺”不会被人质疑是造假数据。真实数据接入后给每条记录打source字段区分模拟和实测避免分析结论混在一起。提示避坑原则是把“能出图”当成底线把“图可信”当成目标。你拿去答辩或者汇报时评审第一个问题很多时候是“数据哪来的”这第 5 条就是给他们看的。6. 进阶给系统加一个短时交通流量预测模块从“看图”到“预判”系统能查历史、看趋势之后值班员的下一步需求一定是“预测接下来一小时会不会堵”。不引入深度学习也能做先落一个线性回归基线既简单又可解释。# predictor.py import numpy as np def build_feature_matrix(hours): 把小时序列转成特征矩阵小时索引和一周内的星期几 weekday [h % 7 for h in hours] hour [h % 24 for h in hours] return np.column_stack([hour, weekday, np.ones_like(hour)]) def train_predictor(hours, flows): A build_feature_matrix(hours) coef, _, _, _ np.linalg.lstsq(A, flows, rcondNone) return coef def predict_next(prev_hours, prev_flows, next_hours): coef train_predictor(prev_hours, prev_flows) X build_feature_matrix(next_hours) return X coef验证方法不要用随机划分时间序列必须按顺序切前四周做训练最后一周做验证。from sklearn.metrics import mean_absolute_error actual flows[-7 * 24:] pred predict_next(hours[:-7 * 24], flows[:-7 * 24], hours[-7 * 24:]) mae mean_absolute_error(actual, pred)我在一个路口的数据上跑MAE 大约在每小时 18 辆作为短时预判足够用。加这个模块并不复杂GUI 里新增一个“预测”页传最近 168 个小时的流量输出未来一小时的点叠加在历史趋势图尾部。我踩过的坑是拿全量数据随机洗牌再评估测试集里混着训练集对应的时间段预测出来误差小得离谱上线一跑立刻穿帮。时间序列预测的评估顺序是底线不能贪快。这个项目做到这里就已经从“数据可视化分析系统”跨进了“辅助决策系统”的门槛。希望帮到你。本文还有配套的精品资源点击获取