企业官网建设流程全解析

1. 先交代一下：这个安全帽检测项目为什么非要在端侧做

1.1 项目现场的真实情况：网络、摄像头、报警闭环

我接到这个需求的时候，第一反应其实跟大多数人一样：安全帽检测这种识别任务，库里随便找个开源模型，接到 GPU 服务器上跑不就行了？真正到项目现场转了一圈之后，我才发现这个思路在工地上根本走不通。

现场的情况是这样的：一个在建园区，分了三个施工标段，每标段少则四五路、多则十几路摄像头，分布在出入口、塔吊底部、钢筋加工棚、临边防护区域这些位置。摄像头倒是不缺，但全部是普通的网络摄像头，大部分通过工地自建的临时局域网汇聚到一台 NVR 上，再通过一条很一般的上行链路接到外部。真正的痛点不在"能不能识别"，而在"识别结果怎么闭环"。

安全帽检测的最终应用不是出一张截图给人看，而是要联动现场的音柱做语音提醒，或者在值班室的大屏上弹报警记录。这意味着从摄像头取流、到检测、到输出告警，整个链路必须在几秒内走完，否则工人早就走过去了，提醒也就没有任何意义。把视频推到云端再拉回结果，或者等人工去翻录像，这两个方案在时间上都不可接受。

1.2 云端方案算完三笔账之后被否了

当时我其实先正经评估过一条云端路线：所有摄像头通过 RTSP 推流到云服务器，在云上用 GPU 实例跑检测，检测结果通过接口回传。技术上行得通，但算完账就有点犹豫了，我又结合现场实际条件逐条对了一下，最后彻底放弃。

第一笔账是带宽。一路 1080P 的 H.264 主码流，平稳场景下码率 2~4Mbps，遇到风吹草动或者傍晚画面噪点增多能到 5Mbps 往上。就算只取其中 10 路做主检测，上行也需要 30Mbps 以上的稳定带宽。但工地现场的网络不是写字楼的专线，高峰期对讲机、门禁、视频回传都在抢带宽，实际稳定性根本没法保证。而且我们当时不止一个工地，每个工地都要这么搞，专线费用直接变成一笔固定成本。

第二笔账是时延。视频从现场推到云端，经过编码、传输、解码、检测，再返回结果，理想状态下也要 1~2 秒。这里还没算网络抖动和排队。对安全帽检测这个场景来说，告警的价值就在那几秒内，超过 3 秒基本就是无效信息。更麻烦的是，现场音柱联动如果依赖云端回转，断网或者网络波动时整个系统就"哑"了。

第三笔账是数据合规。很多企业现在对视频数据外传非常敏感，摄像头画面跨越园区边界本身就需要审批流程，有些项目甚至明确要求视频不能出工地。这其实是个很现实的限制，很多时候它不是技术问题，而是管理问题。

1.3 端侧部署的核心矛盾：算力有限但必须实时

云端方案被否掉之后，端侧部署就成了唯一选项。但端侧也有端侧的难处：没有数据中心那种几乎无限的算力池，没有成熟的 GPU 生态，甚至没有宽松的功耗条件——很多项目现场只有普通 220V 插座，不能像机房一样搞一个高功耗主机。

所以我当时给自己设定了几条硬指标：单台设备要能同时处理至少 4 路 1080P 视频流；从取流到告警输出，端到端时延要控制在 1 秒以内；设备功耗控制在 20W 以内，方便放在弱电箱或者立杆机箱里；设备必须支持 Web 管理界面，方便现场运维人员做简单的配置和重启。

这几条指标把很多方案挡在门外了。第一轮筛选之后，我手里实际上只有三条路线：Jetson 系列、树莓派加边缘算力卡、以及 RK3588 平台。它们各有各的取舍，后面我会详细展开我的对比过程。

2. 硬件选型对比：我在 Jetson、树莓派和 RK3588 之间怎么选的

2.1 一开始的候选清单和筛选逻辑

很多人选边缘硬件容易犯一个毛病：只看一个指标，比如"谁 NPU 算力高就选谁"，或者"谁的生态资料多就选谁"。这种做法在个人项目上问题不大，但放到一个要走交付流程的项目里，很容易在中后期翻车。

我的候选清单如下：Jetson Orin NX 系列、树莓派 5（外接算力卡）、RK3588 平台。三条路线的核心参数差异我整理在下表，方便对照看。

