OpenCV与Python实战：实时交通车流检测与计数系统

简介：基于Python和OpenCV的实时交通监测系统设计源码，面向智能交通、工控机监控等应用场景，适合对计算机视觉与交通参数提取感兴趣的开发者学习。系统通过处理视频流或视频文件，可实时提取车流量、车速和排队长度等关键指标。资源包共31个文件，大小295KB，主要包含11个Python源文件、6个XML配置、若干图片与文档。其中Python文件覆盖视频输入、背景差异分析、流量计数、车速检测等核心流程；XML文件用于保存算法参数与工程配置；Markdown与txt文档则提供使用说明和开发注意事项。目前已有430人学习下载，整体内容结构完整，从预处理到检测模块均有对应代码，并附有示例图片与工程配置，便于直接运行、调试及二次扩展，可作为课程设计或智能交通项目的基础框架。

1. 实时交通监测系统：Python + OpenCV 把摄像头变成车流计数器

在路口掐着秒表人工数车，数到第十分钟就开始怀疑人生。这套基于 Python 和 OpenCV 的实时交通监测系统源码，正是为这个场景准备的：输入监控视频或摄像头画面，自动完成车辆检测、跟踪与跨线计数，把车流统计结果实时叠加到画面上输出。它不依赖深度学习框架，一条纯 OpenCV 视觉管线就能跑通全流程，课程设计、毕业设计、小型路侧车流统计都能直接上手。源码拿到手先别急着跑，检测线位置、背景阈值、跟踪距离这三个参数不调，任何视频都可能翻车。下文按系统架构、环境搭建、核心代码、踩坑记录、验证技巧的顺序展开，照着复制即可跑通。

2. 系统架构与核心模块：从视频帧到车流量的完整链路

2.1 模块划分：四级管线各管一段

系统不是一个大文件从头写到尾，而是按数据流拆成五个模块。video_input 负责读视频或摄像头，preprocess 做灰度化、模糊和 ROI 裁剪，detector 负责背景减除和轮廓提取，tracker 做质心匹配与跨线计数，visualize 把框、检测线和计数值画回原图。main.py 作为主程序按帧循环串联这几个模块，每一帧从头到尾走完这条管线。

这个拆法最大的好处是出问题时能定位到具体环节。计数不对，先看 detector 输出的前景掩码干不干净，再判断 tracker 匹配逻辑，不用一帧一帧去打断点。下面是模块职责和关键函数的对应关系。

这个表格里有一个容易忽略的点：detector 输出的轮廓坐标是相对于 ROI 的，而 visualize 画框是在原图上画，两者之间必须加上 ROI 起点偏移。我第一次跑通时在这里犯过傻，画出的框全偏到左上角，后面第 5 章会再提一次。

2.2 帧预处理与 ROI：灰度化不是玄学，是实打实的算力节省

OpenCV 读进来的帧是 BGR 三通道，而背景减除在灰度图上就能工作。把彩色帧转成灰度图，三个通道变成一通道，后面的高斯模糊、背景建模、轮廓提取都少算两份数据。对 1080p 视频来说，这一步能省掉接近一半的预处理耗时。

高斯模糊的作用是抑制传感器噪点和路面纹理抖动。车辆轮廓是低频信号，噪点是高频信号，一个 5x5 的高斯核就能把大部分高频噪点抹平，背景减除后的掩码里不会出现满屏白色雪花。这里我一般固定用 (5,5) 核，sigma 置 0 让 OpenCV 自动算，效果比手动指定好。

# 帧预处理：灰度 + 高斯模糊 + ROI 截取 import cv2 import numpy as np # ROI 定义在画面坐标系里，这里是 1280x720 画面的中间车道区域 ROI_X, ROI_Y, ROI_W, ROI_H = 150, 180, 900, 460 def preprocess(frame): gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) gray = cv2.GaussianBlur(gray, (5, 5), 0) # 只保留车道区域，排除人行道、对向车道 roi = gray[ROI_Y:ROI_Y + ROI_H, ROI_X:ROI_X + ROI_W] return gray, roi

逻辑说明：先转灰度再模糊最后切片，顺序不要乱。如果先切片再模糊，ROI 边界处会产生卷积假象，边缘像素被拉伸，背景减除时边界会出现一道白边。ROI 截取的是灰度图，后续检测、画框全在这个小区域里进行，效率明显高于全图处理。

