从零构建拥挤场景人头检测系统：YOLOv5/v8/v10训练与部署实战

做过头检测的人都知道，真正难的不是把 YOLO 跑通，而是把它用在拥挤场景里还不出问题。站台上、商场出入口、展会现场，人一多，画面里就是一片人头，框叠框、目标小、互相遮挡，随便挑一个都能让模型漏检漏到怀疑人生。而现实需求恰恰就集中在这些地方——客流统计、区域拥挤预警、安全疏散调度，都需要在人群里准确数出“有多少人”。

这篇博文想跟你完整聊一次这样的项目：如何从零构建一个基于 YOLOv5/v8/v10 的人头检测系统，覆盖数据集构建、模型训练、推理优化，再到带界面的 UI 系统集成。文章不适合完全零基础的人读概念，更适合已经会跑 YOLO、但想往工程化落地的方向走的朋友。我会把项目里踩过的坑、反复调过的参数、以及最后真正能用的方案都摊开讲，尽量让你读完能直接复用到自己的场景里。

1. 项目定位与整体技术方案选型

1.1 拥挤场景人头检测的难点在哪

大多数人头检测项目翻车，翻的不是模型本身，而是对“拥挤”两个字没有足够敬畏。要知道，普通目标检测里的行人类、车辆类样本，主体面积大、特征完整，模型随便学学都能出框。但人头检测面对的是完全不同的分布。

先说尺度问题。在商场俯视摄像头里，一个人头往往只有二三十像素，甚至不到十个像素。YOLO 默认输入是 640x640，特征图经过 5 次下采样后，最小特征图只有 20x20，一个 10x10 的目标映射上去连 1 个像素都不到，模型根本无从学起。其次是遮挡问题。拥挤场景里前排人头挡住后排，后排往往只露出一个头顶弧线，特征严重残缺。再叠加光照不均、发型颜色多样、帽子遮挡等干扰，检测器很容易把发髻当成人头，或者把两个紧挨着的人头合成一个框。

第三个难点是密度极度不均。画面里可能同时存在完全空旷的区域和高度拥挤的区域，模型在稀疏区域容易把背景误检成人头，在拥挤区域又容易漏检。这三个难点叠加在一起，就决定了你不能天真地把通用检测模型直接拿来用，必须从数据到训练到推理一步步针对“拥挤”重新设计。

1.2 为什么是 YOLOv5/v8/v10

既然要落地，模型选型就绕不开 YOLO 系列。在项目启动时我对比了 YOLOv5、v8、v10 三个版本，也分别做了完整的训练和推理测试，这里直接说结论。

我的建议很简单：如果追求最稳的训练体验和长期维护，用 YOLOv8；如果跑在边缘盒子或硬件性能吃紧的设备上，优先试 YOLOv10；如果团队之前用过 v5 积累过代码，继续用 v5 也没问题，v5 在小数据集上迁移学习往往比你想象中更抗打。

我在这次项目里的策略是，三个版本都保留训练和推理接口，但主力训练走 YOLOv8，最终线上部署实际用的是 YOLOv10 导出的 TensorRT 模型。原因很简单——拥挤场景需要更大分辨率输入，计算开销本来就高，v10 去掉 NMS 后单帧能省 10ms 左右的延迟，这部分在高并发业务里非常值钱。

1.3 系统整体框架

整个系统不能只是一个裸模型，我从一开始就把它拆成四条管线：数据管线、训练管线、推理服务、UI 展示层。

数据管线负责原始视频抽帧、人工标注、增强和数据集划分；训练管线负责 YOLO 模型的训练、验证、导出；推理服务封装模型加载、预处理、推理、后处理逻辑，供上层调用；UI 层则做成 PyQt5 桌面应用，支持本地图片、视频文件和摄像头实时流三种输入方式。这样做的好处是每一层都能独立测试，训练迭代时不用动推理代码，UI 改动也不会碰模型逻辑，整个链路里我调参会顺手很多。