这里先说明一下，TOPS 这个数字不能直接横向比，各家统计口径不一样，有的算稀疏、有的算稠密，标称算力和实际跑模型的速度之间差了十万八千里。真正有效的对比方式只有一个：拿你的模型在对应平台上分别跑一遍，看延迟和帧率。

2.2 Jetson 的顾虑：生态香，但周期和散热劝退

Jetson 系列我其实很熟，因为它的软件生态确实是这几条路线里最完整的。CUDA 那套东西在 Jetson 上基本是"即插即用"，PyTorch 模型可以很平滑地迁移过去，社区里踩坑记录也多，遇到问题基本搜得到答案。如果这个项目只做一台演示样机，我大概率会选 Jetson。

但到了实际交付环节，有几个问题绕不过去。首先是供货周期和价格。当时项目排期比较紧，而 Jetson Orin NX 模块的采购周期明显拉长，价格也跟着水涨船高，还要搭配定制载板。对于"每工地放 2~3 台盒子"这种批量需求来说，这个成本不是小数。

其次是散热和封装。Jetson Orin NX 的功耗虽然不高，但它是高频高密度设计，满载时发热集中，被动散热机箱需要仔细设计风道，主动风扇则要考虑现场粉尘环境下的可靠性。工地粉尘有多大就不用我形容了，风扇积灰之后噪音、过热、降频是早晚的事。相比之下，RK3588 这种面向工规、商规场景的 ARM SoC，整体热密度要低不少，一个铝制被动散热壳就能压住。

2.3 树莓派是无 NPU 平台，编解码和推理抢资源

树莓派 5 刚出的时候我特意测过一次，它的 CPU 性能确实比前代提升明显，跑一些轻量级逻辑非常够用。但安全帽检测需要的是"解码 + 推理 + 绘制 + 推流"这个完整的视频处理管线，树莓派在这条链路里有两个硬伤。

硬伤之一是它是"无 NPU 平台"。纯靠 CPU 跑 YOLOv5s 这种模型，640×640 输入在全核满载的情况下也就跑到 5~10FPS，而且这时候 CPU 已经被推理吃干了，解码、绘制、叠加文字这些操作全部排队等资源。我实测过，一旦开始做 H.264 硬解和画面缩放，帧率会进一步掉到 3~5FPS，这个水平做实时检测太勉强。

硬伤之二是外接算力卡的软件栈割裂。树莓派本身是通用 Linux 生态，外接算力卡通常要走私有 SDK，模型转换工具链和主流的深度学习框架之间往往需要很多手工适配。做 demo 可以，做产品就要承担很多额外开发量。而且算力卡同样面临散热、供电、机械固定的问题，等于把一套本来可以紧凑集成的方案拆成了两台设备。

2.4 RK3588 的 NPU+MPP+RGA 组合刚好卡在需求甜点上

RK3588 进入视野是在我对比完前两条路线之后。它给我的第一印象是"规格很全"：4 个 A76 大核 + 4 个 A55 小核，6 TOPS NPU，自带 8K 解码能力和 4K 编码能力，还集成了 RGA 图形加速单元。这些东西分开看每个都不算惊艳，但组合在一起，几乎就是视频分析盒子需要的完整拼图。

最关键的是，RK3588 的解码、缩放、推理这三件事是由三个独立硬件单元完成的：MPP 负责视频硬解码，RGA 负责图像缩放和格式转换，NPU 负责模型推理。三者并行工作的时候互不抢占 CPU，主 CPU 只负责调度和业务逻辑。我用单路 1080P 视频流做预处理基线测试时，MPP 解码几乎不占 A76 核心，RGA 做 NV12 到 RGB 的转换和缩放也非常快，这给后续业务逻辑留下了充足的运算余量。

如果你的场景只有一到两路视频，算力要求很低，那其实随便哪个平台都行，选 RK3588 反而浪费。但当"多路取流 + 实时检测 + 本地闭环"这几个条件同时成立时，RK3588 的这种异构加速架构几乎就是为这个场景准备的。

3. 从 PyTorch 到 RKNN：模型转换过程的真实坑

3.1 版本组合必须先对齐：工具链版本、runtime 和驱动

硬件定了之后，我以为模型部署会很快：训练一个 YOLOv5s，导出 ONNX，转换 RKNN，上板跑通，完事。实际做下来，第一步就折腾了我一个下午。