参数说明：ROI 并不是越窄越好，至少要覆盖车辆从出现到通过检测线的完整移动范围。如果 ROI 上下太短，车辆还没加速到稳定速度就越过了检测线，跟踪匹配来不及建立；如果左右太窄，并行的第二辆车会被切掉一半轮廓，直接漏检。建议一开始放宽 ROI，跑通后再逐步收紧。

2.3 目标检测选型：MOG2 比帧差法和光流更适合这个场景

运动目标检测有几种常见做法：帧差法、光流法、背景减除。帧差法取相邻两帧做差，实现简单但对速度敏感，车在红灯前停稳就立刻消失；光流法能提取每个像素的运动向量，精度高但计算量在 CPU 上基本跑不满实时；背景减除是监控场景最常用的折中方案。

MOG2（混合高斯背景建模）是背景减除的经典实现。每个像素点用多个高斯分布建模其历史取值，光线缓慢变化会被当成背景波动，只有真正偏离模型的目标才标记为前景。它比帧差法强在车辆短时静止几秒仍保留在前景中；比光流法快在核心计算在 C++ 层完成，Python 侧只读掩码。

顺带澄清一个容易搜到的误区：网上很多“OpenCV 检测直线”教程用的是 HoughLinesP 做车道线检测，那是道路标线识别，不是本系统的车辆检测。车道线是静态内容，HoughLinesP 在单帧上找直线；车辆是动态目标，必须靠时序信息（背景减除或帧间差分）才能分离。方向别搞混，否则你会拿着一张静态图到处问为什么检测不到车。

MOG2 的失效边界也要心里有数：严重拥堵时车辆几乎不动，超过 history 时长后会被逐渐吸收进背景；大客车挡住后方小车时，被遮挡的小车会在掩码里断裂成两块。后面 4.4 会讲怎么用参数组合缓解，但完全消除需要换深度学习检测器，那不是这套源码的定位。

2.4 计数逻辑：虚拟检测线为什么比数整帧目标可靠

大多数计数系统在画面里设置一条虚拟检测线，车辆跨过它就算通过一次。这个做法的前提是摄像头固定、画面背景基本静止、车辆沿固定方向移动。当车辆质心从线的上方跨到下方，计数加一；反向行驶则从下往上再加。相比统计画面里当前有几个目标，跨线计数天然抗抖动，车在画面里停住也不会被重复累计。

为什么不直接比对连续两帧的目标数量？因为目标数量受遮挡和轮廓断裂影响极大，一辆大货车在画面里可能一会儿是 1 个轮廓、一会儿是 4 个轮廓，按目标数计数误差非常感人。用质心位置加跨线判断，等于把“有没有通过”简化成“有没有越过一条线”，逻辑简单且对目标分裂有容错。

质心计算用轮廓的一阶矩（cv2.moments），不用外接矩形中心。外接矩形中心容易受车身纹理影响，车窗反光或贴纸会让矩形左右偏移；轮廓矩是对整个轮廓像素分布做加权，质心更接近车辆真实几何中心。这个细节在并排行驶、轮廓有粘连时差距尤其明显。

检测线位置放在 ROI 的 1/3 到 1/2 高度比较合适。放得太靠上，车辆刚进入识别区，轮廓还没稳定，质心会大幅跳变；放得太靠下，车辆离摄像头太近，轮廓过大且可能出画，容易漏计。熟练之后可以加两根线，双向通行的车各计各的，就得到进出两个方向的车流量。

3. 环境搭建与源码运行：十分钟跑通第一个 demo

3.1 安装 Python 与 OpenCV：版本组合别乱搭

先明确一点：这套源码用的是 OpenCV 传统视觉 API，不涉及深度学习模块，所以装标准版 opencv-python 就够，不必额外装 opencv-contrib-python。contrib 包里包含 SIFT、xfeatures2d 等扩展模块，体积大一圈，装错了也不报错，但没必要。

Python 版本建议在 3.9 到 3.11 之间。OpenCV 4.x 的预编译轮子在 3.8 之后的版本上都很稳，太新的 Python 可能吃不到对应轮子，pip 会尝试从源码编译，那基本就是劝退现场。安装走虚拟环境，避免污染系统 Python，这在 Windows 上尤其重要。

# 创建并激活虚拟环境（Windows / macOS / Linux 两条激活命令二选一） python -m venv traffic_env traffic_env\Scripts\activate # Windows source traffic_env/bin/activate # macOS / Linux # 安装 OpenCV 与依赖 pip install opencv-python numpy matplotlib