整体技术栈就是 PyTorch + YOLOv5/v8/v10 + OpenCV + PyQt5。前三种处理模型和图像逻辑，PyQt5 负责界面。这套组合在 Windows 和 Linux 上都能跑，纯离线部署，完全不需要额外网络开销。

2. 数据集构建与标注

2.1 数据来源和采集规范

模型训练效果的底线，不是模型结构，而是数据。我一直跟人强调一个观念：当你觉得模型效果差的时候，先别改网络，回去看看数据里到底有什么、没有什么。

本次项目的数据来源分两块。第一块是公开的头部检测数据集和行人/人群数据集，这类公开学术数据集可以直接下载使用。第二块是自行采集的真实场景视频帧，我选了商场闸机口、地铁换乘通道、展会入口、学校食堂出入口等几个典型密集场景，把摄像头架在不同高度和角度录制，然后每隔固定间隔抽帧。自采数据质量参差不齐没关系，重点在于场景和摄像头视角要跟你真正部署的环境接近，这一步直接决定模型迁移后的表现。

采集时比较重要的规范有这几点：

• 覆盖不同时段：早晚高峰、平峰、夜间灯光场景都要有，人群密度呈现梯度变化。
• 覆盖不同拍摄角度：俯视、平视、倾斜视角各占一定比例，避免模型只认某一类视角。
• 覆盖人体姿态：站立、低头看手机、弯腰、奔跑、抱着小孩等都要标注，不能只标“标准正脸”。
• 注意隐私合规：自行采集视频不能带身份信息，处理完的图片不做公开分发，标注过程尽量模糊人脸敏感细节，只保留几何框用于计算。

最终我整理下来训练集大概有 2 万多张图，其中公开数据约占一半，自采数据占一半。如果你是个人项目，数据量达不到这个数量也没关系，先构建 3000-5000 张的种子集，把模型训到能看，再逐步补充硬样本迭代。

2.2 标注工具的选型和标注规范

标注工具我用的是两种开源的图形标注工具，一种老牌经典，一种新式带辅助功能的。前者界面简单、稳定，适合大批量纯人工标注；后者支持自动分割辅助、交互式标注，效率上能提升一倍。两者标注完都能导出 YOLO 格式的 txt 文件，省去格式转换的麻烦。

不过工具不是重点，重点是人头检测标注规范。普通目标检测只需要“框住目标”，但人头检测的标注要讲究得多。我最终定的规范是这条：

• 人头边界框尽量贴合头部轮廓，包含头发顶部和下巴下边缘，但不包含脖子和肩膀。
• 严重遮挡目标：如果某个头被遮挡面积小于 50%，仍然要标；超过 50% 且只有零星边缘可见，不标。
• 画面边缘的不完整人头，只要可见部分超过 30%，也要标注。
• 两个紧挨着的人头，框可以重叠，但不要为了“美观”去调整边界而丢失真实位置。
• 密集区域每个人都必须单独成框，严禁一个框框住两个人头的情况。

这几个规范和你在通用标注里看到的很不一样。普通标注讲究“干净”，人头标注讲究“尽可能多、尽可能准”。有人可能会问，画面里那么多人头密密麻麻，标注得眼花缭乱怎么办？我的经验是，标注密度大的图时放大到 200%，一个个人头按顺序标过去，宁可慢也不能漏。

标注时还要注意类别平衡。本项目只有一类 head，但如果你想把戴帽子和不戴帽子分开统计，可以拆成 head 和 hat_head 两类。我不建议拆，因为拥挤场景里帽子特征太不稳定，拆类会明显增加误检。

2.3 数据增强与数据集划分

采集和标注完成之后，数据增强是挤场景模型能否扛住实战的关键一环。普通训练用个随机翻转就行，但人群数据的分布太特殊，需要做更有针对性的增强方案。

我在项目里启用的增强策略包括 Mosaic、Copy-Paste、随机遮挡、HSV 色域抖动和随机透视。

