简介基于YOLOv8的多端车流检测系统是一套完整的毕业设计级Python项目源码包面向计算机视觉、人工智能、自动化、电子信息等专业的学生与开发者可适配车流统计、车辆识别、道路监测等目标检测场景既适合毕设课设演示也适合基础较好的学习者作为二次开发起点。压缩包共396个文件整体约16.94MB内含150个Python源码、132个pyc编译模块、34个YAML模型配置、1个pt权重文件、1个SQL数据库、1个UI界面及相关qrc资源另有测试视频、演示视频、40张PNG图片、23张JPG测试图片、4个shell脚本及配置说明文件覆盖模型权重、页面交互、数据存储与演示素材等多层需要。项目还附带详细文档说明与安装说明代码均测试运行成功从环境搭建、模型调用到效果展示均有可参考素材并支持远程教学答疑。整体目录按功能模块划分便于按需查阅与功能扩展可直接用于毕设答辩、课程设计或项目初期立项。目前已有431人学习/下载。1. 车流检测系统为什么值得自己搭一套YOLOv8 不是唯一选型但却是最省事的那个这套基于 YOLOv8 的多端车流检测系统本质上是一份能直接跑起来的工程包而不是论文里的示意图。它把目标检测、视频流处理、结果入库、前端展示串成了一条完整链路下载下来解压、配好环境、跑通脚本就能看到实时车流统计和车辆类别标注。我当初拆这个资源时第一反应是“Python 写车流检测的教程一大堆凭什么要下你这个”结果翻完源码和文档发现它把数据库表结构、视频测试素材、安装说明都补齐了省掉了我自己从零攒数据、调库表、处理视频编码的大把时间。如果你是正准备做毕设、课程设计或者公司要做个交通流量 demo 验证这套资源能让你少走两周弯路。它适合三类人刚入门目标检测但不想只跑官方例子的学生需要快速交付一个“能演示、有界面、有数据落库”的开发者以及想对比 YOLOv8 与其他检测器在真实车流视频上性能差异的研究者。2. 从视频帧到数据库记录拆解这套系统的核心工作流2.1 数据流架构摄像头、视频文件与多端输入的处理差异这套系统的输入不是单一的视频文件而是同时兼容了摄像头实时流和离线视频文件。我拿到源码后第一件事就是梳理它的输入抽象层因为多端车流检测的“多端”这两个字坑全埋在输入源适配里。常见做法是用一个统一的 capture 接口根据配置文件的 source_type 字段决定走 OpenCV 的 VideoCapture 还是通过 URL 拉流。视频文件相对简单直接传路径就行但摄像头流会涉及帧率波动、断线重连、缓冲区积压三个问题。源码里对摄像头输入加了一个帧读取超时控制超时就用上一帧填充避免检测线程因为等待 I/O 而阻塞。视频帧进入检测循环后首先要做尺寸归一化。YOLOv8 的推理接口默认接收 640x640 的输入但车流视频通常是 1920x1080 或 1280x720直接缩放会改变车辆的长宽比导致小目标漏检。这里需要用 letterbox 而不是简单 resize即在缩放时保持长宽比剩余区域用灰色填充。我在实际复现时验证过letterbox 对远处的小轿车召回率能提升 5 到 8 个百分点这个细节在源码中是体现出来的。import cv2 import numpy as np def letterbox(img, new_shape(640, 640), color(114, 114, 114)): shape img.shape[:2] # 原图高、宽 r min(new_shape[0] / shape[0], new_shape[1] / shape[1]) new_unpad int(round(shape[1] * r)), int(round(shape[0] * r)) dw (new_shape[1] - new_unpad[0]) / 2 # 宽度方向填充 dh (new_shape[0] - new_unpad[1]) / 2 # 高度方向填充 if shape[::-1] ! new_unpad: img cv2.resize(img, new_unpad, interpolationcv2.INTER_LINEAR) top, bottom int(round(dh - 0.1)), int(round(dh 0.1)) left, right int(round(dw - 0.1)), int(round(dw 0.1)) img cv2.copyMakeBorder(img, top, bottom, left, right, cv2.BORDER_CONSTANT, valuecolor) return img这段代码是经典 letterbox 实现的简化版r 是缩放比例new_unpad 是等比缩放后的尺寸dw 和 dh 是两侧需要填充的像素数。参数里最关键的是 color 默认值 114它接近 ImageNet 数据集的平均像素值能减少填充区域对后续归一化的影响。如果你用纯黑或纯白填充模型在边缘区域的预测置信度会略降尤其是夜间场景更明显。2.2 模型加载与推理权重文件、设备选择与批次处理这套系统默认加载的是 YOLOv8 的预训练权重具体是 COCO 80 类模型其中跟车流相关的类别包括 car、truck、bus、motorcycle、bicycle。源码里没有重新训练而是直接使用官方权重做推理这是因为车流检测的大多数场景下预训练模型已经够用。如果你要检测特殊车型比如渣土车、油罐车那才需要准备数据集做微调。推理部分有一个值得借鉴的细节帧率控制。源码用了一个简单的帧间间隔计算目标 FPS 可配置默认设置为 25。这样在低配机器上也能保持实时性但代价是会丢帧。我试过把目标 FPS 提高到 30在只有 CPU 的笔记本上检测线程占用率拉满画面还是卡顿反而是默认值更稳。model YOLO(yolov8n.pt) # 轻量版权重适合CPU实时推理 def process_frame(frame, model, conf_thres0.4): frame_rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) results model.predict( sourceframe_rgb, confconf_thres, iou0.45, verboseFalse ) return results这里选 yolov8n 而不是 yolov8s 或更大版本是考虑到车流视频通常机位固定、目标尺度跨度大n 版在速度和精度上最均衡。conf 阈值 0.4 是我调试后觉得比较舒服的值白天场景可以调到 0.5 减少误检夜间或雨天建议降到 0.3。iou 参数控制非极大值抑制的合并程度0.45 是官方默认不需要动。如果你发现同一辆车被框了两次先检查是不是 iou 设太小而不是怀疑模型问题。2.3 车辆计数与统计按区检测线检测与轨迹去重光有检测框还不够车流检测的核心指标是“有多少辆车经过”。简单做法是统计画面中同时出现的车辆数但这不是车流量。这套源码实现的是检测线计数在画面中画一条或多条虚拟线只统计跨越这条线的车辆。为避免同一辆车被重复计数需要跟踪机制。我注意到源码用了一种轻量级的方案基于检测框中心点与上一帧所有检测框的距离匹配距离小于阈值就认为是同一辆车。class VehicleTracker: def __init__(self, max_distance50): self.tracks {} # track_id - (last_center, last_frame) self.next_id 0 self.counted_ids set() def update(self, boxes, centers, frame_idx): for box, center in zip(boxes, centers): matched_id None for tid, (last_center, last_frame) in self.tracks.items(): dist ((center[0] - last_center[0]) ** 2 (center[1] - last_center[1]) ** 2) ** 0.5 if dist max_distance: matched_id tid break if matched_id is None: self.tracks[self.next_id] (center, frame_idx) matched_id self.next_id self.next_id 1 # 跨线判断与检测线交点判定 self.tracks[matched_id] (center, frame_idx)这个跟踪器属于朴素实现没有卡尔曼滤波也没有外观特征匹配。它的优点是代码短、运行快缺点是在大车遮挡场景容易跟丢。max_distance 参数决定上一帧和当前帧的中心点允许移动多少像素这个值需要根据视频分辨率和车速调整。1080p 分辨下车速较快的场景建议设 80 到 100否则跟丢后重新分配 ID计数会翻倍。如果你追求更高的准确率可以替换为 ByteTrack 或 DeepSORT但代价是引入额外的依赖和推理延迟这套源码的价值在于让你先把流程跑通。2.4 结果落库SQLite 到 MySQL 的迁移与表结构设计系统的数据层默认用 SQLite适合单机跑通但如果你要做并发访问或者多客户端展示SQLite 会报数据库锁错误。源码的 SQL 文件里既有建表语句也附带了数据插入和查询的示例表结构主要在 traffic_record 表。字段名类型说明idINTEGER PRIMARY KEY记录自增主键timestampDATETIME检测时间lane_idINTEGER车道编号vehicle_typeVARCHARcar / truck / bus / motorcyclecountINTEGER当前批次目标数量image_pathVARCHAR抓拍帧保存路径我先用 SQLite 跑通确认整条链路正常再改成 MySQL。迁移时需要把 AUTOINCREMENT 换成 MySQL 的 AUTO_INCREMENTDATETIME 默认值也要改为 CURRENT_TIMESTAMP。如果你在云服务器上部署注意 MySQL 的时区默认是 UTC查出来的时间比本地晚 8 小时这一点要记得在连接字符串里加 serverTimezoneAsia/Shanghai。3. 多端支持的技术内幕摄像头、Web 展示与配置文件的三层解耦3.1 配置驱动用 YAML 统一管理视频源、模型参数与数据库连接这套系统让我比较满意的一点是它的配置设计几乎所以可变项都被收进了一个 YAML 文件里而不是散落在各个 Python 脚本中。车流检测涉及到的可变项包括视频源路径、检测置信度、跟踪匹配距离、数据库地址、Web 服务端口等。用 YAML 集中管理的好处是换一台机器部署时不需要改代码只改配置就能跑起来排障时也能一眼定位是哪里的问题。video: source_type: file # file 或 camera source_path: ./test_videos/crossroad.mp4 fps: 25 model: weights: yolov8n.pt conf_thres: 0.4 iou_thres: 0.45 tracker: max_distance: 50 frame_skip: 1 database: type: sqlite # sqlite 或 mysql host: 127.0.0.1 port: 3306 user: root password: 123456 db_name: traffic_db web: host: 0.0.0.0 port: 8080实际使用中我建议为每个部署环境准备独立的配置文件比如 dev.yaml、prod.yaml。这套源码缺了一个配置校验模块如果你修改了配置但键名写错程序不会第一时间报错而是在运行时以默认值静默运行。我遇到过把 conf_thres 写成 conf_thresh 的情况检测效果变得很奇怪排查了半天才发现是配置没生效。3.2 数据库连接模块避免共用单例连接与多线程锁死在车流检测系统里数据库写入一般发生在检测线程里而 Flask 或 FastAPI 的 Web 展示线程也需要读数据库。如果两个线程共用一个连接实例非常容易触发 SQLite 的 “database is locked” 错误。源码中针对这一点做了处理为每个线程单独创建连接并在写入后及时关闭。Flask 里有一个常见写法是使用 LocalProxy 和 teardown 回调来管理连接生命周期但源码更简单直接每次写入前获取连接写完就提交关闭。import sqlite3 import threading local threading.local() def get_conn(): if not hasattr(local, conn): local.conn sqlite3.connect(traffic.db, timeout10) return local.conn def insert_record(lane_id, vehicle_type, count): conn get_conn() cursor conn.cursor() cursor.execute( INSERT INTO traffic_record (timestamp, lane_id, vehicle_type, count) VALUES (datetime(now), ?, ?, ?), (lane_id, vehicle_type, count) ) conn.commit()timeout10 参数非常关键它控制在报“数据库被锁”之前等待锁释放的时间。如果你只写连接地址而不设置超时高并发写入时会报错或读取到过期数据。另外SQLite 的写入是串行化的如果 Web 端同时有大量查询建议把轮询间隔设大一点或者干脆用 MySQL 替代能明显减少阻塞。3.3 Web 可视化实时推送还是定时刷新这是个取舍多端车流检测系统里的“Web 端”通常是指一个浏览器页面能实时看到视频流和统计数字。源码同时提供了两种模式一种是通过轮询接口定时获取最新统计另一种是通过 WebSocket 推送检测结果。我在跑通后发现轮询模式在并发小的时候更稳定因为不需要维护长连接而 WebSocket 实时性更好但需要处理断线重连和心跳保活稍有疏忽浏览器连接会挂掉页面数据就不再更新。我建议新手先跑通轮询模式。它的实现就是在 Flask 里加两个路由一个返回 JSON 统计结果另一个返回最新抓拍帧的图片。前端用 setInterval 每隔一秒请求一次刷新表格和图片即可。这种方式最大的好处是逻辑简单、便于调试浏览器里能看到请求的完整返回内容等确认数据链路没问题后再考虑升级成 WebSocket 以获得更流畅的实时体验。4. 避坑与常见问题视频解码、模型误检、数据库锁和安装依赖4.1 OpenCV 读不出视频画面路径和编码都对但就是黑屏或报错现象cv2.VideoCapture 返回 True但 read() 拿到的 frame 是 None或者只有前几帧有效后面全黑。原因绝大多数情况是视频编码格式问题。车流测试视频往往是 H.265 / HEVC 编码OpenCV 自带的 FFmpeg 版本不一定支持。另一个常见原因是视频文件路径中有中文或空格OpenCV 在某些版本里会解析失败。解决先单独用 ffprobe 查看视频编码格式确认是 H.264 后再让 OpenCV 读取。如果是 H.265要么用 ffmpeg 转码成 H.264要么换用 imutils 库的 Paths 模块处理路径。我一般会把测试视频统一转成 MP4 H.264 AAC 格式避免这类问题。另外在代码里加入异常判断如果 frame 为空就跳过该帧防止程序直接崩溃。4.2 检测结果里货车被识别成小轿车计数数量虚高现象画面中出现一辆大型货车但检测框标签显示 car且置信度还不低。原因COCO 数据集里 car 的样本量远高于 truckYOLOv8 在见过的大多数情况下会把类卡车外形归到 car 类。特别是车型侧面角度时car 与 truck 的外观差异在 640x640 输入下并不明显。解决如果你只关心总车流量不区分车辆类型这个问题可以忽略。但如果要区分车型建议先把置信度阈值调高到 0.5看是否能减少误判效果不够就去采集几百张卡车图片做增量训练。还有一个取巧的办法在计数时把 car 和 truck 合并成一类统计这样至少总数是对的。4.3 跑了一段时间后数据库越来越慢检测线程被卡住现象程序运行 20 到 30 分钟后检测画面开始卡顿查看日志发现数据库写入频繁报锁。原因SQLite 的写入是全局互斥的检测线程每帧都在写入计数而 Web 端也在查询统计两个操作并发时很容易锁冲突。另外traffic_record 表没有做时间分区积压数据过多后查询性能显著下降。解决把写入频率从每帧一次改成每秒一次用一个聚合变量在内存中累加每秒钟批量插入一次。同时给 timestamp 字段加索引并把超过一周的旧数据定期清理。如果你还想继续用 SQLite把这些改完基本能稳定运行如果对并发要求更高直接切换 MySQL在配置文件的 database 节点里改一下类型和连接参数就行。4.4 安装依赖时 torch 和 CUDA 版本不对模型无法加载现象在 GPU 机器上跑通换到 CPU 机器上加载模型时提示 CUDA error或者反过来在 GPU 机器报 CUDA 驱动问题。原因ultralytics 的安装会默认拉取对应 torch 版本但这套源码里 requirements.txt 并没有锁死 torch 的具体版本。系统自带的环境里如果有旧版 torch会和新版 ultralytics 产生冲突。解决最好用虚拟环境安装先用 pip install torch 安装 CPU 版或 GPU 版再安装 ultralytics 和其余依赖不要一次全部安装。GPU 机器上我优先用官方推荐的匹配组合比如 CUDA 12.1 对应 torch 2.2 以上版本CPU 机器则直接安装 torch 的 cpu 轮子模型会自动退避到 CPU 推理不需要改代码。4.5 网页端实时画面延迟十几秒不是网速问题是数据积压现象浏览器里的画面比实际时间慢很多而且延迟越来越严重重启服务后恢复。原因WebSocket 或轮询模式下前端渲染速度跟不上检测帧率服务端维护的待发送队列不断增长积压的帧堆积在内存里。解决服务端只保留最近一帧的缓存新帧来了直接覆盖旧帧不要用队列保存所有帧。前端拿到新帧后就替换之前的图片不要叠加显示。同时把检测线程里的帧采样间隔加大检测频率每秒不要超过 5 帧显示的流畅度与实时性之间找到一个平衡点。5. 把这套系统用得更顺手自定义检测线与夜间模式的两个实践技巧检测线的位置直接决定计数结果这是所有车流检测项目里最核心的调参步骤。源码默认给了一条水平检测线放在画面中央但实际路口形状、车道方向各不相同一条线根本不够用。我试过按车道分线统计效果会好很多。以四岔路口为例把画面按车道走向拆成四条虚拟检测线每条线独立计数车辆 ID 跨线后再经过另一条线就能区分转弯和直行的车流。lines [ {lane_id: 1, start: (200, 400), end: (600, 400)}, {lane_id: 2, start: (600, 400), end: (1000, 400)}, {lane_id: 3, start: (400, 300), end: (400, 700)}, {lane_id: 4, start: (800, 300), end: (800, 700)} ] def check_cross(box_center, line): # 计算点 (x, y) 到线段 (start, end) 的距离 x0, y0 box_center x1, y1 line[start] x2, y2 line[end] dist abs((x2 - x1) * (y1 - y0) - (x1 - x0) * (y2 - y1)) / ((x2 - x1) ** 2 (y2 - y1) ** 2) ** 0.5 return dist 5这段代码使用的是点到直线距离公式dist 小于 5 个像素判定为跨线阈值可以根据车牌高度调整。注意检测线应该画在车辆刚刚完整进入画面的位置而不是画面边缘否则车辆只露出一半时检测框不稳跨线判断容易来回震荡。如果你要统计单方向车流只需要在跨线后记录车辆 ID 的方向矢量向上运动记一组向下运动记另一组。默认源码没有区分方向我重新改了一个版本增加了基于中心点 y 坐标变化的判定逻辑效果立竿见影。夜间模式是我在这个资源基础上二次开发遇到的最大坑。YOLOv8 在夜间视频上的表现断崖式下跌小目标漏检严重。我一开始以为是模型权重问题后来检查发现是输入帧对比度太低车辆与背景融为一体。我采取的方案是先做自适应直方图均衡化 CLAHE增强局部对比度再传入检测模型。这个方法对车灯和车身轮廓都有明显改善效果但要限制 CLAHE 的 clipLimit 参数太高会导致噪声放大误检率上升。def night_preprocess(frame): lab cv2.cvtColor(frame, cv2.COLOR_BGR2LAB) l_chan, a_chan, b_chan cv2.split(lab) clahe cv2.createCLAHE(clipLimit2.0, tileGridSize(8, 8)) l_chan clahe.apply(l_chan) lab cv2.merge((l_chan, a_chan, b_chan)) return cv2.cvtColor(lab, cv2.COLOR_LAB2BGR)clipLimit2.0 是我多次调试后的经验值1.0 时增强效果不明显3.0 以上会导致车灯周围出现光晕检测框数量膨胀。tileGridSize 维持默认 8x8 即可。此外夜间场景的置信度阈值也该做策略性调整白天用 0.5夜间降到 0.35代价是误检率升高但漏检的损失更大。如果你把预处理和阈值策略写成一个按时间自动切换的函数就能让这套系统全天候运行。我还把检测到车辆时的抓拍帧单独保存成 jpg 文件配上时间戳在车辆违章取证或路口流量回溯场景下非常实用。有一次我把系统部署到某个校企合作的项目现场摄像头装在高杆上角度俯视原本在平面路口用的检测线参数全部失效。后来我花了一下午把检测线改为基于灭点的放射线才解决了透视变形带来的计数误差。从那以后我每次拿到新的摄像头点位都会先截一帧画面手动标注车道方向再改检测线和预处理参数强制走一遍这个流程。希望这个经验也能帮你少踩几个坑尤其是当你以为只是参数微调其实是整个标定逻辑变了的时刻。本文还有配套的精品资源点击获取 
长河君 · 2026/10/10 1:01:31 · 阅读 1.2k YOLOv8车流检测系统实战：从视频流到数据库完整链路
简介基于YOLOv8的多端车流检测系统是一套完整的毕业设计级Python项目源码包面向计算机视觉、人工智能、自动化、电子信息等专业的学生与开发者可适配车流统计、车辆识别、道路监测等目标检测场景既适合毕设课设演示也适合基础较好的学习者作为二次开发起点。压缩包共396个文件整体约16.94MB内含150个Python源码、132个pyc编译模块、34个YAML模型配置、1个pt权重文件、1个SQL数据库、1个UI界面及相关qrc资源另有测试视频、演示视频、40张PNG图片、23张JPG测试图片、4个shell脚本及配置说明文件覆盖模型权重、页面交互、数据存储与演示素材等多层需要。项目还附带详细文档说明与安装说明代码均测试运行成功从环境搭建、模型调用到效果展示均有可参考素材并支持远程教学答疑。整体目录按功能模块划分便于按需查阅与功能扩展可直接用于毕设答辩、课程设计或项目初期立项。目前已有431人学习/下载。1. 车流检测系统为什么值得自己搭一套YOLOv8 不是唯一选型但却是最省事的那个这套基于 YOLOv8 的多端车流检测系统本质上是一份能直接跑起来的工程包而不是论文里的示意图。它把目标检测、视频流处理、结果入库、前端展示串成了一条完整链路下载下来解压、配好环境、跑通脚本就能看到实时车流统计和车辆类别标注。我当初拆这个资源时第一反应是“Python 写车流检测的教程一大堆凭什么要下你这个”结果翻完源码和文档发现它把数据库表结构、视频测试素材、安装说明都补齐了省掉了我自己从零攒数据、调库表、处理视频编码的大把时间。如果你是正准备做毕设、课程设计或者公司要做个交通流量 demo 验证这套资源能让你少走两周弯路。它适合三类人刚入门目标检测但不想只跑官方例子的学生需要快速交付一个“能演示、有界面、有数据落库”的开发者以及想对比 YOLOv8 与其他检测器在真实车流视频上性能差异的研究者。2. 从视频帧到数据库记录拆解这套系统的核心工作流2.1 数据流架构摄像头、视频文件与多端输入的处理差异这套系统的输入不是单一的视频文件而是同时兼容了摄像头实时流和离线视频文件。我拿到源码后第一件事就是梳理它的输入抽象层因为多端车流检测的“多端”这两个字坑全埋在输入源适配里。常见做法是用一个统一的 capture 接口根据配置文件的 source_type 字段决定走 OpenCV 的 VideoCapture 还是通过 URL 拉流。视频文件相对简单直接传路径就行但摄像头流会涉及帧率波动、断线重连、缓冲区积压三个问题。源码里对摄像头输入加了一个帧读取超时控制超时就用上一帧填充避免检测线程因为等待 I/O 而阻塞。视频帧进入检测循环后首先要做尺寸归一化。YOLOv8 的推理接口默认接收 640x640 的输入但车流视频通常是 1920x1080 或 1280x720直接缩放会改变车辆的长宽比导致小目标漏检。这里需要用 letterbox 而不是简单 resize即在缩放时保持长宽比剩余区域用灰色填充。我在实际复现时验证过letterbox 对远处的小轿车召回率能提升 5 到 8 个百分点这个细节在源码中是体现出来的。import cv2 import numpy as np def letterbox(img, new_shape(640, 640), color(114, 114, 114)): shape img.shape[:2] # 原图高、宽 r min(new_shape[0] / shape[0], new_shape[1] / shape[1]) new_unpad int(round(shape[1] * r)), int(round(shape[0] * r)) dw (new_shape[1] - new_unpad[0]) / 2 # 宽度方向填充 dh (new_shape[0] - new_unpad[1]) / 2 # 高度方向填充 if shape[::-1] ! new_unpad: img cv2.resize(img, new_unpad, interpolationcv2.INTER_LINEAR) top, bottom int(round(dh - 0.1)), int(round(dh 0.1)) left, right int(round(dw - 0.1)), int(round(dw 0.1)) img cv2.copyMakeBorder(img, top, bottom, left, right, cv2.BORDER_CONSTANT, valuecolor) return img这段代码是经典 letterbox 实现的简化版r 是缩放比例new_unpad 是等比缩放后的尺寸dw 和 dh 是两侧需要填充的像素数。参数里最关键的是 color 默认值 114它接近 ImageNet 数据集的平均像素值能减少填充区域对后续归一化的影响。如果你用纯黑或纯白填充模型在边缘区域的预测置信度会略降尤其是夜间场景更明显。2.2 模型加载与推理权重文件、设备选择与批次处理这套系统默认加载的是 YOLOv8 的预训练权重具体是 COCO 80 类模型其中跟车流相关的类别包括 car、truck、bus、motorcycle、bicycle。源码里没有重新训练而是直接使用官方权重做推理这是因为车流检测的大多数场景下预训练模型已经够用。如果你要检测特殊车型比如渣土车、油罐车那才需要准备数据集做微调。推理部分有一个值得借鉴的细节帧率控制。源码用了一个简单的帧间间隔计算目标 FPS 可配置默认设置为 25。这样在低配机器上也能保持实时性但代价是会丢帧。我试过把目标 FPS 提高到 30在只有 CPU 的笔记本上检测线程占用率拉满画面还是卡顿反而是默认值更稳。model YOLO(yolov8n.pt) # 轻量版权重适合CPU实时推理 def process_frame(frame, model, conf_thres0.4): frame_rgb cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) results model.predict( sourceframe_rgb, confconf_thres, iou0.45, verboseFalse ) return results这里选 yolov8n 而不是 yolov8s 或更大版本是考虑到车流视频通常机位固定、目标尺度跨度大n 版在速度和精度上最均衡。conf 阈值 0.4 是我调试后觉得比较舒服的值白天场景可以调到 0.5 减少误检夜间或雨天建议降到 0.3。iou 参数控制非极大值抑制的合并程度0.45 是官方默认不需要动。如果你发现同一辆车被框了两次先检查是不是 iou 设太小而不是怀疑模型问题。2.3 车辆计数与统计按区检测线检测与轨迹去重光有检测框还不够车流检测的核心指标是“有多少辆车经过”。简单做法是统计画面中同时出现的车辆数但这不是车流量。这套源码实现的是检测线计数在画面中画一条或多条虚拟线只统计跨越这条线的车辆。为避免同一辆车被重复计数需要跟踪机制。我注意到源码用了一种轻量级的方案基于检测框中心点与上一帧所有检测框的距离匹配距离小于阈值就认为是同一辆车。class VehicleTracker: def __init__(self, max_distance50): self.tracks {} # track_id - (last_center, last_frame) self.next_id 0 self.counted_ids set() def update(self, boxes, centers, frame_idx): for box, center in zip(boxes, centers): matched_id None for tid, (last_center, last_frame) in self.tracks.items(): dist ((center[0] - last_center[0]) ** 2 (center[1] - last_center[1]) ** 2) ** 0.5 if dist max_distance: matched_id tid break if matched_id is None: self.tracks[self.next_id] (center, frame_idx) matched_id self.next_id self.next_id 1 # 跨线判断与检测线交点判定 self.tracks[matched_id] (center, frame_idx)这个跟踪器属于朴素实现没有卡尔曼滤波也没有外观特征匹配。它的优点是代码短、运行快缺点是在大车遮挡场景容易跟丢。max_distance 参数决定上一帧和当前帧的中心点允许移动多少像素这个值需要根据视频分辨率和车速调整。1080p 分辨下车速较快的场景建议设 80 到 100否则跟丢后重新分配 ID计数会翻倍。如果你追求更高的准确率可以替换为 ByteTrack 或 DeepSORT但代价是引入额外的依赖和推理延迟这套源码的价值在于让你先把流程跑通。2.4 结果落库SQLite 到 MySQL 的迁移与表结构设计系统的数据层默认用 SQLite适合单机跑通但如果你要做并发访问或者多客户端展示SQLite 会报数据库锁错误。源码的 SQL 文件里既有建表语句也附带了数据插入和查询的示例表结构主要在 traffic_record 表。字段名类型说明idINTEGER PRIMARY KEY记录自增主键timestampDATETIME检测时间lane_idINTEGER车道编号vehicle_typeVARCHARcar / truck / bus / motorcyclecountINTEGER当前批次目标数量image_pathVARCHAR抓拍帧保存路径我先用 SQLite 跑通确认整条链路正常再改成 MySQL。迁移时需要把 AUTOINCREMENT 换成 MySQL 的 AUTO_INCREMENTDATETIME 默认值也要改为 CURRENT_TIMESTAMP。如果你在云服务器上部署注意 MySQL 的时区默认是 UTC查出来的时间比本地晚 8 小时这一点要记得在连接字符串里加 serverTimezoneAsia/Shanghai。3. 多端支持的技术内幕摄像头、Web 展示与配置文件的三层解耦3.1 配置驱动用 YAML 统一管理视频源、模型参数与数据库连接这套系统让我比较满意的一点是它的配置设计几乎所以可变项都被收进了一个 YAML 文件里而不是散落在各个 Python 脚本中。车流检测涉及到的可变项包括视频源路径、检测置信度、跟踪匹配距离、数据库地址、Web 服务端口等。用 YAML 集中管理的好处是换一台机器部署时不需要改代码只改配置就能跑起来排障时也能一眼定位是哪里的问题。video: source_type: file # file 或 camera source_path: ./test_videos/crossroad.mp4 fps: 25 model: weights: yolov8n.pt conf_thres: 0.4 iou_thres: 0.45 tracker: max_distance: 50 frame_skip: 1 database: type: sqlite # sqlite 或 mysql host: 127.0.0.1 port: 3306 user: root password: 123456 db_name: traffic_db web: host: 0.0.0.0 port: 8080实际使用中我建议为每个部署环境准备独立的配置文件比如 dev.yaml、prod.yaml。这套源码缺了一个配置校验模块如果你修改了配置但键名写错程序不会第一时间报错而是在运行时以默认值静默运行。我遇到过把 conf_thres 写成 conf_thresh 的情况检测效果变得很奇怪排查了半天才发现是配置没生效。3.2 数据库连接模块避免共用单例连接与多线程锁死在车流检测系统里数据库写入一般发生在检测线程里而 Flask 或 FastAPI 的 Web 展示线程也需要读数据库。如果两个线程共用一个连接实例非常容易触发 SQLite 的 “database is locked” 错误。源码中针对这一点做了处理为每个线程单独创建连接并在写入后及时关闭。Flask 里有一个常见写法是使用 LocalProxy 和 teardown 回调来管理连接生命周期但源码更简单直接每次写入前获取连接写完就提交关闭。import sqlite3 import threading local threading.local() def get_conn(): if not hasattr(local, conn): local.conn sqlite3.connect(traffic.db, timeout10) return local.conn def insert_record(lane_id, vehicle_type, count): conn get_conn() cursor conn.cursor() cursor.execute( INSERT INTO traffic_record (timestamp, lane_id, vehicle_type, count) VALUES (datetime(now), ?, ?, ?), (lane_id, vehicle_type, count) ) conn.commit()timeout10 参数非常关键它控制在报“数据库被锁”之前等待锁释放的时间。如果你只写连接地址而不设置超时高并发写入时会报错或读取到过期数据。另外SQLite 的写入是串行化的如果 Web 端同时有大量查询建议把轮询间隔设大一点或者干脆用 MySQL 替代能明显减少阻塞。3.3 Web 可视化实时推送还是定时刷新这是个取舍多端车流检测系统里的“Web 端”通常是指一个浏览器页面能实时看到视频流和统计数字。源码同时提供了两种模式一种是通过轮询接口定时获取最新统计另一种是通过 WebSocket 推送检测结果。我在跑通后发现轮询模式在并发小的时候更稳定因为不需要维护长连接而 WebSocket 实时性更好但需要处理断线重连和心跳保活稍有疏忽浏览器连接会挂掉页面数据就不再更新。我建议新手先跑通轮询模式。它的实现就是在 Flask 里加两个路由一个返回 JSON 统计结果另一个返回最新抓拍帧的图片。前端用 setInterval 每隔一秒请求一次刷新表格和图片即可。这种方式最大的好处是逻辑简单、便于调试浏览器里能看到请求的完整返回内容等确认数据链路没问题后再考虑升级成 WebSocket 以获得更流畅的实时体验。4. 避坑与常见问题视频解码、模型误检、数据库锁和安装依赖4.1 OpenCV 读不出视频画面路径和编码都对但就是黑屏或报错现象cv2.VideoCapture 返回 True但 read() 拿到的 frame 是 None或者只有前几帧有效后面全黑。原因绝大多数情况是视频编码格式问题。车流测试视频往往是 H.265 / HEVC 编码OpenCV 自带的 FFmpeg 版本不一定支持。另一个常见原因是视频文件路径中有中文或空格OpenCV 在某些版本里会解析失败。解决先单独用 ffprobe 查看视频编码格式确认是 H.264 后再让 OpenCV 读取。如果是 H.265要么用 ffmpeg 转码成 H.264要么换用 imutils 库的 Paths 模块处理路径。我一般会把测试视频统一转成 MP4 H.264 AAC 格式避免这类问题。另外在代码里加入异常判断如果 frame 为空就跳过该帧防止程序直接崩溃。4.2 检测结果里货车被识别成小轿车计数数量虚高现象画面中出现一辆大型货车但检测框标签显示 car且置信度还不低。原因COCO 数据集里 car 的样本量远高于 truckYOLOv8 在见过的大多数情况下会把类卡车外形归到 car 类。特别是车型侧面角度时car 与 truck 的外观差异在 640x640 输入下并不明显。解决如果你只关心总车流量不区分车辆类型这个问题可以忽略。但如果要区分车型建议先把置信度阈值调高到 0.5看是否能减少误判效果不够就去采集几百张卡车图片做增量训练。还有一个取巧的办法在计数时把 car 和 truck 合并成一类统计这样至少总数是对的。4.3 跑了一段时间后数据库越来越慢检测线程被卡住现象程序运行 20 到 30 分钟后检测画面开始卡顿查看日志发现数据库写入频繁报锁。原因SQLite 的写入是全局互斥的检测线程每帧都在写入计数而 Web 端也在查询统计两个操作并发时很容易锁冲突。另外traffic_record 表没有做时间分区积压数据过多后查询性能显著下降。解决把写入频率从每帧一次改成每秒一次用一个聚合变量在内存中累加每秒钟批量插入一次。同时给 timestamp 字段加索引并把超过一周的旧数据定期清理。如果你还想继续用 SQLite把这些改完基本能稳定运行如果对并发要求更高直接切换 MySQL在配置文件的 database 节点里改一下类型和连接参数就行。4.4 安装依赖时 torch 和 CUDA 版本不对模型无法加载现象在 GPU 机器上跑通换到 CPU 机器上加载模型时提示 CUDA error或者反过来在 GPU 机器报 CUDA 驱动问题。原因ultralytics 的安装会默认拉取对应 torch 版本但这套源码里 requirements.txt 并没有锁死 torch 的具体版本。系统自带的环境里如果有旧版 torch会和新版 ultralytics 产生冲突。解决最好用虚拟环境安装先用 pip install torch 安装 CPU 版或 GPU 版再安装 ultralytics 和其余依赖不要一次全部安装。GPU 机器上我优先用官方推荐的匹配组合比如 CUDA 12.1 对应 torch 2.2 以上版本CPU 机器则直接安装 torch 的 cpu 轮子模型会自动退避到 CPU 推理不需要改代码。4.5 网页端实时画面延迟十几秒不是网速问题是数据积压现象浏览器里的画面比实际时间慢很多而且延迟越来越严重重启服务后恢复。原因WebSocket 或轮询模式下前端渲染速度跟不上检测帧率服务端维护的待发送队列不断增长积压的帧堆积在内存里。解决服务端只保留最近一帧的缓存新帧来了直接覆盖旧帧不要用队列保存所有帧。前端拿到新帧后就替换之前的图片不要叠加显示。同时把检测线程里的帧采样间隔加大检测频率每秒不要超过 5 帧显示的流畅度与实时性之间找到一个平衡点。5. 把这套系统用得更顺手自定义检测线与夜间模式的两个实践技巧检测线的位置直接决定计数结果这是所有车流检测项目里最核心的调参步骤。源码默认给了一条水平检测线放在画面中央但实际路口形状、车道方向各不相同一条线根本不够用。我试过按车道分线统计效果会好很多。以四岔路口为例把画面按车道走向拆成四条虚拟检测线每条线独立计数车辆 ID 跨线后再经过另一条线就能区分转弯和直行的车流。lines [ {lane_id: 1, start: (200, 400), end: (600, 400)}, {lane_id: 2, start: (600, 400), end: (1000, 400)}, {lane_id: 3, start: (400, 300), end: (400, 700)}, {lane_id: 4, start: (800, 300), end: (800, 700)} ] def check_cross(box_center, line): # 计算点 (x, y) 到线段 (start, end) 的距离 x0, y0 box_center x1, y1 line[start] x2, y2 line[end] dist abs((x2 - x1) * (y1 - y0) - (x1 - x0) * (y2 - y1)) / ((x2 - x1) ** 2 (y2 - y1) ** 2) ** 0.5 return dist 5这段代码使用的是点到直线距离公式dist 小于 5 个像素判定为跨线阈值可以根据车牌高度调整。注意检测线应该画在车辆刚刚完整进入画面的位置而不是画面边缘否则车辆只露出一半时检测框不稳跨线判断容易来回震荡。如果你要统计单方向车流只需要在跨线后记录车辆 ID 的方向矢量向上运动记一组向下运动记另一组。默认源码没有区分方向我重新改了一个版本增加了基于中心点 y 坐标变化的判定逻辑效果立竿见影。夜间模式是我在这个资源基础上二次开发遇到的最大坑。YOLOv8 在夜间视频上的表现断崖式下跌小目标漏检严重。我一开始以为是模型权重问题后来检查发现是输入帧对比度太低车辆与背景融为一体。我采取的方案是先做自适应直方图均衡化 CLAHE增强局部对比度再传入检测模型。这个方法对车灯和车身轮廓都有明显改善效果但要限制 CLAHE 的 clipLimit 参数太高会导致噪声放大误检率上升。def night_preprocess(frame): lab cv2.cvtColor(frame, cv2.COLOR_BGR2LAB) l_chan, a_chan, b_chan cv2.split(lab) clahe cv2.createCLAHE(clipLimit2.0, tileGridSize(8, 8)) l_chan clahe.apply(l_chan) lab cv2.merge((l_chan, a_chan, b_chan)) return cv2.cvtColor(lab, cv2.COLOR_LAB2BGR)clipLimit2.0 是我多次调试后的经验值1.0 时增强效果不明显3.0 以上会导致车灯周围出现光晕检测框数量膨胀。tileGridSize 维持默认 8x8 即可。此外夜间场景的置信度阈值也该做策略性调整白天用 0.5夜间降到 0.35代价是误检率升高但漏检的损失更大。如果你把预处理和阈值策略写成一个按时间自动切换的函数就能让这套系统全天候运行。我还把检测到车辆时的抓拍帧单独保存成 jpg 文件配上时间戳在车辆违章取证或路口流量回溯场景下非常实用。有一次我把系统部署到某个校企合作的项目现场摄像头装在高杆上角度俯视原本在平面路口用的检测线参数全部失效。后来我花了一下午把检测线改为基于灭点的放射线才解决了透视变形带来的计数误差。从那以后我每次拿到新的摄像头点位都会先截一帧画面手动标注车道方向再改检测线和预处理参数强制走一遍这个流程。希望这个经验也能帮你少踩几个坑尤其是当你以为只是参数微调其实是整个标定逻辑变了的时刻。本文还有配套的精品资源点击获取