RK3588 的 NPU 推理需要把 ONNX 或者 PyTorch 模型转换成 RKNN 格式，这套工具链叫 RKNN-Toolkit2。它有两种使用方式：一种是在 x86 主机上用 Python 跑转换和模拟推理，另一种是直接在板子上用 RKNN-Lite 跑推理。问题在于，主机端的 RKNN-Toolkit2 版本、板端的 RKNN runtime 版本、NPU 驱动版本，这三者必须严格对齐，版本不匹配的话转换出来的模型可能上板直接加载失败，甚至出现莫名其妙的精度下降。

我当时就吃了版本不对齐的亏：主机端用的 RKNN-Toolkit2 版本比较新，但板端刷的系统镜像里自带的 runtime 驱动还是旧版，结果模型转换时 API 报了一个很隐晦的版本不支持错误，排查了很久。后来我总结出一个规矩：先确认板端系统镜像里 runtime 的版本，再到原厂发布页找对应的 Toolkit2 版本，而不是反过来用最新版工具链去迁就旧板子。

3.2 量化要用现场数据而非通用图片

RKNN 转换里有个容易忽略但又非常影响结果的参数：量化数据集。INT8 量化需要一个校准数据集，用来统计每层 activation 的数值范围，然后决定怎么把浮点权重压缩到 8bit。很多人图省事，直接用验证集里随便挑几十张图就过一遍，这样出来的模型在测试视频上表现很差。

我的做法是从现场采集的样本里抽取 200 张左右图片作为量化集，覆盖白天、傍晚、夜间红外、阴天、雨天各个时段。因为工地场景的视觉分布和通用数据集差别很大——安全帽颜色鲜艳、背景有大片灰扑扑的混凝土、夜间有红外补光带来的高噪点画面——如果量化集不能代表这些分布，模型在端侧的表现就会和训练时严重脱节。

量化之后一定要先做精度对比。我在同样的测试集上对比过 FP32 模型和 INT8 量化模型的 mAP 结果，掉点在 2~3 个点是正常的，属于可接受范围；如果某个类别掉点超过 5 个点，那就是量化集选得有问题，或者某个层对量化特别敏感。

3.3 算子兼容性问题：一个 Decode 层让精度掉 4 个点的排查

模型转换过程中遇到的最典型的坑，是一个后处理算子的兼容性问题。我用的是 YOLOv5s 6.2 版本，模型自带 Detect 头，导出 ONNX 后里面有一些把预测结果解码成坐标的算子。RKNN 工具链对这部分算子的支持是分版本的，旧版本工具链在转换时会发生部分算子被"降级"到 CPU 执行的情况，或者被替换成精度损失较大的实现。

我第一次转换完，量化后的模型在测试集上精度比 FP32 掉了将近 4 个点。tools 自带的模拟推理看起来正常，但上板实测 loss 大得离谱。排查过程很枯燥：先把模型里各个层逐个去掉来定位敏感层，然后在 GitHub 的 issue 里翻到一条关于 Detect 层解码算子兼容性的讨论，这才意识到是工具链版本的问题。

解决方式有两种：一是升级 RKNN-Toolkit2 到支持该算子的版本；二是把模型改写成"只保留主干 + 检测头输出 raw 预测，把 decode 和 NMS 挪到 NPU 之外，用普通 C++ 代码在 CPU 上做"。我选了第二种——从工程角度看，后处理放在 CPU 上更安全，以后换模型结构也不用再担心工具链的算子支持度问题。这个决定在后面调模型的时候帮了大忙。

3.4 后处理放 NPU 还是 CPU：我的选择

关于后处理放哪里的问题，简单说下我的体会。NPU 理论上可以跑完整的模型，包括一部分后处理，但现实是它的算子支持列表有限，有些高效实现（比如特定版本的 NMS、某些动态 shape 的 gather 操作）转换不了，强行转换会让模型超过预期 size 或者变慢。

我最终把 NMS 和坐标解码都做在了吃 CPU 的一侧。640×640 输入、单路视频流，每帧检测结果里的目标数量不会太多，这部分计算量完全可以忽略。最直观的好处是：训练团队后来换模型结构、调置信度阈值、改类别过滤逻辑，都只需要重新生成 .rknn 文件和调整推理代码里的参数，不用再跟工具链的兼容性问题纠缠。

4. 视频管线搭建：解码、缩放、推理之间的排队问题