Mosaic 是 U 版 YOLO 引入的经典策略，把一个 batch 里的 4 张图随机裁剪拼接成一张新图，强制模型学习不同光照和背景下的小目标特征，对拥挤场景非常有效。我在训练前 80 个 epoch 开启 Mosaic，最后 20 个 epoch 关掉，避免拼接图的小目标分布和真实场景不一致导致最终精度下降。

Copy-Paste 是特别适合人群场景的增强。实现逻辑是先把密集区域的人头目标连同背景抠下来，贴在另一张稀疏图上，人为制造“局部拥挤”样本。这样能把有限的密集目标数据复制出更多变体，大大缓解拥挤样本不足的问题。

随机遮挡则可以模拟真实场景前后遮挡。做法是把图里的随机矩形区域清成纯色斑块，迫使模型依赖更鲁棒的特征识别，而不是只认完整的人头轮廓。

数据集划分我用的是 train/val 各占 90%/10%，不设独立的 test 集，因为验证集已经能反映泛化趋势。但要注意划分时按视频序列分组，不能把同一段视频的帧同时混进训练和验证，否则会严重高估模型效果——这个问题很多初学者都会踩。

最终数据集目录结构长这样：

text复制datasets/head_count/
├── images/
│   ├── train/
│   └── val/
├── labels/
│   ├── train/
│   └── val/
└── head_dataset.yaml

YAML 文件里只需要指好路径和类别：

yaml复制path: ./datasets/head_count
train: images/train
val: images/val

nc: 1
names: ['head']

3. YOLOv5/v8/v10 的训练配置与调优

3.1 环境准备与训练启动

训练环境使用的是 PyTorch 2.x 和配套的 CUDA 版本。显存 8GB 起步，如果只有 CPU 或者老显卡，劝你还是先租个云 GPU 实例，不然训练一轮下来人都要等麻了。

我用的是单卡训练，一张 24GB 显存的显卡，这个卡跑 YOLOv8s 配 640 分辨率、batch size 64 毫无压力。如果你显存小，batch size 减半就行。

启动训练前先写好数据集 YAML，然后三个版本分别执行训练命令。

YOLOv5 训练命令：

bash复制python train.py \
    --data head_dataset.yaml \
    --weights yolov5s.pt \
    --img 640 \
    --batch-size 32 \
    --epochs 150 \
    --device 0 \
    --workers 4

YOLOv8 训练命令：

bash复制yolo detect train \
    data=head_dataset.yaml \
    model=yolov8s.pt \
    imgsz=640 \
    batch=32 \
    epochs=150 \
    device=0 \
    workers=4

YOLOv10 训练命令：

bash复制yolo detect train \
    data=head_dataset.yaml \
    model=yolov10s.yaml \
    imgsz=640 \
    batch=32 \
    epochs=150 \
    device=0

三个版本我在实际项目中都跑过，v5 和 v8 训练过程比较稳定，v10 的端到端训练对学习率更敏感一点，初学建议先用官方默认学习率，不要手动改太大。

3.2 关键超参数怎么定

训练命令看起来简单，真正决定项目成败的是超参数。我给几个自己在拥挤人头场景里的推荐值，并说清楚为什么。

第一个是 imgsz。很多人习惯用默认 640，但人头检测里小目标实在太多，640 输入下小头几乎不可见。我最终训练用的是 960，推理时输入也保持 960。代价是显存占用翻倍、推理速度下降，但对小目标的召回提升非常明显。如果你的设备实在跑不动 960，妥协到 768 也比 640 好很多。

第二个是 batch size。在不爆显存的前提下尽量大，32 是底线，64 更好。batch 太小会让 BatchNorm 统计不稳定，影响收敛。我的建议是先把显存加到能承受的上限，再往里塞 batch。

第三个是 epoch。拥挤场景因为数据复杂，150 epoch 起步，200 epoch 也不嫌多。关键要看验证集 loss 是否还在下降，如果 20 个 epoch 内 mAP 都不动了，就早停。