参数说明：numpy 不用单独指定版本，opencv-python 会自动拉取匹配的 numpy；matplotlib 是可选依赖，用于把计数结果画成折线图，不需要可以跳过。如果网络慢，可以加 --index-url 指定镜像源，但不同机构镜像地址不一样，遇到超时再换。

装完后验证一下，避免出现“明明装了却 import 不到”这种诡异情况。

# 验证安装 python -c "import cv2; print(cv2.__version__)"

如果输出类似 4.9.0，说明安装完成。如果报 ModuleNotFoundError，先看当前用的是哪个解释器。用 VSCode 跑代码的话，记得按 Ctrl+Shift+P 打开命令面板，选择 Python 解释器路径，指向刚才创建虚拟环境里的 python.exe。这一步跟安装同样重要，很多“装不上”其实是解释器选错。

提示：VSCode 里选了系统 Python 导致 import 失败的情况非常多，装包前先确认解释器路径，能少走一半弯路。

3.2 源码目录结构：从 main.py 开始读

源码包不是单个文件，而是按模块组织的工程结构。拿到之后先花两分钟看目录，别急着运行。下面是这类系统最常见的文件组织方式。

我的建议是先打开 config.py，把视频路径改成你自己的；再打开 main.py，看它每帧做了哪几件事。main.py 通常很短，只有 read、preprocess、detect、track、draw 五步，业务逻辑全部在 detector 和 tracker 里，符合“入口薄、模块厚”的写法。调试时也按这个顺序来：先确认输入帧正常，再确认掩码干净，最后才是计数逻辑。

3.3 运行方式与参数调整：命令行覆盖配置

有两种运行方式，一种是直接改 config.py，适合一次性调试；另一种是命令行传参覆盖，适合批量测试多组参数。命令行方式不用反复改文件，跑对比实验时特别好用。

# 直接运行 python main.py # 命令行覆写关键参数 python main.py --video data/traffic.mp4 --line-y 420 --min-area 2000 --skip-frames 2

参数表如下，这几个参数是系统最主要的旋钮，后面第 4 章会展开讲联动关系。

skip-frames 这个参数很多人一上来就设 0（每帧都处理），结果 CPU 满载、画面卡成幻灯片。我一般先设 2 或 3，处理速度上去了，质心位移量变大，只要把跟踪匹配的最大距离阈值同步放大就行。帧与帧之间车流是连续的，适当跳帧带来的误差远小于背景建模卡顿带来的误差。

跑起来之后观察三个信号判断是否正常：画面窗口能持续刷新、FPS 数值保持稳定、车辆经过检测线时计数值单调递增。如果计数值忽大忽小或者 FPS 掉到个位数，先按第 5 章的排错流程走，别急着调参数。config.py 里的 video_source 可以写文件路径也可以写 0 表示默认摄像头，用摄像头联调时如果画面一闪而过，多半是 cap.read() 返回 False 没有处理，先断点观察 ret 值。

4. 核心代码拆解：车辆检测、跟踪与跨线计数的实现细节

4.1 背景差分与形态学处理：把“动的车”从静止画面里抠出来

背景减除器的核心调用只有一行，但参数直接影响检测效果。先看代码，再讲参数含义。

import cv2 import numpy as np # 混合高斯背景建模器 bg_sub = cv2.createBackgroundSubtractorMOG2( history=500, # 背景模型参考的历史帧数 varThreshold=25, # 像素值方差阈值，决定“变化多少算前景” detectShadows=True # 分离阴影区域，在 mask 中用灰度 127 标记 ) cap = cv2.VideoCapture('data/traffic.mp4') while True: ret, frame = cap.read() if not ret: break # 当前帧与背景模型对比，得到前景掩码 fgmask = bg_sub.apply(frame) # 形态学开运算：先腐蚀再膨胀，去掉孤立噪点 kernel = cv2.getStructuringElement(cv2.MORPH_ELLIPSE, (5, 5)) fgmask = cv2.morphologyEx(fgmask, cv2.MORPH_OPEN, kernel) # 膨胀两次，把车辆内部空洞补上，让轮廓保持完整 fgmask = cv2.dilate(fgmask, kernel, iterations=2)