4.1 MPP 硬解码 + RGA 预处理：别让 CPU 干图像处理的活

模型搞定之后，新的问题又冒出来了：怎么把摄像头视频流高效地送进 NPU？

如果沿用通用的 OpenCV 方案，用 cv::VideoCapture 拉 RTSP 流再 imread 取帧，在 RK3588 上会非常浪费——CPU 做软解不仅占用大量 A76 核心，还会让整个设备在 4 路并发时直接卡顿。正确的做法是走 RK3588 的 MPP 硬解码接口，让它用硬件解码器把视频码流解成 NV12 格式的图像帧。MPP 对 H.264/H.265 码流的兼容性很好，RTSP 取流的职责交给 FFmpeg 的 avformat 层，拿到编码后的 AVPacket 再喂给 MPP 硬解。

解码出来的 NV12 帧还不能直接喂给 NPU。我的模型输入是 RGB 格式、640×640 分辨率，而摄像头原始帧是 1080P 的 NV12。这一步如果直接写代码逐像素转换，CPU 占用率会直接飙上去。RK3588 自带的 RGA 模块可以一次性完成"裁剪/缩放 + NV12 到 RGB 的格式转换"，RGA 本身是硬件加速，做这一组操作对 CPU 几乎零负担。

我建议的取流链路是：FFmpeg 负责解协议拿 packets，MPP 负责硬件解码，RGA 负责预处理的缩放和颜色转换，NPU 只拿干净的标准 RGB 帧做推理。这条链路里没有任何一步需要 CPU 深度参与像素计算，多路视频并发时 CPU 才能腾出手来做业务逻辑和告警推送。

4.2 双线程队列设计：采集和推理解耦，用有界队列兜底

视频管线搭起来之后，下一个问题是架构上的：取流、解码、推理这几个环节是串行执行还是并行处理？

如果每帧都"取流 -> 解码 -> 推理"串行处理，任何一环出现瞬时抖动，整个管线都会被拖慢，最终结果是帧率忽高忽低，时延像过山车。我用的方案是标准的双线程结构：采集线程负责取流和解码，把解码后的图像帧放入一个有界队列；推理线程从队列里取帧，做缩放、推理、后处理，然后推送结果。两个线程之间通过一个带互斥锁的队列通信，队列容量固定为 4~6 帧。

这个设计的最关键点是"有界"两个字。队列满的时候，采集线程必须主动丢帧——永远不能让采集线程无限阻塞等待队列腾出空间，否则输入侧压力会传导到输出侧。

// 伪代码：有界队列的消费者逻辑 void InferenceThread() { while (running) { Frame* frame = queue.Pop(); // 队列为空时阻塞等待 if (frame == nullptr) continue; cv::Mat rgb = RgaConvert(frame); // RGA 硬件转换 auto dets = rknn_run(rgb); // NPU 推理 ProcessDetections(dets); // 告警判断 + 推流叠加 queue.Recycle(frame); // 回收帧内存 } }

这里还有一个容易被忽略的细节：帧内存要复用。不要在每一轮循环里重新分配 cv::Mat 内存，频繁的 malloc/free 会让内存碎片越来越严重，跑几个小时之后设备开始变慢。我是预先申请了一个帧缓冲池，采集线程从缓冲池取空帧、推理线程用完归还，整个运行过程中内存分配次数非常少。

4.3 抽帧策略：全帧检测反而拉高时延，跳帧更稳

最开始我自然是"来一帧测一帧"，全帧也不卡，但一旦视频路数增加到 4 路以上，推理线程的负载就会明显上来。后来我冷静想了一下：安全帽检测真的需要每秒 25 帧的检测频率吗？

工人进入镜头到走到警戒区域，这个过程至少持续几秒。检测频率只需要保证"人在画面里出现过、且被抓拍到了若干帧"就够了。实测下来，每 3 帧取 1 帧做检测，也就是在 25FPS 视频流里做到约 8FPS 的检测频率，对安全帽这种运动速度很慢的目标来说完全足够。

重要的是，跳帧不能只是"数到第几帧丢多少帧"那么机械，最好加一个时间戳判断。如果没有时间戳，当视频源帧率波动时，跳帧后的实际检测频率会不稳定。我的做法是：采集线程每拿到一帧就检查当前时间，距离上一次送入队列超过 120ms 才允许入队，这样检测频率会稳定在 8FPS 左右。