第四个是 lr0。YOLO 系列默认初始学习率 0.01 已经比较稳。如果你发现训练初期 loss 震荡剧烈，把它降到 0.001 试试。人群目标小、正样本占比低，学习率过大很容易把梯度带偏。

第五个是 NMS 阈值和置信度阈值。这两个虽然推理时才用，但训练时的 anchor 分配和后处理语义也相关。拥挤场景建议推理时把 IoU 阈值从默认的 0.45 降到 0.3，置信度阈值从 0.25 提到 0.4。降 IoU 是为了让紧挨着的人头框不容易被合并成一个，提置信度是为了滤掉拥挤区域产生的低质量误检框。

3.3 训练过程监控与调优

训练启动后，我每周都会看一次训练日志里的 box_loss、cls_loss、.mAP50、mAP50-95 这几个指标，判断模型状态。

box_loss 稳定下降说明边界框回归在正常学；如果停滞不动，先看是不是数据标注框不精准，再考虑是不是学习率过低。mAP50 是针对 IoU 0.5 的指标，人头检测项目主要盯它。如果 mAP50 高但 mAP50-95 低，说明模型框得“不够紧”，边界贴合不精准，这时候需要更长的训练轮次或者提高输入分辨率。

我遇到过的典型情况是：训练 60 epoch 内 mAP 涨得飞快，到 100 epoch 后验证集指标反而轻微下降，这是过拟合的典型信号。解决方法很简单，我用的是 YOLOv8 提供的早停机制，通过 patience 参数控制，连续 20 个 epoch 没有提升就自动停止。同时我关闭了最后 20 个 epoch 的 Mosaic 增强，让模型在接近真实分布的数据上微调。

另一个坑是类别不均。如果你的数据里稀疏场景特别多、密集场景特别少，模型会对密集区域“视而不见”。我的处理方式是给样本做了重采样，让 batch 里密集场景的出现频率至少占到 40%。这一步对最终效果的提升，比我换任何模型结构都明显。

4. 拥挤场景推理优化与模型加速

4.1 从模型训练完到可用的最后一公里

训完模型只是万里长征走了一半。很多项目在测试集指标上很好，一接到真实摄像头画面就全线崩溃，问题大多出在推理阶段没有针对拥挤场景做后处理。

推理阶段第一个要调的参数就是置信度阈值。我用训练好的模型直接跑真实场景测试，发现大量误检来自背景区域——墙面纹理、椅子靠背、远处的车灯都容易被当成头。把置信度从默认 0.25 提到 0.4 之后，误检大幅减少，真正的头并没有丢太多。

第二个是 NMS 阈值。拥挤场景里两个人头如果靠得很近，预测框高度重叠，默认的 0.45 IoU 阈值会把其中一个框当成重复框合并掉。我试过把它调到 0.2，结果一个头被拆成两三个框；调到 0.45 以上，紧挨着的人头又被吞掉。最终调在 0.3 是一个比较舒服的位置。

我用一个直观例子说明：假设两个人头实际位置距离只有 15 像素，模型给出两个框，IoU 计算结果为 0.4。那么阈值 0.45 时，两个框被认为是同一个目标，其中一个被抑制掉；阈值 0.3 时，两个框被保留，正好对应两个人头。所以在拥挤场景里，IoU 阈值要适度调低，但不能低到让同一个目标的多个框全都保留。

4.2 小目标从哪捡回来

密集场景里的小目标漏检，是后处理参数调不回来的硬伤。我试过三种思路，最后组合着用效果最好。

第一种是提升输入分辨率。训练和推理都用 960，甚至 1280。代价很明显，单帧耗时上涨，但小头召回率让我舍不得降回去。如果你的服务器性能有限，可以考虑做动态分辨率：视频画面里人群密度低时用 640，密度高时自动切到 960。