逻辑说明：bg_sub.apply 每次调用都会更新内部背景模型，这是它和帧差法的本质区别。第一次调用时背景是空的，OpenCV 会用前面若干帧逐步建立背景，所以程序刚启动的 0.5 秒内 mask 基本是黑的，这正常。detectShadows 开启后，阴影区域在 mask 中是 127 的灰度值，不会被 findContours 的 255 提取，但阴影仍会影响轮廓形状，所以形态学操作不能省。

参数说明：history 越大，背景对新场景适应越慢，车辆短时停车越不容易被吸收，但场景光线缓慢变化时也越迟钝。varThreshold 是敏感性旋钮，调低能让暗色车辆更明显，代价是树叶摇曳、水面反光更容易误检。这两个值没有绝对标准，一天中不同时段表现差异很大，后面 4.4 给一组可以试的起点组合。

4.2 轮廓提取与面积过滤：把掩码变成可跟踪的目标

拿到干净的前景掩码后，用 findContours 提取轮廓，再按面积过滤，就得到“车辆候选框”。

# 提取轮廓并过滤 contours, _ = cv2.findContours( fgmask, cv2.RETR_EXTERNAL, # 只取最外层轮廓，防止车内纹理拆成多个目标 cv2.CHAIN_APPROX_SIMPLE # 压缩存储点，只保留关键端点 ) detections = [] for cnt in contours: area = cv2.contourArea(cnt) # 面积过滤：小轮廓多半是噪点、树叶、昆虫掠过 if area < config.MIN_AREA: continue x, y, w, h = cv2.boundingRect(cnt) # 外接矩形，用于画框 # 用一阶矩计算质心，比外接矩形中心更稳定 M = cv2.moments(cnt) if M['m00'] > 0: cx = int(M['m10'] / M['m00']) cy = int(M['m01'] / M['m00']) else: continue detections.append({'bbox': (x, y, w, h), 'centroid': (cx, cy)})

逻辑说明：RETR_EXTERNAL 只取最外层轮廓。如果换成 RETR_LIST 或 RETR_TREE，车身贴纸、车窗反光造成的内部轮廓也会被当成独立目标，一辆车输出好几个 bbox。CHAIN_APPROX_SIMPLE 压缩轮廓点，只保留能描述形状的端点，内存和后续计算都更省。

参数说明：MIN_AREA 跟摄像头高度直接相关。俯拍视角下轿车投影面积大，2000 合理；如果摄像头架在五楼往下拍，车辆只有几百像素，MIN_AREA 就该降到 500，否则全被过滤掉。判断方法很直接：把 mask 用 cv2.imwrite 存一帧，数一下最大的白色连通域大约多少像素，MIN_AREA 取它的三分之一左右。

4.3 质心跟踪与跨线计数：把“这辆车”从上一帧认到这一帧

目标跟踪在这里不需要高大上的算法。对低密度车流，最近邻匹配就够用：每个当前帧的质心，找上一帧里距离最近的质心，距离小于阈值就认为是同一辆车。这套逻辑简洁可控，出了问题也容易排查。

MAX_DIST = 80 # 匹配距离阈值，单位像素 tracks = [] # 每个元素: {'centroid': (cx, cy), 'counted': False} total_count = 0 for det in detections: cx, cy = det['centroid'] best_track = None best_dist = float('inf') # 在已有轨迹里找最近的质心 for tr in tracks: prev_cx, prev_cy = tr['centroid'] dist = (cx - prev_cx) ** 2 + (cy - prev_cy) ** 2 if dist < best_dist: best_dist = dist best_track = tr if best_track is not None and best_dist < MAX_DIST ** 2: prev_cy = best_track['centroid'][1] best_track['centroid'] = (cx, cy) # 更新到当前位置 # 跨线判定：上一帧在线之上，当前帧在线之下，算一次通过 if prev_cy < config.LINE_Y and cy >= config.LINE_Y: if not best_track['counted']: best_track['counted'] = True total_count += 1 else: # 没有匹配到任何已有轨迹，作为新目标加入 tracks.append({'centroid': (cx, cy), 'counted': False})

逻辑说明：这段代码的跨线判定只对“线上面到线下面”的方向计数。如果视频里双向行驶，需要再补一条从下往上的判断，或者用两根检测线分开统计。counted 标志是防重复计数的关键，一旦这辆车跨过线，后面就不再参与计数判断，但轨迹仍会继续更新，直到驶出 ROI。