这里有一个反直觉的结论：全帧检测在实时性上不如跳帧检测。其原因在于推理线程的处理速度是固定的，当输入帧积压到队列里排长队时，每帧从入队到被推理的时间拉长，最终系统的输出延迟反而变大。适度丢帧，让队列保持低水位，才能保证"最新一帧"被及时处理。这也是我在这个项目里学到的很实用的一课。

4.4 全链路实测数据：CPU、NPU、时延、帧率

经过一番调整，我在一台被动散热的 RK3588 盒子上跑通了完整流程，用 4 路 1080P 视频流实测了下数据。

之前纯 CPU + OpenCV 软解软编方案，单路 1080P 时 CPU 已经跑到 90% 以上，帧率还上不去；切到 MPP 硬解 + RGA + NPU 之后，4 路并发时 CPU 还有大量余量去做告警推送和 Web 服务，这就是异构加速组合带来的直接收益。端到端时延从 800ms 降到三四百毫秒，听音柱联动报警的时候差异非常明显。

5. 精度和误报的二次调优：工地环境比数据集复杂得多

5.1 逆光、夜视、灰尘：数据增强要做现场数据采样

模型在测试集上跑得很好，不代表在现场就能跑好。工地的光照环境是真的恶劣：白天大太阳底下工人戴安全帽，逆光的时候安全帽整个变成一团黑；傍晚光线不足时，摄像头自动切换红外夜视，画面变成低饱和度的灰绿色；还有雨天水雾、扬尘天气，画面就像蒙了一层纱。

我处理这些问题的思路是：不要自己闷头想数据增强，直接去现场采集真正会出现的画面段。我在不同时间段、不同天气条件下，分别录制了每个摄像头视角的视频片段，从中抽帧补进训练集。针对逆光问题，我加了对整图做暗角、降对比度、曝光偏移的增强操作；针对红外夜视画面，我单独做了一组灰度化 + 噪声抖动的增强。

这一步对最终的 F1 值提升非常明显。原来模型在夜间画面下漏检率很高，原因很简单——训练集里根本就没有红外画面，模型"没见过"这种风格的图。补了现场夜视样本之后，夜间检测效果一下子就正常了。如果你的项目也是这种固定机位场景，最有效的数据增强不是随机裁剪翻转那些通用 Trick，而是从真实现场的机位视角去采集数据。

5.2 小目标：30 米外的安全帽只有 15×15 像素怎么办

安全帽检测一个隐性问题是小目标——在工地入口这种宽阔视野下，工人离摄像头远的时候，整个头部的像素高度可能只有二三十个像素，安全帽本体就更小了，大概 15×15 像素左右。这种尺寸的目标对 YOLOv5s 来说非常吃力。

我试过两条路。一条是用更大输入尺寸的模型，比如把 640×640 换成 1280×1280，小目标检出率确实提升，但 NPU 推理耗时几乎翻倍，多路并发时扛不住。另一条是切图检测，把 1080P 原图切成四块分别推理，但这个方案不仅推理次数增加四倍，还引入了跨块目标的拼接问题，工程复杂度太高。

最终我的选择是分场景处理：出入口和塔吊底部这些近距离机位，使用常规模型配置，保证实时性；开阔区域的大范围机位，单独训练一个更高输入分辨率的模型，且降低检测触发频率，只在关键帧或 I 帧附近做一次检测。这个"一台设备内加载多套模型配置"的思路，把算力花在刀刃上，小目标漏检率降了不少，同时没有牺牲整体实时性。如果你的项目也是固定机位场景，建议按机位实际覆盖范围分别调整模型配置，而不是一个模型通吃所有画面。

5.3 误报防线：人脸和黄色安全帽之间的斗争

精度问题搞完之后，真正让我头大的是误报。安全帽检测的误报五花八门：黄色铁皮、塑料桶、反光背心都可能被认成黄色安全帽，最离谱的是因为颜色太接近，模型会把肤色附近的人脸区域识别成黄色安全帽。

解决误报不能光靠训练，还要在推理后处理上加"业务级"判断。我加了这么几层防线：

第一层是目标属性过滤。安全帽和目标检测框有位置关系，头部往往在画面中呈现为检测框，安全帽应该出现在头部上方区域。我把明显不在合理位置关系内的候选框直接丢弃。这个先验知识非常朴素，但能把大量贴在身体两侧的误报干掉。