第二种是 tiling 切图策略。把大图分成若干重叠小块分别检测，再把结果合并回原图坐标。这个方案对超高清全景摄像头特别有效，但对小车不太友好。我实际用的代码逻辑大概是这样的：

python复制# 伪代码，演示切图检测的思路
def tiling_detect(image, model, tile_size=640, overlap=0.2):
    h, w = image.shape[:2]
    detections = []

    for y in range(0, h, int(tile_size * (1 - overlap))):
        for x in range(0, w, int(tile_size * (1 - overlap))):
            tile = image[y:y + tile_size, x:x + tile_size]
            results = model(tile, imgsz=tile_size)
            for box in results[0].boxes:
                x1, y1, x2, y2 = box.xyxy[0].tolist()
                # 把局部坐标还原为全图坐标
                detections.append((x + x1, y + y1, x + x2, y + y2))
    return detections

切图后需要对重叠区域的检测框做一次全局 NMS，否则重叠区会出现大量重复框。

第三种是 TTA（测试时增强）。推理时同时跑原图、水平翻转图和多尺度图，再把结果合并。这个方案效果最好，但耗时成倍增加，在实时系统里很难直接上。我的做法是把它留作离线分析工具，适合做事后统计和标注辅助，不适合在线视频流。

4.3 加速推理的实操

前面做了那么多加分辨率、加切图的操作，推理开销肯定会涨，所以加速是必须的。

我最终的线上推理方案是走 ONNX + TensorRT 部署。YOLOv8 和 YOLOv10 官方都提供了导出脚本，可以直接转 ONNX，再由 TensorRT 转成 engine 格式。有一个印象很深的坑：转 ONNX 时有些版本的模型内置了 NMS 算子，导致 TensorRT 转换报错。解决方案是导出时显式禁用 NMS，保留原始输出，后处理用 TensorRT 插件完成。

TensorRT 开启 FP16 精度后，单帧 960 输入的推理时间大约可以压缩 50%。实测下来，在桌面级显卡上大概能跑到 30ms 一帧，配合跳帧策略可以满足 25 帧左右的实时展示。如果继续做 INT8 量化，推理速度还能再快一倍，但量化校准后小目标精度掉得比较厉害，我在项目里没有用 INT8，保守起见保留 FP16。

加速方案选型这件事，我的建议是别盲目追求满血速度，先测你自己的场景在哪个精度水平下还能接受，再决定量化深度。

5. UI 界面设计与完整系统集成

5.1 界面功能规划

模型跑通了，最终要交到不熟悉命令行的人手里，所以 UI 界面是项目的脸面。我的 UI 用 PyQt5 做桌面应用，功能按使用场景拆成三块。

输入侧支持三种模式：选择本地图片、选择本地视频文件、打开摄像头实时采集。对图片和视频，界面展示检测结果并叠加人数统计；对摄像头，界面实时刷新画面和人数数字，同时提供开始、停止按钮，防止摄像头资源一直被占用。

展示侧是大画面显示区，检测结果带彩色边界框和置信度标注。左上角显示“当前人数”大字数字，底部有实时帧率和每帧耗时统计。

业务侧提供一个简单的 CSV 导出功能，把每一帧的时间戳、人数、置信度平均值写进表格，方便做后续客流分析。这部分虽然小，但实际使用时特别好用，比让用户截图统计强一百倍。

整个界面的设计原则是克制，不加花哨元素，默认显示内容只有检测画面和人数，其他统计信息放到侧边栏或底部。

5.2 PyQt5 工程结构与关键代码

PyQt5 界面最核心的一个问题，是不能在 UI 主线程里跑模型推理。如果直接在按钮回调里执行模型推理，界面会卡死到完全无法拖动窗口，用户体验非常糟糕。解决办法是用 QThread 开一个工作线程，让模型推理在后台持续跑，处理完一帧后通过 Qt 信号把结果送回 UI 线程刷新画面。

我实现的核心逻辑大概是这样：