参数说明：MAX_DIST 要跟 skip_frames 联动。skip_frames=2 时，一帧实际对应视频里 3 帧的时间，车速快的车辆质心位移可能达到 60 到 100 像素，MAX_DIST 设 40 就会频繁丢匹配，跟踪变成频繁新建轨迹。我一般用“车辆在画面里的像素速度 × 跳帧间隔 × 2”估算，给跟踪留出余量。

4.4 参数联动：history、varThreshold、min_area 与检测线怎么配合

参数不是孤立调出来的，它们互相牵制。给一组我常用的起点组合，以及对应的场景特征。

为什么傍晚要缩短 history？因为光线在几十秒内持续变暗，背景模型若引用太多旧帧，会把“变暗后的路面”误判成前景；history 短一点，背景能更快跟上光照变化。夜间车灯造成的眩光会让轮廓面积暴增，MIN_AREA 必须调大，否则一辆车会被灯光扩散光晕拆成两三个目标。

检测线位置也遵循一个逻辑：光照差、目标不稳定时，把线放在 ROI 中上部，让车辆在较小、较清晰的状态下完成计数；光照好时放到中线甚至偏下，利用更大的轮廓做稳定匹配。这种“按场景调组合”的做法，比单独试探每个参数收敛快得多。

5. 避坑与常见问题排查：五个真实踩坑记录与修复方案

5.1 ModuleNotFoundError: No module named 'cv2'：解释器没对齐

现象：pip install opencv-python 显示安装成功，运行代码却报 No module named 'cv2'。

原因：几乎所有新人都会踩。pip 装到了系统 Python，而 VSCode 或 IDE 用的是虚拟环境里的 Python，两个路径完全隔离；或者反过来，虚拟环境里装了包，终端却用全局 Python 跑脚本。

解决：先确认当前解释器的实际路径，再定向安装。

# 查看当前 Python 解释器路径 which python # macOS / Linux where python # Windows # 直接在虚拟环境里安装 pip install opencv-python numpy python -c "import cv2; print(cv2.__version__)"

只要输出的路径和 VSCode 状态栏选择的解释器是同一个，问题就消失。检查顺序：先 where，再装，最后验证 import，三步就够了。

5.2 findContours 与 contourArea 的版本差异：3.x 和 4.x 返回值不一样

现象：findContours 报错 “takes 2 positional arguments but 3 were given”，或者 contourArea 提示未定义标识符。

原因：OpenCV 4.x 把 findContours 的返回值从三个改成两个，网上大量老教程还在用 image, contours, hierarchy = cv2.findContours(...) 的 3.x 写法。未定义标识符多半是函数名拼错，正确写法是 cv2.contourArea，不是多一个 u，也不是 cvtArea 之类的变形。

解决：

# OpenCV 4.x 标准写法 contours, hierarchy = cv2.findContours( fgmask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE ) # 如果还在用 3.x，需要接收三个返回值 # image, contours, hierarchy = cv2.findContours(fgmask, ...)

判断版本只需要一行：print(cv2.version)。显示 4.x 就用两变量写法，3.x 就加回 image，别两个都写。这个坑在老博客里反复出现，跑源码报错第一时间先看版本，而不是去改代码逻辑。

5.3 同一辆车被数了两次：跟踪丢失和检测线太宽

现象：一辆车正常通过，计数值却加了 2 甚至 3。

原因：最常见的是车辆在检测线附近减速，质心在上、下、上之间抖动，跨线判断被触发多次。另一个隐蔽原因是轮廓断裂，一辆车在前景掩码里碎成两块，两个质心各自建轨迹，一辆车被当成两辆车。

解决：一是给轨迹加 counted 状态并在计数后冻结（第 4.3 节代码已处理）；二是把跨线判断改成连续确认，要求连续两帧都位于线下方才算通过。轮廓断裂靠形态学膨胀补洞，膨胀迭代次数从 1 加到 2 到 3，观察 mask 里车身是否连成整块。

# 已计数的车不再参与后续匹配，直接跳过 if tr.get('counted', False): continue

膨胀次数不是越多越好，迭代 4 次以上会把相邻车道的车连成一个大目标，反而更难处理。以“车身完整但车道间仍有缝隙”为宜。

5.4 视频打不开或拉流中断：路径编码、解码器与重连机制

现象：cv2.VideoCapture('D:/测试视频/车流.mp4') 返回 False，改成英文路径就能读；或者接 RTSP 摄像头，跑五分钟画面卡死，read() 一直不返回。

