最近在做一套公共场所的视频安全监测程序，需求听起来不算复杂：有人没戴口罩要报警，人和人挨得太近要报警，体温看起来不正常也要报警。但真正把这三个功能拼进同一个Python项目里，会遇到比想象中多得多的细节问题——模型怎么选、距离怎么算、温度数据从哪里来、又是怎么跟摄像头画面一一对应上的。这篇文章就是我基于这个项目整理的完整实现记录，覆盖从模型选型、距离标定到热成像设备接入的全过程，适合正在做类似视觉安全检测项目的开发者参考。
我把整个项目拆成了四个可独立运行的模块，再通过一个主程序做联动调度。项目的核心是口罩佩戴检测、行人安全距离检测和生物测定（bioassay）三个部分，其中生物测定这里主要以体温筛查为目标，也可以扩展到心率等生命体征指标。整套程序用Python编写，推理部分基于深度学习目标检测框架，视频流处理基于OpenCV，实际部署在一台普通的工控机上，用USB摄像头加红外热成像模块做输入，最终在实时画面里画出检测框、距离连线、温度数值和告警状态。
1. 项目整体需求拆解：为什么这三个检测必须放在一起
1.1 单一检测模块的痛点
很多现成的开源项目只解决一个问题，比如只做口罩识别，或者只做行人检测。但在真实场景里，单一模块的价值非常有限。我之前试过只部署一个口罩检测程序，结果现场管理人员反馈说：你告诉我谁没戴口罩，但两个人挨得那么近，我也很难判断该不该提醒，更麻烦的是，有些人戴着口罩走过来，体温却异常，这种反而要格外注意。所以需求很快就从"检测口罩"变成了"口罩、距离、体温三合一"。
三合一不是简单地把三个功能串起来，而是要在同一个视频帧里协同工作。比如当系统检测到两个人距离小于安全阈值时，还要同时判断这两个人是否都戴了口罩，如果其中一方没戴口罩，告警级别就要更高。再比如体温异常的人出现在画面里，人眼很难从普通摄像头画面里看出来，这时候就需要红外热成像数据做融合判断。每个模块单独跑没问题，但一旦合并调度，就涉及设备同步、数据对齐、线程阻塞这些问题，这也是这个项目里最有工程价值的地方。
1.2 系统整体流程设计
整个系统的数据流可以概括为：视频帧获取、目标检测、属性分析、逻辑判断、告警输出。视频帧获取环节同时接管普通摄像头和红外热成像模块，普通摄像头用于YOLO目标检测，红外模块用于提取温度数据。目标检测环节先做行人检测，再对每个行人的头部区域做口罩佩戴分类。属性分析环节计算行人之间的像素距离并换算成实际距离，同时把红外温度数据映射到检测框上。逻辑判断环节综合所有信息，生成告警级别和提示信息。最后通过OpenCV画框、语音播报和日志记录把结果输出。
这个流程看着直白，但每一步都有不少坑。比如普通摄像头和红外模块的视场角不一致，会导致温度检测框和目标检测框对不上；比如行人在画面里一帧一帧地跑，距离计算如果不做跟踪，同一行人被重复检测会导致误报；再比如口罩检测模型在光线暗或者侧脸的情况下很容易漏检。后面我会把每个环节的具体实现和踩坑经验都写出来。
2. 核心技术选型：模型、框架与硬件的取舍
2.1 目标检测模型：YOLOv8n为什么比YOLOv5s更适合这个场景
检测模型我最终选择了YOLOv8n。很多人还在用YOLOv5，不是说YOLOv5不行，而是这个场景对实时性要求很高，工控机上还要同时跑三个模块，模型不能太大。YOLOv8n是YOLOv8系列里最小的版本，参数量大约3.2M，COCO数据集上mAP在37左右，但推理速度在CPU上都能跑到20到30帧每秒，配合GPU加速会有更好表现。
这里我对比过几个候选模型。YOLOv5s精度略高一点，但模型体积大了近一倍，在同一个设备上做三路推理时，帧率下降明显。YOLOv8n在精度损失很小的情况下换来了更快的速度，对本项目这种以实时告警为核心的场景来说更合适。另外YOLOv8的输出格式更简洁，可以直接拿到每个检测框的类别、置信度和坐标，减少了后处理代码量。如果你也要做类似项目，我的建议是：先在YOLOv8n上跑通全流程，别一上来就用大模型，否则后面联调的时候会因为帧率太低影响距离计算的实时性。
2.2 行人安全距离检测的技术路线：单目摄像头加标定方案
行人安全距离检测有几种实现路线。第一种是直接用深度摄像头，比如Intel RealSense系列，它能直接输出深度图，通过深度值计算距离，精准但硬件成本高，而且深度摄像头在户外强光下效果会打折。第二种是双目立体视觉，两个摄像头标定后通过视差计算距离，实现复杂，标定过程也比较繁琐。第三种是单目摄像头加几何标定，假定行人站在地面平面上，通过透视变换把画面转换成鸟瞰图，在鸟瞰图里计算距离，成本最低，代码量适中，精度在2到3米的误差范围内能满足安全距离预警需求。
我选的是第三条路线。具体思路是：第一步用棋盘格标定板求摄像头的内参和畸变系数；第二步在画面地面区域取四个参考点，这四个点在实际场景中对应一个已知尺寸的矩形（比如两米乘两米的区域）；第三步通过这四个点的像素坐标和实际坐标求单应性矩阵；第四步把每一个行人的脚底坐标（检测框底部中点近似）投影到鸟瞰图坐标上；最后计算任意两个行人坐标的欧氏距离，再乘上比例系数得到实际距离。这样做的核心原因是：安全距离检测不需要特别精确，只需要能稳定判断"小于1米""小于1.5米""大于2米"这几个区间，单目方案完全够用。
2.3 生物测定（bioassay）模块的硬件选择：普通摄像头做不到的事
生物测定这个词在不同领域含义不太一样。在本项目里，我把它理解为针对人体生理指标的实时检测，核心是体温。普通摄像头拍的是可见光，拿不到温度数据，所以这个模块必须依赖额外的传感器。我的选择是红外热成像模块，具体用的是MLX90640这类阵列式红外传感器，它能够输出32乘24像素的热成像矩阵，每个像素代表一个温度值。分辨率不算高，但用来做体温筛查足够。
除了MLX90640，市面上还有一种方案是热成像机芯模组，分辨率更高，比如384乘288或者640乘512的，这类设备精度好，但价格高出不少，而且驱动和SDK通常只在Windows下提供，对Python项目的兼容性反而不如MLX90640这种开放的I2C设备。MLX90640虽然需要自己做温漂补偿和坏点处理，但胜在跨平台、库齐全、社区资料丰富，非常适合快速原型验证。如果你要在室外场景部署，建议换用更高分辨率的设备，因为MLX90640对远距离人脸测温的精度确实有限，最佳测量距离在0.5到1米之间。
3. 口罩佩戴检测模块：数据、训练与实时推理细节
3.1 数据集与标注规范
口罩检测属于目标检测任务，最理想的做法是直接训练一个带口罩类别的检测模型。但这需要采集大量戴口罩的人脸图片，数据来源是个问题。我实际采用的是分步方案：先用通用行人检测模型检测行人，然后从行人检测框的上半部分裁出头部区域，再交给一个口罩分类模型判断这个头部是"戴口罩"还是"没戴口罩"。这种方案的优点是可以复用成熟的COCO预训练行人模型，口罩分类模型只需要处理分类任务，数据需求小很多，训练也更快。
口罩分类数据集我用的是公开数据集中筛选出来的图片，按三类区分：戴了口罩、没戴口罩、佩戴不规范（比如口罩拉到下巴）。标注的时候要注意，不要把口罩遮挡下半脸的人脸框当作"没戴口罩"，否则模型会学到错误的特征。我的做法是：先让人脸检测器检测人脸，再把口罩区域作为分类依据，最后对每个类别统计数量，保证类别平衡。如果某一类图片太少，就用数据增强补足，主要做水平翻转、亮度调整和随机裁切。
3.2 训练配置与迁移学习
口罩分类模型我用了MobileNetV3的预训练权重做迁移学习。选它的原因和选YOLOv8n类似，模型轻量，推理快，在工控机上跑CPU也能达到较高吞吐。训练时我先把输入resize到224乘224，batch size设成64，初始学习率0.001，优化器用Adam，损失函数用交叉熵。训练集大约有8000张图片，每类两千多张，训练30个epoch就基本收敛了，验证集准确率能到95%以上。
有一个很容易被忽略的细节：迁移学习时要冻结模型浅层，只微调靠近输出层的高层特征。MobileNetV3的前几层学到的是通用的边缘、纹理特征，这些特征不因为口罩任务而改变，冻结它们可以减少过拟合风险，同时大幅降低训练参数量。我用PyTorch实现时，通过设置参数的requires_grad属性来控制冻结范围。具体的做法是：前80%的层全部冻结，只对最后几个block和分类头做微调。
3.3 实时推理代码与分类结果处理
在实时推理阶段，我用YOLOv8n提供行人检测框，然后提取检测框的上半部分作为头部候选区域。这里有几个细节需要注意：第一，行人检测框通常是全身框，头部大约占上五分之一到四分之一，我取的是框顶部往下20%的区域；第二，行人侧身或者背影时，头部区域裁切出来可能只有后脑勺，分类模型很可能误判为"没戴口罩"，因为看不到面部特征，这种场景要允许通过连续帧投票来平滑结果；第三，分类器输出的置信度不能直接当作最终结果，至少要看连续3帧的结果，如果两帧都显示没戴口罩，才触发告警，这样能大大减少因为偶尔一帧检测偏差造成的误报。
下面这段代码是我在项目中实际使用的推理核心逻辑，做了简化处理，但流程是完整的：
import cv2 import numpy as np from ultralytics import YOLO pedestrian_model = YOLO("yolov8n.pt") mask_model = load_mask_classifier("mask_mobilenetv3.pth") def is_missing_mask(frame, pedestrian_box): x1, y1, x2, y2 = pedestrian_box width = x2 - x1 head_region = frame[int(y1):int(y1 + (y2 - y1) * 0.2), int(x1):int(x2)] if head_region.size == 0: return None head_resized = cv2.resize(head_region, (224, 224)) result = mask_model.predict(head_resized) return result # 0: 戴口罩, 1: 没有口罩, 2: 佩戴不规范 cap = cv2.VideoCapture(0) pending_alert = {} while True: ret, frame = cap.read() if not ret: break results = pedestrian_model(frame, verbose=False) for det in results[0].boxes: cls = int(det.cls[0]) if cls == 0: # person class box = det.xyxy[0].cpu().numpy() mask_state = is_missing_mask(frame, box) track_id = compute_iou_track_id(box, pending_alert) if mask_state == 1: pending_alert[track_id] = pending_alert.get(track_id, 0) + 1 if pending_alert[track_id] >= 3: draw_red_warning(frame, box, "NO MASK") else: pending_alert[track_id] = 0 cv2.imshow("mask detection", frame) if cv2.waitKey(1) & 0xFF == ord("q"): break这里我特意写了一个compute_iou_track_id函数，作用是给检测框分配一个临时ID，用来做连续帧的计数。如果不做这一步，同一行人每帧都是独立检测框，无法累计判断"连续3帧没戴口罩"。这个函数的实现可以按最原始的IoU匹配来写：当前帧的检测框和上一帧所有已知框计算IoU，如果最大值大于0.5就认为是同一个行人。后面我会在行人距离检测模块里也用同样的跟踪思路，只是把匹配特征换成脚底坐标的欧氏距离。
3.4 口罩检测模块的效果评估
我在办公室和走廊两种场景下做了测试。办公室场景光照均匀，正脸比例高，检测准确率在96%左右，连续3帧投票后基本不会误报。走廊场景偏暗，行人经过速度较快，部分侧脸和背身情况会把"没戴口罩"误判成"佩戴口罩不规范"，但经过投票后，漏报率控制在5%以内。整体来说，这个方案在室内固定摄像头场景下是可用的，但如果你要在户外强光或者多人同时入画的情况下使用，建议再引入一个人脸检测前置步骤，先精确定位人脸区域再分类，效果会好很多。
4. 行人安全距离检测：从像素坐标到实际距离的换算工程
4.1 行人位置估计：检测框底部中点比中心点可靠得多
行人距离检测最关键的一步是确定每个行人的地面位置。我在调试过程中发现，如果用检测框的中心点来计算距离，结果会非常不稳定，因为检测框高度会随着行人姿态变化而波动，站立、弯腰、蹲下都会让中心点上下跳动，距离计算结果就忽大忽小。后来我改成用检测框底部中点作为地面位置，效果好了很多，这个位置在物理上非常接近行人的脚底，而脚底恰好是行人接触地面的点，用来做透视变换是最合理的。
但底部中点也有一个需要注意的问题：如果行人的脚被其他物体遮挡，或者行人走出了检测框下边界，底部中点会偏移甚至消失。我在实际场景里遇到过一个情况，两个人在画面上半部分互动，下半身被柜台遮住，YOLO检测框往下延伸到柜台表面，底部中点其实落在柜台边缘上，这会让距离计算产生偏差。我的处理方式是：人为设定一个有效检测区域，只对处于画面中下区域的行人做距离计算，画面边缘和遮挡严重区域直接跳过，同时在告警逻辑里增加一个置信度权重，距离值越接近安全阈值边界，要求连续帧数越多。
4.2 透视变换标定的完整步骤
透视变换标定的目标是求一个单应性矩阵，用来把像素坐标映射到地面实际坐标。我在项目里的具体操作步骤如下：
第一步，打印一张标准的棋盘格标定板，贴在平整的地面上，用同一个摄像头从正上方或者略倾斜的角度拍几张照片。第二步，用OpenCV的findChessboardCorners函数提取角点，再用calibrateCamera计算出摄像头的内参矩阵和畸变系数。第三步，在视频画面的地面上选取四个点，这四个点在真实物理空间里构成一个已知尺寸的矩形。比如我在地面上贴了四个胶带标记，组成一个长2米、宽1.5米的矩形，然后记录这四个点在画面中的像素坐标。第四步，用getPerspectiveTransform函数求出单应性矩阵，再用warpPerspective验证变换效果。
下面是我用的核心代码片段：
import cv2 import numpy as np # 地面上四个标记点的像素坐标（按顺序：左上、右上、左下、右下） pixel_points = np.array([[280, 420], [640, 430], [200, 620], [720, 610]], dtype=np.float32) # 对应的实际地面坐标（单位：米） world_points = np.array([[0, 0], [2.0, 0], [0, 1.5], [2.0, 1.5]], dtype=np.float32) H, _ = cv2.getPerspectiveTransform(pixel_points, world_points) def pixel_to_world(px, py): point = np.array([[[px, py]]], dtype=np.float32) transformed = cv2.perspectiveTransform(point, H) return transformed[0][0][0], transformed[0][0][1] # 示例：计算两个行人之间的距离 foot_a = pixel_to_world(ax, ay) foot_b = pixel_to_world(bx, by) distance = np.sqrt((foot_a[0] - foot_b[0]) ** 2 + (foot_a[1] - foot_b[1]) ** 2)这里有一个非常关键的经验：四个像素点必须取自同一个物理水平面上的点，也就是说这四个点都要落在地面上，不能出现一个点标在墙面上或者桌子上的情况。我在第一次标定时就犯了这个错误，把其中一个点选在了地面上放置的纸箱顶角，结果整个变换矩阵偏差很大，距离计算结果直接失真。另外，如果摄像头位置或者焦距变了，标定必须重新做，这一步没法偷懒，否则前功尽弃。
4.3 距离计算与违规判断逻辑
有了透视变换矩阵，距离计算就变得很简单。每一帧检测到行人后，提取每个检测框底部中点的像素坐标，变换到世界坐标，然后两两计算欧氏距离。我设定安全距离阈值为1.5米，当距离小于阈值时输出警告；距离小于1米时输出严重警告。
但直接两两计算会有一个问题：行人A、B、C三个人站在一起，AB距离小于1.5米，BC距离也小于1.5米，AC距离大于1.5米，算法会把AB和BC都标记为违规，这没问题。可是如果出现了AB距离小于1.5米、AC距离也小于1.5米、但ABC三个人其实站得很密集的情况，告警信息会非常多，现场管理人员反而难以分辨谁是主要风险群体。我的优化方案是引入聚类思路：把所有距离小于阈值的人归到同一个违规组，每组只发一条综合告警，告警里写明涉及的行人ID和最小距离。这样既保留了检测的准确度，又减少了告警噪音。
我还在代码里加入了一个动态阈值策略。白天和晚上光线不同，行人检测框的稳定性也不同，晚上检测框抖动更明显，直接使用固定1.5米阈值容易出现时近时远的现象。我的做法是把阈值分成两档：默认1.5米触发警告，当连续3帧检测到同一组人距离都小于阈值时才触发正式告警；如果最小距离小于0.8米，则不需要连续帧，立即触发严重告警。这个策略在实际运行里明显降低了误报率。
4.4 行人跟踪对距离检测的加持
如果你认真做过类似项目，应该会发现一个很影响体验的问题：YOLO检测框在连续帧之间会抖动，抖动传递到距离计算上，会让距离值在1.4米和1.6米之间来回跳，告警一会有、一会没有。这个问题光靠加阈值滞回还不够，最好引入简单的目标跟踪。我用的是基于脚底坐标的最近邻匹配，不引入卡尔曼滤波的复杂逻辑，因为脚底坐标变化比较平滑，追踪起来很容易。具体做法是：维护一个当前活跃行人的列表，每个行人包含ID和脚底坐标；新帧到来时，对每个检测框计算脚底坐标与列表里所有行人的欧氏距离，找最近的那个，距离小于0.3米就认为是同一人并更新坐标；如果找不到匹配，就创建一个新ID；如果一个ID连续丢失超过10帧，就从列表里删除。
这种轻量跟踪的效果很明显。加入跟踪后，距离计算值变得更平滑，我还可以基于跟踪轨迹计算行人的运动速度，当两个人相向而行且速度较快时，把安全距离阈值放宽到2米，相当于提前三秒预警，这个功能在实际测试中很有价值，因为它比单纯的实时距离判断更接近人的直觉。
5. 生物测定（bioassay）模块：体温筛查的工程化实现
5.1 热成像设备接入与数据读取
MLX90640的接入需要用到I2C接口。我在树莓派上做过原型验证，后来部署到工控机上用的是FT232H转接模块，这样工控机也能通过USB访问I2C设备。Python端读取MLX90640数据的库主要是mlx90640-driver和pyftdi，前者在树莓派上直接可用，后者配合FT232H在Windows和Linux上都能跑。我选择的是pyftdi方案，因为部署环境是普通工控机，没有板载I2C引脚。
读取温度矩阵的代码如下：
import time from pyftdi.i2c import I2cController i2c = I2cController() i2c.configure("ftdi://ftdi:232h/1") mlx = i2c.get_port(0x33) # MLX90640 默认地址 # 每次读一整帧需要传递大量寄存器数据 for page in range(2): mlx.write([0x00, 0x24 + page]) data = mlx.read(666, True) process_page(page, data)MLX90640的原始数据是16位精度，需要经过出厂参数和温度补偿公式换算成摄氏度。这个过程比较繁琐，我用的驱动库已经封装好了换算函数，只需要传入帧数据就能得到32乘24的温度矩阵。但有一个坑：MLX90640在连续读取模式下，帧率设置和刷新速度必须匹配，否则会出现数据撕裂，相邻两块温度区域有拼缝。我的解决办法是把帧率设为8Hz，每读一帧后sleep 0.12秒，保证数据完整。
5.2 温度校准与环境补偿
这是整个生物测定模块里最容易出问题、也最容易被忽视的部分。MLX90640这类传感器在出厂时做过基础标定，但在实际环境中会受到环境温度、镜头遮挡、测量距离等多种因素影响。我的做法是：每次系统启动时，先让设备预热5分钟，然后测量一个已知温度的黑体或者恒温物体，计算偏移量，把这个偏移量应用到后续所有温度值上。
测温距离的影响也要处理。MLX90640的最佳测温距离在0.5到1米范围，距离超过1.5米时，温度和真实值偏差会增大到1摄氏度以上。在实际部署场景里，摄像头通常装在通道口或者门口，行人经过时距离镜头1到2米不等，所以我做了一个简化补偿函数：根据目标检测框在画面中的尺寸估算距离，然后按距离查表补偿。比如检测框高度达到画面的30%以上时，距离约0.5到0.8米，补偿量0.2摄氏度；检测框高度在10%到30%时，距离约1到1.5米，补偿量0.5摄氏度；更远的目标直接标记为"无法准确测温"，不做温度告警。
5.3 人脸区域与热成像坐标的映射
热成像模块分辨率太低，32乘24的矩阵根本无法做目标检测。所以我的做法是：先用普通摄像头做人脸检测，得到人脸在可见光画面中的像素坐标，然后通过两个摄像头之间的外参关系，把可见光坐标映射到热成像矩阵坐标上。这里的映射关系在安装时做一次标定，标定方法是：在画面中放置一个发热点（比如电烙铁或者人手），分别在可见光画面和热成像矩阵中定位这个点，多取几个点后计算单应性变换矩阵。
映射完成之后，温度提取变得很直接。在热成像矩阵的对应位置取一个3乘3邻域，计算平均温度，作为人脸区域温度。之所以取邻域平均而不是单点最大，是因为单点最大容易受坏点影响。MLX90640有几个像素点是出厂就坏掉的，输出温度会固定在某个异常值，必须先用掩码把这些坏点排除掉。邻域平均同时也能平滑掉微小的空间抖动，让温度值更稳定。
5.4 体温异常告警与多模块联动
体温告警的阈值我设在37.3摄氏度，这是公共场所常用的人体发热筛查线。但实际检测中，人体额头温度和人体核心温度之间有差异，而且每个人基础体温不同，所以37.3摄氏度作为硬性阈值会有一定误报率。我加入了两个优化策略：第一，对同一行人连续多次测温，取中位数作为最终结果，避免单次测量波动造成误报；第二，当口罩检测模块同时判断该行人没戴口罩时，即使温度是37.1摄氏度，也提升告警级别，因为没戴口罩且体温偏高需要重点关注。
联动告警的实现方式是采用了一个全局事件队列。三个模块各自把检测结果写入队列，主程序每秒读取一次队列，根据所有信息综合判断告警级别。
event_queue = queue.Queue() def alert_worker(): recent_events = [] while True: event = event_queue.get() recent_events.append(event) if len(recent_events) > 30: recent_events.pop(0) # 判断某一ID是否有复合风险 merged = merge_events_by_person(recent_events) for person in merged: if person["temperature"] >= 37.3 and person["mask_state"] == "no_mask": trigger_high_alert(person)实际测试中，这个联动机制非常好用。以前三个模块各自为政，一天能收到上百条零散告警，现场人员已经完全麻木；加了联动和聚簇之后，真正需要人关注的复合风险事件每天只有几条，信息价值明显提升。这也说明，做多检测模块的项目，真正拉开差距的不是单个模型的精度，而是事件融合和告警决策的逻辑。
6. 系统联调与性能优化：让整套程序在低配设备上稳定跑
6.1 多线程架构：不能让一个模块堵住整条流水线
如果所有检测都在同一个线程里按顺序执行，帧率会很难看。YOLOv8n推理需要大约30到60毫秒，口罩分类需要10到15毫秒，距离计算几乎不耗时，但MLX90640读取热成像数据要至少120毫秒。如果全部串行，一帧的处理时间轻松超过200毫秒，帧率只有5帧左右，行人快速走动时检测框会严重滞后。我的解决方案是拆成三个线程：视频采集和行人检测线程、口罩分类线程、热成像读取线程，线程之间通过队列共享数据。
Python的GIL会让CPU密集型的多线程效果变差，所以我把最重的YOLO推理放在主线程，把热成像I2C读取放在独立线程（因为I2C读取是阻塞型I/O，受GIL影响小），口罩分类因为要在每个行人框上跑，比较繁重，我也放在独立线程，但会限制它的队列长度，防止积压。
一个实际的性能瓶颈是CPU版本OpenCV和NumPy在多线程下的内存复制。每传递一帧给子线程，就要复制一份frame数据，三个线程之间传帧会导致内存占用飙升。我的优化做法是在送入队列前先对图像做一次缩小，比如从1920乘1080缩到960乘540，检测精度不会有明显损失，但内存占用和数据传输时间都大幅下降。
6.2 推理速度优化与缓存复用
除了多线程，模型推理本身也有几处可以优化的地方。第一处是输入尺寸，YOLOv8n默认输入是640乘640，但如果画面中行人目标相对大，可以把输入r缩到480乘480，推理时间能减少30%到40%。第二处是类别过滤，我只关心person类，所以推理后只保留cls为0的检测框，这个过滤能让后处理时间忽略不计。第三处是推理缓存，相邻两帧之间画面变化其实很小，如果当前帧所有检测框与上一帧的IoU都超过0.9，可以完全跳过推理，直接复用上一帧的检测结果，这个技巧在摄像头固定、画面变化缓慢的场景里非常有效，帧率能提升一倍以上。
口罩分类模型也有类似的优化空间。MobileNetV3在CPU上的单次推理大约10毫秒，如果画面里有10个人，就要跑10次，也就是100毫秒，这还是会拖慢速度。我发现同一行人在画面里的头部位置变化不大，所以给每个跟踪ID设置一个分类结果缓存，如果该ID在最近5帧内有过分类结果，只有在当前帧的检测框置信度较低时才重新分类，否则直接复用缓存。这样分类开销几乎可以忽略。
6.3 实测效果：帧率、告警准确率与典型误报来源
整套系统在工控机上测试时，配置是Intel i5处理器、16GB内存、没有独立显卡，用纯CPU推理。实测结果是：行人检测线程保持在18到25帧每秒，口罩分类和热成像读取独立运行，不会拖累主循环，整体画面显示稳定在21帧左右。告警结果的评估我分了两个维度：漏报率和误报率。连续测试一天的数据显示，口罩漏报率大约4%，距离告警误报率约8%，体温筛查误报率因为环境温度波动会高一些，大约15%，其中大多数误报来自行人快速经过时体温测距不准。
典型误报来源主要有三个。第一，多人重叠：两个行人交叠走过时，YOLO检测框会互相干扰，导致脚底坐标偏移，距离计算突变；第二，红外模块被阳光照射：阳光中的红外成分会让温度读数整体偏高，下午时段特别明显；第三，口罩佩戴不规范：口罩拉到下巴但鼻子外露的情况，分类器倾向于判成"佩戴不规范"而不是"没戴口罩"，但管理人员其实最担心的就是这种。三个误报来源里，前两个通过增加连续帧确认都缓解了，第三个需要单独调整数据集的标注权重，或者把"佩戴不规范"也列入告警规则。
6.4 部署层面的小经验：日志、远程告警与模型热更新
最后聊几个部署层面容易被忽视的细节。第一个是日志记录。告警事件一定要记录时间、行人ID、检测值、画面帧截图，这样出了问题还能回溯。我的做法是每当触发严重告警时，把当前帧保存为一张JPEG图片，同时在CSV里追加一条记录。第二个是远程告警。现场没有专人盯着屏幕时，可以用企业微信机器人或者钉钉机器人接口推一条文本消息，Python里用requests库非常方便。第三个是模型热更新。如果后续训练了新模型，不需要重启整个程序，用一个模型版本号文件控制，程序每30秒检查一次版本号，发现有变化就自动加载新权重，这对长期运行的系统很重要。
总结一下这个项目的经验：单模块检测并不难，难的是把多个模块组合在一起还能稳定运行。口罩检测、距离检测、体温检测各自都有成熟的算法和工具，但真正决定项目成败的是你对场景的理解——行人的脚底坐标怎么提取、红外和可见光怎么对齐、告警怎么聚合、误报怎么消除。这些都是把DEMO变成可用系统的关键细节，也是这篇文章希望为你提供参考的地方。
如果你要复现这个项目，我的建议是分阶段推进：先在普通摄像头画面上把口罩检测和距离检测跑通，验证画面和逻辑都稳定，再加入热成像模块做体温筛查。不要一开始就追求三合一，因为每个模块的调试都会占用大量时间，分开加能让你更清楚问题出在哪个环节。如果条件允许，最好准备两台摄像头，一台对准出入口做个人筛查，一台架在空旷区域做距离检测，两套系统独立运行再统一汇总告警，这样实际效果往往更好。