python复制# 检测线程
class DetectThread(QThread):
    frame_signal = pyqtSignal(QImage)   # 把结果帧传给 UI
    count_signal = pyqtSignal(int)      # 把人数传给 UI
    fps_signal = pyqtSignal(float)      # 把帧率传给 UI

    def __init__(self):
        super().__init__()
        self.device = 0
        self.model = None
        self.cap = None
        self.running = False
        self.skip_frames = 2

    def load_model(self, model_path):
        ckpt = torch.load(model_path, map_location="cpu")
        self.model = ckpt["model"].float().eval()
        self.model.to(self.device)

    def run(self):
        fps_start = time.time()
        frame_id = 0
        while self.running:
            ret, frame = self.cap.read()
            if not ret:
                break

            # 跳帧检测，提升处理速度
            frame_id += 1
            if frame_id % self.skip_frames != 0:
                continue

            results = self.model.predict(frame, imgsz=960, conf=0.4, iou=0.3)
            annotated = results[0].plot(line_width=2)
            count = len(results[0].boxes)

            # 转换为 QImage 推给界面
            frame_rgb = cv2.cvtColor(annotated, cv2.COLOR_BGR2RGB)
            h, w, ch = frame_rgb.shape
            q_img = QImage(frame_rgb.data, w, h, ch * w, QImage.Format_RGB888)
            self.frame_signal.emit(q_img)
            self.count_signal.emit(count)

            # 计算帧率
            fps = 1.0 / (time.time() - fps_start)
            fps_start = time.time()
            self.fps_signal.emit(fps)
        self.cap.release()

这里我故意用了跳帧策略，每 3 帧只检测 1 帧，因为拥挤场景里的人头位置变化不会特别剧烈，跳帧 2-3 帧换取 2-3 倍处理速度非常划算。

主窗口里只需要连接信号就好：

python复制self.detect_thread.frame_signal.connect(self.update_frame)
self.detect_thread.count_signal.connect(self.update_count)
self.detect_thread.fps_signal.connect(self.update_fps)

这个模式我建议封到手后使用，任何类似 GUI 集成模型的需求都可以照搬。

5.3 实时性与稳定性的平衡

实时视频检测的稳定性和实时性是一对矛盾，有几个实际技巧对效果影响很大。

第一是摄像头资源管理。打开摄像头前先检查是否已被占用，检测结束必须 release，否则再次打开会因为资源冲突导致黑屏。我遇到过多次这种问题，后来在关闭事件里强制调用 self.detect_thread.running = False，并等待线程完全退出后再关闭窗口，才彻底解决。

第二是内存增长问题。实时检测跑久了会发现显存占用缓慢上升，大概率是每次 predict 都产生了新的中间结果但没有释放。解决办法是尽可能复用处理结果，不保存多余的变量，每一帧处理结束后显式清理 History 和清空缓存。

第三是帧率同步问题。UI 刷新频率需要和检测帧率匹配，不要让界面一帧一帧跳。我用一个简单的定时器控制 UI 刷新频率在 30Hz，保证画面流畅度稳定。

第四是异常处理。摄像头中途断流是经常发生的事，比如 USB 摄像头松了一下，这时候程序不能直接崩溃。我在读取帧的循环里加了重连机制，检测到连续读取失败超过 50 帧就自动重新打开摄像头，同时 UI 上给出提示，而不是整个应用死掉。

6. 实战问题记录与避坑清单

6.1 训练期间的三次翻车

第一次翻车是显存溢出（OOM）。我把 imgsz 调到 960 后，batch 还是照搬 640 时的 64，结果训练没跑两步就爆显存。排查过程不复杂，显存占用大概是原分辨率面积比的平方倍关系，960 相对于 640 显存需求放大到 2.25 倍，所以我从 batch 64 直接降到 32。如果你还想保住 batch 数量，可以用梯度累积，等效模拟大 batch。