原因：OpenCV 的 VideoCapture 对中文路径支持很差，底层调用系统 API，中文路径在不同平台上编码不一致。RTSP 拉流时网络抖动会导致解码缓存异常，VideoCapture 没有自动重连能力，卡住后 read() 一直阻塞。

解决：视频文件一律放到纯英文路径下，这是最省事的方案。RTSP 先用 ffmpeg 确认流是否健康，再进程序逻辑。

# 用 ffmpeg 验证 RTSP 流，能输出数据说明流本身没坏 ffmpeg -i "rtsp://192.168.1.64/stream" -t 10 -f null -

程序里对 read() 的结果做重试，失败时重建 VideoCapture 对象，比在卡死的通道上死等有效：

ret, frame = cap.read() if not ret: cap.release() cap = cv2.VideoCapture(video_source) ret, frame = cap.read()

这套兜底逻辑在摄像头偶尔断流的场景里很实用，能顶住大部分短时抖动。实时流还可以加上 cap.set(cv2.CAP_PROP_BUFFERSIZE, 1)，把缓冲降到最低，减少延迟累积。

5.5 帧率掉到个位数：全图处理是性能杀手

现象：1080p 视频跑起来只有 8 FPS，画面和慢放一样。

原因：MOG2 对每个像素做多高斯分布更新，1080p 全图等于每秒处理 200 多万个像素，CPU 直接打满。再加上全图 findContours 和画框，每一帧都在做无用功。

解决：三步走，第一步缩帧，第二步裁 ROI，第三步跳帧。

# 性能优化三板斧 frame = cv2.resize(frame, (960, 540), interpolation=cv2.INTER_AREA) # 只对 ROI 区域做背景减除 roi = frame[ROI_Y:ROI_Y + ROI_H, ROI_X:ROI_X + ROI_W] fgmask = bg_sub.apply(roi) # 每隔 N 帧处理一次，中间帧用质心线性插值 if frame_idx % skip_frames != 0: continue

调整顺序：先裁 ROI，再看帧率决定要不要缩帧，最后才考虑跳帧。三板斧上完，一般能从 8 FPS 拉到 20 FPS 以上，画面流畅度完全可用。缩帧时用 INTER_AREA 而不是 INTER_LINEAR，前者对缩小图像保留更多有效像素，轮廓边缘锯齿少。

6. 进阶：把 demo 变成可用系统的三个验证技巧

6.1 离线视频验证：先跑通再上实时流

实时相机调试最痛苦的是光照和天气不可控，参数调了半天一到黄昏全变。我现在的习惯是先拿一段固定视频离线跑，把计数结果存成 CSV 和标注视频，人工数一遍做对比，误差在 5% 以内再考虑接实时流。

python main.py --video test.mp4 --save-video output/result.mp4

比如人工数 87 辆，程序输出 84 辆，误差率 3.4%，说明参数组合可用；误差超过 10%，先回第 4 章调参数，而不是直接上现场。离线视频能复现同一场景反复调参，这是实时摄像头给不了的。

6.2 双线标定：用两根检测线确认方向

单向计数看不出错误是漏检还是多检。在 ROI 里放两根线，上线下线各计一次，理论上两线数值应接近。如果上线数值明显高于下线，说明目标在中间区域丢失严重，需要调 varThreshold 或膨胀参数；如果下线高于上线，则要检查跨线判定是不是重复触发。双线差值与单线绝对值的组合，比只看一个数更容易定位问题环节。

6.3 从质心最近邻升级到 Sort 跟踪

低密度车流用最近邻匹配没问题，一旦出现并排行驶、超车变道，最近邻会频繁交换 ID。升级方案是把 tracker 换成 Sort 算法：卡尔曼滤波预测下一帧位置，匈牙利算法做最优匹配。核心概念不复杂，但 ID 切换率会明显下降。升级后记得给轨迹加生命周期，连续 3 帧匹配不上就删除，避免僵尸轨迹占内存。自己写匹配逻辑的另一个好处是可以随时打印轨迹 ID 和质心位置，真正需要上追踪算法时心里有底。

当初我在路口架着笔记本直接用摄像头实况调参，光线一变整个背景模型崩掉，一下午参数全白调。从那以后我每次拿到新视频，都强制先离线跑三遍：一遍默认参数、一遍调小 varThreshold、一遍调大 MIN_AREA，把误差记下来再上实时测试。这套验证顺序，希望帮到你。

本文还有配套的精品资源，点击获取