客流统计系统最早的实现方式比较简单，本质就是"穿线计数"。
在实际项目里，一般是摄像头画一条虚拟线，目标穿过就+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）
复杂度主要不在模型，而在现场环境的不确定性。