客流统计系统实战：从检测→跟踪→计数的完整工程实现

一、问题定义（工程视角）

客流统计不是“数人头”，而是一个典型的多目标检测 + 跟踪 + 事件触发问题。

核心链路：

Video → Detection → Tracking → ROI → Line Crossing → Filter → Output

目标很明确：

• 同一目标只计数一次
• 区分进 / 出方向
• 在遮挡、逆光、人群密集情况下保持稳定

二、系统架构（实际项目版本）

Camera → Edge Device → Inference → Tracking → Counting → API / Server

模块拆解：

1. 输入（Camera）

• 分辨率：720p / 1080p
• 帧率：15–25 FPS

2. 边缘推理（Edge）

• 模型：YOLOv8n（轻量） / YOLOv8s（平衡）
• 推理方式：ONNX / TensorRT

3. 跟踪（Tracking）

• ByteTrack（实际项目更稳定）

4. 计数逻辑

• 虚拟线 + 方向判断

5. 输出

• 实时计数 + 分时数据

三、核心实现流程（带代码思路）

1️⃣ ROI裁剪（必须做）

实际不会对整帧做检测：

roi = frame[y1:y2, x1:x2]

作用：

• 降低计算量（约30%+）
• 减少误检

2️⃣ 帧率控制（降算力关键）

if frame_id % 2 != 0:
    continue

说明：

• 实际推理帧率：15 FPS → 7~8 FPS
• 对统计影响不大，但算力下降明显

3️⃣ 检测 + 跟踪

detections = model(roi)
tracks = tracker.update(detections)

关键点：

• 检测负责“找人”
• 跟踪负责“保持ID一致”

4️⃣ 计数逻辑（核心）

if track.cross(line):
    if track.direction == "in":
        in_count += 1
    else:
        out_count += 1

四、关键优化点（决定能不能用）

1️⃣ 抖动过滤（必须）

问题：人在边界晃动 → 被重复计数

if abs(curr_y - prev_y) < threshold:
    ignore = True

2️⃣ 多帧方向判断（避免误判）

不要用单帧判断：

direction = sum(last_n_frames) / n

3️⃣ 去重窗口（防爆数据）

if current_time - last_count_time < 3:
    ignore = True

4️⃣ ROI + 计数线组合

常见错误：

❌ 全画面检测 + 单线 ✅ ROI限制 + 双线缓冲区

五、实际性能参数（项目参考）

六、常见误差来源（真实踩坑）

1️⃣ 双人并排通过

现象： 👉 2个人 → 统计1个

原因：

• 检测框重叠
• 跟踪ID合并

2️⃣ 边界反复横跳

现象： 👉 同一个人被统计3次

原因：

• 没有抖动过滤

3️⃣ 小孩 / 低身高漏检

原因：

• 检测模型偏向成人
• 安装高度不合理

4️⃣ 强光 / 玻璃反射

现象： 👉 人消失 or 检测失败

5️⃣ 员工频繁进出

现象： 👉 数据严重偏高

解决：

• 白名单
• 高频行为过滤

七、性能 vs 精度取舍

优化建议：

• 边缘设备 → n / s
• 服务器 → m / l

八、系统瓶颈分析

实际项目瓶颈通常在：

• 推理（GPU / NPU）
• 多路视频并发
• 带宽传输

优化方向：

• 多线程
• 批处理
• 模型量化

九、数据结构（实际可用）

{
  "timestamp": "2026-03-17T10:00:00",
  "device_id": "cam_01",
  "in_count": 125,
  "out_count": 118,
  "confidence": 0.94
}

补充建议：

• 加时间窗口统计
• 加异常过滤（突增/突降）

十、总结（工程结论）

客流统计能不能用，关键看三点：

• 检测是否稳定
• 跟踪是否连续
• 计数逻辑是否抗干扰

实际问题大多出在：

👉 边界处理 + 轨迹判断 + 去重策略

而不是模型本身。

（建议你一定保留这一段）

如果你做过类似项目，应该会有同感：

👉 真正难的不是“把人检测出来” 👉 而是“在复杂场景下只数一次”