第二次翻车是训练不收敛。日志里 loss 从一开始就在 5 左右震荡，怎么调都降不下去。排查到最后发现是数据标注文件里有人头的类别编号写成了 0，而数据集 YAML 里又把类别名称写成了别的顺序，导致标签和类别对不上。这个问题非常隐蔽，因为模型还能出框，只是框的位置一塌糊涂。解决办法是训练前写一个小脚本，直接读一张图和它对应的 label 文件可视化一遍，确认框是不是正确落在人头上。

第三次翻车是 mAP 很高但实际检测效果很差。这轮训练验证集 mAP50 到了 0.85，但一接到真实监控画面，错误框满天飞。原因就是我在前面强调过的——训练集和验证集来自同一批视频的抽帧，模型严重过拟合到场景特征上了，一到新场景就露馅。修复方法是重新按视频序列划分数据集，再补充了大量不同场景的稀疏样本，问题才缓解。

6.2 推理和 UI 阶段的坑

推理阶段最典型的坑是模型用 GPU 推理但 PyQt 主线程在 CPU 上做图像转换，导致每帧转换耗时比推理还长。解决办法是把 cv2 图像转 QImage 的操作也放到工作线程里，只有最后的渲染在主线程完成。

另一个坑是摄像头视频流颜色异常。OpenCV 默认读进来是 BGR，直接显示到 PyQt 上画面会发蓝。我刚开始忽略了这个细节，调试了半天才发现往界面上传之前要先做 BGR 到 RGB 的转换。这类问题我用颜色转换那一行代码就解决了。

还有一个实际部署时常见的问题是模型文件路径写死，换机器就崩。我把所有路径都改成相对配置文件配置，模型、视频、导出目录统一放在外部 config 里，换环境只要改一个配置文件即可。

我把这些问题统一整理成了一个速查表，方便你以后快速定位：

7. 项目扩展与后续优化方向

7.1 能做的扩展比想象中多

这套人头检测系统跑通之后，最爽的部分是可以快速扩展出更多功能，而且基本不需要再动模型。

人数统计做成实时折线图，累积一天的人流变化曲线，可以监测商场不同时段客流峰值。加上跟踪算法（比如 ByteTrack）就可以实现轨迹追踪，能区分一个人进来又出去还是两个人一进一出。进一步做区域越界检测：在画面里画几个感兴趣区域，只要统计进出每个区域的人数就能做方向性分析，比如判断哪个通道拥堵最严重、哪个柜台排队太长了。

人流密度热力图是另一个很好用的扩展。把检测出的人头坐标投影到画面二维网格，按高斯核叠加密度，就可以生成实时热力图，直接叠加在原图上供管理人员查看。这个功能对展览、车站这类大空间管理特别实用。

还可以输出标准化的 JSON 数据接口，把检测结果推给后端分析平台，实现大屏展示。如果后端需要结构化数据，只需要在推理线程里把每帧的检测框坐标、置信度、时间戳写到一个消息队列里。

7.2 我的真实体会

做这个项目，我最大的体会是：模型结构本身决定不了项目的成败，数据质量和工程细节才是决胜点。YOLOv8 和 YOLOv10 的差距在实际效果上远小于数据集质量导致的差距，这是新人最容易忽略的地方。

另一个体会是，参数调节不能靠玄学，要有意识。每次调阈值、调分辨率，都要记录下当时的配置和对应的效果指标，形成自己的调参地图。我仅 NMS 阈值就从 0.2 到 0.6 逐个测试过一轮，每个值对应的漏检率和误检率都记在表格里，最后才确定 0.3 这个值。盲目拍脑袋调参，调一百次也调不出好效果。

还有一点想特别提醒：做这类项目一定要分清“演示”和“可用”的差别。能跑通是一回事，24 小时连续跑不崩、断流自动恢复、日志清晰可查是另一回事。工程化的系统拼的永远不是模型多先进，而是异常情况下还能不能稳定运行。这一课，我是踩了无数次坑才学会的。