客流统计系统的工程实现：从线穿越计数到多目标跟踪

客流统计系统最早的实现方式比较简单本质就是“穿线计数”。在实际项目里一般是摄像头画一条虚拟线目标穿过就1。检测 → 穿线判断 → 1计数 → 上报这种方式在单入口、低密度场景基本没问题但一旦进入商场或展馆环境问题会很明显。1. 误差来源现场最常见的几个问题人流折返导致重复计数多人遮挡导致漏检逆光区域检测失败入口双向流动穿线混乱特别是在午高峰人群密度上来以后穿线逻辑会明显失真。2. 引入多目标跟踪MOT后面项目里开始引入多目标跟踪。基本链路变成YOLO检测 → ByteTrack / DeepSORT → 轨迹生成 → 穿线逻辑这一层的关键变化是不是每一帧都计数而是先形成 track再做事件判断。3. ReID在实际中的问题理论上加了ReID embedding后可以做去重但实际效果不稳定拥挤场景ID Switch频繁光照变化导致特征漂移远距离目标embedding区分度下降在某些展馆场景ID Switch率甚至能到10%。4. 去重逻辑工程实现实际项目里不会完全依赖模型而是加规则if (track_id匹配 时间窗口ΔT 空间区域相近): 认为是同一人 else: 新客流通常会加一个滑动窗口做修正。5. 多摄像头场景多入口商场会遇到一个更麻烦的问题同一个人跨摄像头重复计数。这时候需要做跨设备关联但现实里时间同步误差1~3s很常见网络延迟导致轨迹断裂ID无法稳定继承所以很多项目最后是“弱融合”而不是强ReID全局统一。6. 实际效果上线后的指标大致是低密度场景误差3%~5%高密度场景误差5%~10%拥挤展馆偶尔超过10%但相比纯穿线模型稳定性已经提升很多。7. 总结客流统计系统从工程角度看本质是三个问题检测Detection跟踪Tracking事件判断Event复杂度主要不在模型而在现场环境的不确定性。