简介这份PPT资料面向深度学习与视频分析方向的开发者、学生及工程实践者围绕Django与YOLOv8搭建实时跟踪与统计系统展开帮助读者理解从模型推理到前端展示的完整链路。内容涵盖YOLOv8在检测、分割、跟踪、姿态估计与分类上的能力演进Django Channel与ASGI的异步通信机制WebSocket全双工传输以及SORT、deepSORT目标跟踪与计数算法并给出视频流处理、消息队列、前后端解耦的系统架构思路。资源包为1个pptx文件约28.76MB以图文幻灯片形式组织适合作为技术分享、课程汇报或项目方案参考。目前已有1028人学习读者可借此快速建立实时跟踪统计系统的整体认知理解关键组件选型与协作方式为后续工程落地提供可借鉴的架构与算法思路。1. 从一份答辩 PPT 说起Django 接住 YOLOv8 的实时跟踪与统计到底在做什么很多人第一次看到「基于 Django YOLOv8 搭建实时跟踪与统计系统」这个题目会以为它是个课程作业式的拼装项目前端传视频、后端跑模型、页面显示结果。真上手才发现难点根本不在 YOLOv8 推理本身而在「实时」两个字——视频帧怎么从浏览器到 Django、推理结果怎么带目标 ID 回传、统计数字怎么在多人多目标场景下不重复计数。这套系统要解决的核心问题是把 YOLOv8 的检测与跟踪能力包装成一个能通过浏览器访问、能持续统计进出/停留目标的 Web 服务。它适合有 Python 基础、想从「跑通 demo」跨到「能交付的系统」的开发者也适合需要做客流统计、区域入侵告警、车辆计数这类落地场景的工程师。下面按我实际搭过一遍的顺序把选型、代码、参数和翻车点讲清楚。2. 技术选型与整体链路为什么是 Django YOLOv8 而不是 Flask 裸推理2.1 三个组件的分工与不可替代性先把链路拆开看。YOLOv8 负责单帧的目标检测输出每个目标的边界框和类别跟踪算法负责给跨帧的同一个目标分配稳定 IDDjango 负责接收视频流、调度推理、把带 ID 的结果推回前端并维护统计数据。三者缺一不可但职责边界必须划清否则后期改一处崩三处。选 Django 而不是 Flask主要原因是这个系统天然需要 ORM、用户会话、后台管理和多路由。统计结果要落库、要按时间段查询、要能导出Django 的 ORM 和 admin 能省掉大量重复代码。YOLOv8 这边Ultralytics 官方库已经把检测和跟踪封装得很完整model.track()一行就能同时拿到检测框和跟踪 ID没必要自己再拼 ByteTrack 或 BoT-SORT。常见做法是检测用 YOLOv8n 或 YOLOv8s 做速度优先跟踪用内置的 ByteTrack统计逻辑自己写在 Django 的视图或独立服务里。需要提前想清楚的是推理进程和 Web 进程的关系。Django 的请求-响应模型不适合在视图里同步跑一个持续的视频流推理会把 worker 占死。我一般会把推理做成一个独立的后台线程或独立进程Django 只负责通过队列或共享内存拿结果。这一点在选型阶段就要定不然后面重构成本很高。2.2 最小可运行链路的搭建步骤第一步建 Django 项目和 app。命令很标准但要注意目录结构模型文件和推理代码不要塞进 app 目录里单独放一个inference包方便后面拆服务。django-admin startproject trackstats cd trackstats python manage.py startapp core第二步装依赖。Ultralytics 会连带装 torch如果机器有 NVIDIA 显卡先确认 CUDA 版本再装否则会默认装 CPU 版推理速度差一个数量级。pip install django ultralytics opencv-python # 有显卡时确认 torch 是 cu 版本 python -c import torch; print(torch.cuda.is_available())第三步写一个最小的推理封装把检测和跟踪合到一起。这里用生成器逐帧产出结果方便后面接视频流或摄像头。from ultralytics import YOLO # 加载模型n 版速度优先s 版精度略高 model YOLO(yolov8n.pt) def track_frames(frame): # persistTrue 让跟踪器在连续帧之间保持 ID results model.track(frame, persistTrue, trackerbytetrack.yaml, verboseFalse) boxes results[0].boxes detections [] if boxes.id is not None: for box, tid, cls, conf in zip(boxes.xyxy, boxes.id, boxes.cls, boxes.conf): detections.append({ bbox: box.tolist(), track_id: int(tid), class_id: int(cls), confidence: float(conf), }) return detections这段代码的关键在persistTrue它决定跟踪器是否在帧间保留状态。如果每帧都新建跟踪器ID 会乱跳统计必然重复计数。tracker参数指定跟踪配置文件ByteTrack 在人群场景下比默认配置稳。verboseFalse是为了避免每帧刷日志拖慢速度。返回结构里boxes.id在没检测到目标时是 None必须判空否则直接报错。2.3 统计逻辑该放在哪一层统计不是简单累加检测框数量。真实场景里同一个目标会在画面里停留很多帧直接数框会把一个人算成几百次。正确做法是基于 track_id 做去重维护一个已见 ID 集合新 ID 出现时计数加一ID 消失超过一定帧数后从活跃集合移除。如果是进出统计还要配合一条虚拟线或一个区域判断目标轨迹是否穿越。我一般把统计状态放在一个独立的Tracker类里和 Django 的模型解耦。这样单元测试好写也方便换成 Redis 存状态做多进程。Django 侧只负责把统计结果写进数据库字段至少要有时间戳、区域名、进入数、离开数、当前停留数。查询和展示直接用 ORM 聚合不用在 Python 里再算一遍。3. 把 YOLOv8 推理接进 Django视图、线程与视频流的三种接法3.1 三种接法的适用场景与取舍第一种是上传视频文件后离线处理最简单适合做统计报表但不满足「实时」。第二种是浏览器通过 WebSocket 推帧Django Channels 接收后推理再推回延迟能压到几百毫秒适合演示和轻量场景。第三种是服务端直接读 RTSP 或摄像头推理结果通过 WebSocket 广播给前端这是最接近生产环境的做法也是我实际项目里用得最多的。选哪种取决于你的「实时」定义。如果是秒级更新统计数字第二种够用如果要画面和框同步、延迟低于 500ms必须走第三种并且要把推理和 Web 服务分开部署。下面重点讲第三种因为它踩的坑最多学会了前两种自然能降级实现。3.2 用独立线程跑推理并推送到 Channels先配 Channels。在settings.py里注册并指定 ASGI 应用。注意channels_redis作为通道层单机测试也可以用内存通道层但多 worker 时必须用 Redis。# settings.py INSTALLED_APPS [ daphne, channels, core, # ... ] ASGI_APPLICATION trackstats.asgi.application CHANNEL_LAYERS { default: { BACKEND: channels_redis.core.RedisChannelLayer, CONFIG: {hosts: [(127.0.0.1, 6379)]}, }, }然后写一个消费者负责把推理线程的结果转发给前端。消费者本身不跑模型只做消息中转这样 Web 进程不会被推理阻塞。# core/consumers.py import json from channels.generic.websocket import AsyncWebsocketConsumer class TrackConsumer(AsyncWebsocketConsumer): async def connect(self): self.group_name track await self.channel_layer.group_add(self.group_name, self.channel_name) await self.accept() async def disconnect(self, code): await self.channel_layer.group_discard(self.group_name, self.channel_name) async def track_message(self, event): # 把推理线程发来的结果原样推给浏览器 await self.send(text_datajson.dumps(event[data]))推理线程通过async_to_sync(channel_layer.group_send)把每帧结果发到这个组。这里有个容易翻车的点group_send是异步的在同步线程里必须用async_to_sync包一层否则报 event loop 错误。另外消息体不要塞整帧图像只传框坐标、ID 和类别图像走单独的 MJPEG 流或前端 canvas 绘制否则 WebSocket 带宽会被打满。3.3 视频读取与帧率控制的关键参数服务端读流用 OpenCV但cv2.VideoCapture默认会缓冲导致延迟越积越大。必须设置缓冲区大小为 1并考虑跳帧。下面这段是推理线程的主循环。import cv2 import time from inference.tracker import track_frames, StatsTracker cap cv2.VideoCapture(rtsp://your_stream_url) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) # 关键避免缓冲堆积 tracker StatsTracker() last_push 0 while True: ok, frame cap.read() if not ok: break detections track_frames(frame) stats tracker.update(detections) now time.time() # 限制推送频率避免前端渲染跟不上 if now - last_push 0.1: push_to_channels({detections: detections, stats: stats}) last_push nowCAP_PROP_BUFFERSIZE设成 1 是血泪经验不设的话延迟会从几百毫秒涨到几秒。推送频率限制在 10fps 左右前端渲染足够也能给推理留出余量。如果显卡是 GTX1660Ti 这类中端卡YOLOv8n 在 640 输入下大概能跑到 60fps 以上瓶颈通常在解码和网络不在模型。RK3588 这类边缘设备部署时要用它的 NPU 加速Ultralytics 官方对 RKNN 的支持需要额外转换模型输入尺寸和量化方式都会影响精度建议先用 640 输入、INT8 量化跑通再调。4. 跟踪 ID 与统计准确性避坑与常见问题排查4.1 ID 跳变导致重复计数现象统计数字比实际人数多出好几倍日志里同一个目标短时间内出现多个不同 track_id。原因通常是跟踪器在帧间没保持状态或者检测框抖动太大导致匹配失败。解决方法是确认persistTrue已设置适当调大跟踪器的track_high_thresh和track_buffer并在检测前做一次尺寸归一化避免输入分辨率频繁变化。如果目标遮挡严重ByteTrack 也会断 ID这时要接受一定误差或在业务层用轨迹相似度做合并。4.2 推理线程把 Django worker 占满现象页面打开几个后整个服务无响应CPU 跑满。原因是把推理放在了视图函数里同步执行。解决方法是把推理移到独立进程或线程Django 只做消息中转。用 Channels 时注意 daphne 的 worker 数量推理线程不要开太多一个 GPU 上并行跑多个模型实例反而会互相抢显存速度更慢。4.3 视频流延迟越跑越大现象画面比实时慢好几秒且随时间增加。原因就是前面说的缓冲区堆积。除了设BUFFERSIZE1还要在循环里主动丢弃旧帧只处理最新帧。如果流本身码率高考虑在服务端转码降分辨率或者让前端只拉低码率子流。4.4 统计数字落库后对不上现象页面显示的实时数字和数据库查询结果不一致。原因是统计状态在内存里落库有延迟或批量写入丢数据。解决方法是把统计更新做成幂等的按时间窗口聚合后再写库或者直接用 Redis 做实时计数、定时同步到数据库。查询时以数据库为准实时数字只做展示。4.5 模型加载慢或首次推理卡顿现象服务启动后第一次请求要等好几秒。原因是模型权重在首次调用时才加载。解决方法是在 Django 启动时预加载模型放到一个全局单例里或者用AppConfig.ready()里初始化。注意别在ready()里做重推理只加载权重即可。5. 让统计更准的两个进阶技巧区域判定与轨迹平滑5.1 用多边形区域替代整帧计数整帧计数只能告诉你画面里有几个目标业务上往往需要知道「进入某个区域」的数量。做法是定义一个多边形区域判断目标框的中心点是否落在区域内再结合 track_id 的首次进入和离开事件来计数。下面是一个判断点是否在多边形内的实现配合matplotlib.path最省事。from matplotlib.path import Path def in_region(center, polygon): # polygon 是 [(x1,y1), (x2,y2), ...] return Path(polygon).contains_point(center) def update_region_stats(tracker, detections, polygon): for det in detections: x1, y1, x2, y2 det[bbox] center ((x1 x2) / 2, (y1 y2) / 2) tid det[track_id] if in_region(center, polygon): tracker.mark_enter(tid) else: tracker.mark_leave(tid)mark_enter和mark_leave内部用集合去重同一个 ID 只记一次进入。区域坐标建议做成可配置存在数据库里前端画框后保存避免硬编码。多边形顶点顺序要统一顺时针或逆时针都行但别混用否则判定会出错。5.2 轨迹平滑减少 ID 抖动检测框逐帧抖动会让中心点反复穿越区域边界导致进入/离开事件误触发。简单有效的办法是对中心点做滑动平均窗口取 5 到 10 帧。代价是引入一点延迟但对统计准确性提升明显。如果目标移动快窗口取小一点目标移动慢窗口可以大一点。这个参数没有标准值我一般先在测试视频上跑一遍看事件触发次数和人工计数差多少再微调。5.3 验证统计准确性的土办法别迷信模型指标统计系统的准确性要用业务口径验证。我的习惯是录一段有明确人数的测试视频人工数一遍然后跑系统对比。重点看三个数总进入数、总离开数、峰值停留数。如果进入和离开差很多说明 ID 合并或丢失严重如果峰值停留数偏高说明去重没做好。这个对比表比任何 mAP 都直观。指标人工计数系统输出偏差容忍总进入数5048±2总离开数5047±3峰值停留1213±1偏差在容忍范围内就可以上线超出就回去查跟踪参数和区域判定。这套系统值不值得做取决于你的场景对统计精度的要求。如果只是看趋势YOLOv8n 加 ByteTrack 足够如果要精确到个位数就得在跟踪算法和区域逻辑上多花时间甚至考虑换更重的模型或加 ReID。我自己踩过的最大坑是过早优化模型后来发现瓶颈全在视频读取和 ID 去重上。先把链路跑通再拿真实视频调参数比一上来就换模型有效得多。希望帮到你。本文还有配套的精品资源点击获取 Django + YOLOv8 实时跟踪与统计系统实战：从选型到避坑
简介这份PPT资料面向深度学习与视频分析方向的开发者、学生及工程实践者围绕Django与YOLOv8搭建实时跟踪与统计系统展开帮助读者理解从模型推理到前端展示的完整链路。内容涵盖YOLOv8在检测、分割、跟踪、姿态估计与分类上的能力演进Django Channel与ASGI的异步通信机制WebSocket全双工传输以及SORT、deepSORT目标跟踪与计数算法并给出视频流处理、消息队列、前后端解耦的系统架构思路。资源包为1个pptx文件约28.76MB以图文幻灯片形式组织适合作为技术分享、课程汇报或项目方案参考。目前已有1028人学习读者可借此快速建立实时跟踪统计系统的整体认知理解关键组件选型与协作方式为后续工程落地提供可借鉴的架构与算法思路。1. 从一份答辩 PPT 说起Django 接住 YOLOv8 的实时跟踪与统计到底在做什么很多人第一次看到「基于 Django YOLOv8 搭建实时跟踪与统计系统」这个题目会以为它是个课程作业式的拼装项目前端传视频、后端跑模型、页面显示结果。真上手才发现难点根本不在 YOLOv8 推理本身而在「实时」两个字——视频帧怎么从浏览器到 Django、推理结果怎么带目标 ID 回传、统计数字怎么在多人多目标场景下不重复计数。这套系统要解决的核心问题是把 YOLOv8 的检测与跟踪能力包装成一个能通过浏览器访问、能持续统计进出/停留目标的 Web 服务。它适合有 Python 基础、想从「跑通 demo」跨到「能交付的系统」的开发者也适合需要做客流统计、区域入侵告警、车辆计数这类落地场景的工程师。下面按我实际搭过一遍的顺序把选型、代码、参数和翻车点讲清楚。2. 技术选型与整体链路为什么是 Django YOLOv8 而不是 Flask 裸推理2.1 三个组件的分工与不可替代性先把链路拆开看。YOLOv8 负责单帧的目标检测输出每个目标的边界框和类别跟踪算法负责给跨帧的同一个目标分配稳定 IDDjango 负责接收视频流、调度推理、把带 ID 的结果推回前端并维护统计数据。三者缺一不可但职责边界必须划清否则后期改一处崩三处。选 Django 而不是 Flask主要原因是这个系统天然需要 ORM、用户会话、后台管理和多路由。统计结果要落库、要按时间段查询、要能导出Django 的 ORM 和 admin 能省掉大量重复代码。YOLOv8 这边Ultralytics 官方库已经把检测和跟踪封装得很完整model.track()一行就能同时拿到检测框和跟踪 ID没必要自己再拼 ByteTrack 或 BoT-SORT。常见做法是检测用 YOLOv8n 或 YOLOv8s 做速度优先跟踪用内置的 ByteTrack统计逻辑自己写在 Django 的视图或独立服务里。需要提前想清楚的是推理进程和 Web 进程的关系。Django 的请求-响应模型不适合在视图里同步跑一个持续的视频流推理会把 worker 占死。我一般会把推理做成一个独立的后台线程或独立进程Django 只负责通过队列或共享内存拿结果。这一点在选型阶段就要定不然后面重构成本很高。2.2 最小可运行链路的搭建步骤第一步建 Django 项目和 app。命令很标准但要注意目录结构模型文件和推理代码不要塞进 app 目录里单独放一个inference包方便后面拆服务。django-admin startproject trackstats cd trackstats python manage.py startapp core第二步装依赖。Ultralytics 会连带装 torch如果机器有 NVIDIA 显卡先确认 CUDA 版本再装否则会默认装 CPU 版推理速度差一个数量级。pip install django ultralytics opencv-python # 有显卡时确认 torch 是 cu 版本 python -c import torch; print(torch.cuda.is_available())第三步写一个最小的推理封装把检测和跟踪合到一起。这里用生成器逐帧产出结果方便后面接视频流或摄像头。from ultralytics import YOLO # 加载模型n 版速度优先s 版精度略高 model YOLO(yolov8n.pt) def track_frames(frame): # persistTrue 让跟踪器在连续帧之间保持 ID results model.track(frame, persistTrue, trackerbytetrack.yaml, verboseFalse) boxes results[0].boxes detections [] if boxes.id is not None: for box, tid, cls, conf in zip(boxes.xyxy, boxes.id, boxes.cls, boxes.conf): detections.append({ bbox: box.tolist(), track_id: int(tid), class_id: int(cls), confidence: float(conf), }) return detections这段代码的关键在persistTrue它决定跟踪器是否在帧间保留状态。如果每帧都新建跟踪器ID 会乱跳统计必然重复计数。tracker参数指定跟踪配置文件ByteTrack 在人群场景下比默认配置稳。verboseFalse是为了避免每帧刷日志拖慢速度。返回结构里boxes.id在没检测到目标时是 None必须判空否则直接报错。2.3 统计逻辑该放在哪一层统计不是简单累加检测框数量。真实场景里同一个目标会在画面里停留很多帧直接数框会把一个人算成几百次。正确做法是基于 track_id 做去重维护一个已见 ID 集合新 ID 出现时计数加一ID 消失超过一定帧数后从活跃集合移除。如果是进出统计还要配合一条虚拟线或一个区域判断目标轨迹是否穿越。我一般把统计状态放在一个独立的Tracker类里和 Django 的模型解耦。这样单元测试好写也方便换成 Redis 存状态做多进程。Django 侧只负责把统计结果写进数据库字段至少要有时间戳、区域名、进入数、离开数、当前停留数。查询和展示直接用 ORM 聚合不用在 Python 里再算一遍。3. 把 YOLOv8 推理接进 Django视图、线程与视频流的三种接法3.1 三种接法的适用场景与取舍第一种是上传视频文件后离线处理最简单适合做统计报表但不满足「实时」。第二种是浏览器通过 WebSocket 推帧Django Channels 接收后推理再推回延迟能压到几百毫秒适合演示和轻量场景。第三种是服务端直接读 RTSP 或摄像头推理结果通过 WebSocket 广播给前端这是最接近生产环境的做法也是我实际项目里用得最多的。选哪种取决于你的「实时」定义。如果是秒级更新统计数字第二种够用如果要画面和框同步、延迟低于 500ms必须走第三种并且要把推理和 Web 服务分开部署。下面重点讲第三种因为它踩的坑最多学会了前两种自然能降级实现。3.2 用独立线程跑推理并推送到 Channels先配 Channels。在settings.py里注册并指定 ASGI 应用。注意channels_redis作为通道层单机测试也可以用内存通道层但多 worker 时必须用 Redis。# settings.py INSTALLED_APPS [ daphne, channels, core, # ... ] ASGI_APPLICATION trackstats.asgi.application CHANNEL_LAYERS { default: { BACKEND: channels_redis.core.RedisChannelLayer, CONFIG: {hosts: [(127.0.0.1, 6379)]}, }, }然后写一个消费者负责把推理线程的结果转发给前端。消费者本身不跑模型只做消息中转这样 Web 进程不会被推理阻塞。# core/consumers.py import json from channels.generic.websocket import AsyncWebsocketConsumer class TrackConsumer(AsyncWebsocketConsumer): async def connect(self): self.group_name track await self.channel_layer.group_add(self.group_name, self.channel_name) await self.accept() async def disconnect(self, code): await self.channel_layer.group_discard(self.group_name, self.channel_name) async def track_message(self, event): # 把推理线程发来的结果原样推给浏览器 await self.send(text_datajson.dumps(event[data]))推理线程通过async_to_sync(channel_layer.group_send)把每帧结果发到这个组。这里有个容易翻车的点group_send是异步的在同步线程里必须用async_to_sync包一层否则报 event loop 错误。另外消息体不要塞整帧图像只传框坐标、ID 和类别图像走单独的 MJPEG 流或前端 canvas 绘制否则 WebSocket 带宽会被打满。3.3 视频读取与帧率控制的关键参数服务端读流用 OpenCV但cv2.VideoCapture默认会缓冲导致延迟越积越大。必须设置缓冲区大小为 1并考虑跳帧。下面这段是推理线程的主循环。import cv2 import time from inference.tracker import track_frames, StatsTracker cap cv2.VideoCapture(rtsp://your_stream_url) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) # 关键避免缓冲堆积 tracker StatsTracker() last_push 0 while True: ok, frame cap.read() if not ok: break detections track_frames(frame) stats tracker.update(detections) now time.time() # 限制推送频率避免前端渲染跟不上 if now - last_push 0.1: push_to_channels({detections: detections, stats: stats}) last_push nowCAP_PROP_BUFFERSIZE设成 1 是血泪经验不设的话延迟会从几百毫秒涨到几秒。推送频率限制在 10fps 左右前端渲染足够也能给推理留出余量。如果显卡是 GTX1660Ti 这类中端卡YOLOv8n 在 640 输入下大概能跑到 60fps 以上瓶颈通常在解码和网络不在模型。RK3588 这类边缘设备部署时要用它的 NPU 加速Ultralytics 官方对 RKNN 的支持需要额外转换模型输入尺寸和量化方式都会影响精度建议先用 640 输入、INT8 量化跑通再调。4. 跟踪 ID 与统计准确性避坑与常见问题排查4.1 ID 跳变导致重复计数现象统计数字比实际人数多出好几倍日志里同一个目标短时间内出现多个不同 track_id。原因通常是跟踪器在帧间没保持状态或者检测框抖动太大导致匹配失败。解决方法是确认persistTrue已设置适当调大跟踪器的track_high_thresh和track_buffer并在检测前做一次尺寸归一化避免输入分辨率频繁变化。如果目标遮挡严重ByteTrack 也会断 ID这时要接受一定误差或在业务层用轨迹相似度做合并。4.2 推理线程把 Django worker 占满现象页面打开几个后整个服务无响应CPU 跑满。原因是把推理放在了视图函数里同步执行。解决方法是把推理移到独立进程或线程Django 只做消息中转。用 Channels 时注意 daphne 的 worker 数量推理线程不要开太多一个 GPU 上并行跑多个模型实例反而会互相抢显存速度更慢。4.3 视频流延迟越跑越大现象画面比实时慢好几秒且随时间增加。原因就是前面说的缓冲区堆积。除了设BUFFERSIZE1还要在循环里主动丢弃旧帧只处理最新帧。如果流本身码率高考虑在服务端转码降分辨率或者让前端只拉低码率子流。4.4 统计数字落库后对不上现象页面显示的实时数字和数据库查询结果不一致。原因是统计状态在内存里落库有延迟或批量写入丢数据。解决方法是把统计更新做成幂等的按时间窗口聚合后再写库或者直接用 Redis 做实时计数、定时同步到数据库。查询时以数据库为准实时数字只做展示。4.5 模型加载慢或首次推理卡顿现象服务启动后第一次请求要等好几秒。原因是模型权重在首次调用时才加载。解决方法是在 Django 启动时预加载模型放到一个全局单例里或者用AppConfig.ready()里初始化。注意别在ready()里做重推理只加载权重即可。5. 让统计更准的两个进阶技巧区域判定与轨迹平滑5.1 用多边形区域替代整帧计数整帧计数只能告诉你画面里有几个目标业务上往往需要知道「进入某个区域」的数量。做法是定义一个多边形区域判断目标框的中心点是否落在区域内再结合 track_id 的首次进入和离开事件来计数。下面是一个判断点是否在多边形内的实现配合matplotlib.path最省事。from matplotlib.path import Path def in_region(center, polygon): # polygon 是 [(x1,y1), (x2,y2), ...] return Path(polygon).contains_point(center) def update_region_stats(tracker, detections, polygon): for det in detections: x1, y1, x2, y2 det[bbox] center ((x1 x2) / 2, (y1 y2) / 2) tid det[track_id] if in_region(center, polygon): tracker.mark_enter(tid) else: tracker.mark_leave(tid)mark_enter和mark_leave内部用集合去重同一个 ID 只记一次进入。区域坐标建议做成可配置存在数据库里前端画框后保存避免硬编码。多边形顶点顺序要统一顺时针或逆时针都行但别混用否则判定会出错。5.2 轨迹平滑减少 ID 抖动检测框逐帧抖动会让中心点反复穿越区域边界导致进入/离开事件误触发。简单有效的办法是对中心点做滑动平均窗口取 5 到 10 帧。代价是引入一点延迟但对统计准确性提升明显。如果目标移动快窗口取小一点目标移动慢窗口可以大一点。这个参数没有标准值我一般先在测试视频上跑一遍看事件触发次数和人工计数差多少再微调。5.3 验证统计准确性的土办法别迷信模型指标统计系统的准确性要用业务口径验证。我的习惯是录一段有明确人数的测试视频人工数一遍然后跑系统对比。重点看三个数总进入数、总离开数、峰值停留数。如果进入和离开差很多说明 ID 合并或丢失严重如果峰值停留数偏高说明去重没做好。这个对比表比任何 mAP 都直观。指标人工计数系统输出偏差容忍总进入数5048±2总离开数5047±3峰值停留1213±1偏差在容忍范围内就可以上线超出就回去查跟踪参数和区域判定。这套系统值不值得做取决于你的场景对统计精度的要求。如果只是看趋势YOLOv8n 加 ByteTrack 足够如果要精确到个位数就得在跟踪算法和区域逻辑上多花时间甚至考虑换更重的模型或加 ReID。我自己踩过的最大坑是过早优化模型后来发现瓶颈全在视频读取和 ID 去重上。先把链路跑通再拿真实视频调参数比一上来就换模型有效得多。希望帮到你。本文还有配套的精品资源点击获取