第二层是时序稳定性。单帧的检测结果不可信，但连续帧的检测结果就很可信。我给每个检测目标加了生命周期：同一目标在连续 3 帧内都被检出，且区域重叠度超过 60%，才认为这是一个真实事件。这层逻辑实测下来把误报率降了一半以上。

// 伪代码：连续帧确认逻辑（目标生命周期管理） if (matched_frame_count >= 3) { TriggerAlarm(target_id, bbox); matched_frame_count = 0; // 防止重复触发 }

第三层是颜色特征辅助。安全帽的 HSV 颜色分布比通用目标更集中，黄色安全帽的色相、饱和度都有比较稳定的区间。我在检测框内部再做一次简单的颜色统计，如果候选框内部的黄色像素占比过低，就降低置信度。这一层不是用来做主要判断，只是给置信度做一个参考修正。三层叠加之后，误报率从最初的高频噪音，降到可以接受的低水平，现场值守人员也明显更信任这套系统了。

6. 这次权衡最后教会我的几件事

6.1 边缘 vs 云端的成本账，算完再动手

这次项目做下来，我对"边缘 vs 云端"有了更具体的认知。如果单纯看一次性开发成本，云端方案确实更省力——不用做硬件适配、不用处理端侧各种异常情况，一套 GPU 服务器上的代码跑遍所有项目。但这个账要拉长到部署规模和运营周期来看：

单台边缘盒子的硬件成本，对多数项目来说不到一个季度云服务器的租用费。算上带宽费用，10 路视频的云端方案一年的持续成本明显高于一次性采购边缘盒子。更重要的不在于省多少钱，而在于边缘方案把"检测能力"沉淀成了固定资产，放在现场的盒子里，不吃带宽、不受网络波动影响、数据不出门。对于长期运营的工地项目，这种模式天然更稳。

6.2 模型更新和视频管线的维护成本错位

如果让我复盘整个项目的工时分配，大概是这样的：模型训练和调优占了三成，NPU 转换和算子适配占了两成，视频管线（取流、解码、绘制、推流、告警联动、配置管理）占了四成，剩下的一成是现场联调和部署。大部分人第一反应会觉得模型是主角，实际项目里视频管线的繁琐程度远远超过想象。

这里有个经验供参考：在项目架构上，尽量让模型更新只影响 ".rknn 文件 + 少量参数"这一层，把解码、绘制、推流、告警策略这些业务逻辑和模型解耦。这样算法团队后来迭代模型，只需要替换文件、改一下类别配置，业务逻辑完全不用动。如果一开始把后处理也塞进模型里，每次模型结构变动都可能引发一遍全链路测试，那工作量会让人崩溃。

6.3 什么情况下我会劝你别抄这份作业

最后说几句掏心窝的话。RK3588 方案并不是万能的，以下情况我建议你别照搬：

第一，如果项目现场有可靠网络、视频允许上云，而且检测结果的闭环可以在云端走通，那直接用云端 GPU 服务器是明智能的选择。边缘方案的硬件适配、现场调试成本不会低，没必要为了"边缘"而边缘。

第二，如果算法团队坚持要用超大模型追求极致精度，比如用 YOLO-X 级别甚至更大规模的模型，RK3588 的 6 TOPS 算力会比较吃力。这种情况下只能考虑边缘做前置初筛、云端做精检的两级架构，或者换更高算力的硬件平台。

第三，如果只是做一个几路视频的演示系统，根本不需要考虑多路并发和长时间稳定运行，那树莓派或者一台普通工控机加一个加速卡也完全能应付，选择 RK3588 只会增加不必要的开发量。

我最终选定 RK3588，是因为这个项目的具体约束——多路并发、实时闭环、网络不稳、长期运行、成本敏感——恰好能用它的异构加速架构来满足。我的建议是：先写清楚你项目的硬指标和约束条件，再对照硬件参数做取舍，而不是拿着一个现成方案去套需求。

最后再分享一个小技巧：视频分析盒子到了现场之后，最怕的其实不是检测不准，而是 RTSP 流断线之后整个程序挂掉。实验室里你很难模拟出"摄像头掉线 5 分钟再恢复"这种场景，但工地现场几乎每周都会发生。从一开始就给取流模块加上断线重连、超时保护、以及整机看门狗重启机制，会让你的系统在现场少挨很多骂。