企业官网建设流程全解析

1. 安防通行人脸抓拍识别系统的整体设计思路

1.1 为什么选择“抓拍+识别”而不是“纯视频分析”

做过安防项目的同行都清楚，通行场景下的人脸识别和普通视频监控分析是两码事。普通监控可以容忍几秒延迟，但通行场景——比如门禁闸机、考勤通道、访客登记——要求的是“人过留脸、脸过留名”，整个链路必须在几百毫秒内完成。我最早接触这类需求时，试过直接用视频流做逐帧检测，结果服务器CPU直接跑满，效果还不好。后来改成“抓拍机负责抓拍、后端负责识别”的架构，整个系统才稳定下来。

这个思路的核心在于分工：前端抓拍设备（通常是带人脸检测能力的网络摄像头或专用抓拍机）只做一件事——检测画面中的人脸并输出最优的一张抓拍图；后端服务接收这张图，做特征提取和比对。这样做的好处是前端算力被充分利用，后端压力大幅降低，而且抓拍图的质量比视频帧更可控。

从技术选型上看，抓拍环节依赖的是摄像头内置的检测算法，识别环节则通常采用ArcFace这类开源人脸识别算法。ArcFace的核心优势在于它通过加性角度间隔损失函数，让同类人脸的特征向量在超球面上更紧凑，不同类之间更分散。说人话就是：同一个人不同角度拍的照片，特征向量靠得近；不同人的照片，特征向量离得远。这个特性对1:N识别场景特别关键，因为门禁场景下需要从几千甚至几万张底库中准确找出目标人脸。

1.2 系统链路的完整拆解

一个完整的安防通行人脸抓拍识别系统，从物理世界到业务系统，大致经过这几个环节：

• 前端抓拍：摄像头通过RTSP协议输出视频流，内置算法检测人脸并抓拍最优帧
• 图像传输：抓拍图通过HTTP/HTTPS或私有协议上传到后端服务
• 人脸检测与对齐：后端对抓拍图做人脸框检测和关键点对齐，确保人脸姿态标准化
• 特征提取：用ArcFace等算法将人脸图像转换为512维或1024维的特征向量
• 特征比对：将当前人脸特征与底库中的特征做1:N比对，找出最相似的目标
• 业务决策：根据相似度阈值判断是否放行，并触发闸机、记录通行日志等

这个链路里，RTSP协议承担的是视频流传输的角色。RTSP本身是控制协议，实际视频数据通过RTP传输，摄像头作为RTSP服务端，后端或中间件作为客户端拉流。在通行场景下，抓拍机通常自己完成检测和抓拍，后端不需要持续拉流，只需要接收抓拍图。但在一些改造项目中，如果用的是普通网络摄像头，就需要后端自己拉RTSP流做检测，这时候RTSP的稳定性和延迟就成了关键问题。

1.3 方案选型的几个关键考量

在实际项目中，我总结了几条选型原则：

第一，抓拍机优先于普通摄像头。专用抓拍机内置了人脸检测和最优帧选择算法，抓拍质量远高于后端从视频流里截帧。而且抓拍机通常支持HTTP直接上传抓拍图，省去了后端拉流和解码的开销。海康、大华等主流厂商的抓拍机都支持RTSP预览和抓拍图上传双通道，调试时可以用RTSP看画面，正式运行时走抓拍图上传。

第二，识别算法要选对场景。ArcFace在学术界表现很好，但工程落地时要注意模型版本和推理框架的匹配。InsightFace提供的ArcFace模型有多个版本，从MobileFaceNet到ResNet100，精度和速度差异很大。通行场景下，我一般推荐用ResNet50级别的模型，在GPU上单张推理能控制在20ms以内，精度也足够。

第三，底库管理要提前设计。1:N识别中，N的大小直接影响比对耗时和准确率。几千人的底库用暴力比对还能接受，几万人就必须上向量索引了。常用的方案是Faiss或Milvus，前者轻量适合嵌入式，后者适合大规模分布式场景。

2. 核心细节解析与实操要点

2.1 RTSP拉流与抓拍机的配合方式

RTSP协议在安防领域的地位不用多说，海康、大华、宇视的摄像头默认都支持。海康的RTSP地址格式通常是：

rtsp://用户名:密码@IP地址:554/Streaming/Channels/101

其中101表示通道1的主码流，102表示子码流。调试阶段建议用子码流，分辨率低、延迟小，方便快速验证。正式运行时如果后端要做视频分析，再用主码流。

这里有个实操细节：很多抓拍机同时支持RTSP预览和抓拍上传，但两者是独立的。RTSP预览走的是视频流通道，抓拍上传走的是HTTP通道。配置的时候要在摄像头Web界面里分别设置。我遇到过好几次，RTSP能正常预览，但抓拍图传不上来，最后发现是HTTP上传的地址配错了，或者防火墙没放行。

注意：海康摄像头的RTSP地址中，通道号从1开始，但有些型号的NVR通道号从33开始。调试时先用VLC或ffplay测试RTSP地址是否可用，再接入代码。

用ffplay测试RTSP的命令很简单：

ffplay -rtsp_transport tcp "rtsp://admin:password@192.168.1.64:554/Streaming/Channels/101"

加-rtsp_transport tcp是为了强制走TCP传输，避免UDP丢包导致的花屏。在局域网内UDP通常没问题，但跨网段或无线环境下，TCP更稳。

2.2 人脸检测与对齐的关键参数

抓拍图拿到之后，第一步是人脸检测。这里说的检测不是摄像头内置的检测，而是后端对抓拍图再做一次精确定位。为什么要做两次？因为摄像头内置的检测算法通常比较轻量，给出的人脸框可能不够精确，关键点也可能有偏差。后端用RetinaFace或SCRFD这类算法重新检测，能拿到更准确的人脸框和5个关键点（双眼、鼻尖、左右嘴角）。

对齐的目的是把人脸旋转到标准姿态。具体做法是根据5个关键点计算仿射变换矩阵，将人脸对齐到112x112的标准尺寸。这一步对识别精度影响很大，我做过对比测试：不对齐的情况下，ArcFace的识别准确率会下降5到10个百分点，尤其是侧脸和俯仰角较大的场景。

对齐后的图像送入ArcFace模型提取特征。以InsightFace的buffalo_l模型为例，输出是512维的归一化特征向量。归一化的意思是向量长度为1，这样比对时只需要算余弦相似度，值域在-1到1之间。实际使用中，同一个人的两张照片余弦相似度通常在0.5以上，不同人通常在0.3以下。阈值一般设在0.4到0.45之间，具体要根据业务场景调整。

2.3 1:N识别的底库构建与比对策略

1:N识别是通行场景的核心。底库就是所有授权人员的人脸特征集合，每个人可能有多张照片，每张照片对应一个特征向量。比对时，将当前人脸特征与底库中所有特征计算相似度，取最高分对应的身份。

底库构建有几个要点：

照片质量比数量重要。一个人录入10张模糊照片，不如录入3张清晰的正脸照。我一般建议每人录入3到5张，覆盖不同角度和光照条件，但必须是清晰的。

特征归一化要统一。所有特征向量必须用同一个模型提取，不能混用不同模型的特征。ArcFace不同版本之间的特征空间不兼容，混用会导致比对结果完全错误。

底库更新要平滑。新增人员时，不要直接往现有索引里插，而是批量重建索引。Faiss的IndexFlatIP支持动态添加，但数据量大时重建更稳妥。

比对策略上，除了取最高分，还要加几个约束条件：

• 最高分阈值：低于阈值直接拒绝，不返回任何身份
• 次高分差距：最高分和次高分的差距要大于一定值，否则说明底库中有相似人脸，需要人工确认
• 时间窗口：同一人短时间内多次抓拍，只记录一次通行

这些约束能有效降低误识率。我做过统计，不加约束的情况下，1:N识别的误识率在万分之一左右，加上约束后能降到十万分之一以下。

2.4 安卓端缓存RTSP流的特殊处理

有些项目需要在安卓设备上做人脸识别门禁机，这时候RTSP流的处理就比较特殊。安卓设备的网络和算力都不如服务器，直接拉RTSP流做解码和检测很容易卡顿。常见的做法是：

方案一：抓拍机上传抓拍图，安卓端只做识别。这是最省力的方案，安卓端只需要接收HTTP上传的图片，做特征提取和比对。缺点是依赖抓拍机，如果抓拍机故障，整个系统就瘫了。

方案二：安卓端拉RTSP流，本地缓存后做检测。这种方案需要在安卓端实现RTSP客户端，常用的库有libstreaming、GStreamer等。缓存策略是只保留最近几秒的帧，检测到人脸后取最优帧做识别。这里要注意安卓的硬件解码能力，建议用MediaCodec做硬解，软解在低端设备上跑不动。

方案三：边缘计算盒子。在安卓设备旁边放一个边缘计算盒子，盒子负责拉RTSP流和检测，安卓端只做展示和业务逻辑。这个方案成本高一些，但稳定性最好。

实操心得：安卓端拉RTSP流时，一定要设置超时和重连机制。网络抖动导致流断开是常态，没有重连机制的话，设备会一直卡在最后一帧。

3. 实操过程与核心环节实现

3.1 环境准备与依赖安装

先说一下我常用的环境配置。后端服务用Python写，主要依赖这几个库：

pip install insightface onnxruntime-gpu opencv-python faiss-cpu flask

InsightFace负责检测和识别，onnxruntime-gpu提供GPU推理加速，opencv处理图像，faiss做向量检索，flask提供HTTP接口。如果服务器没有GPU，把onnxruntime-gpu换成onnxruntime也行，但推理速度会慢很多。

模型文件需要单独下载。InsightFace的buffalo_l模型包包含检测模型（det_10g.onnx）和识别模型（w600k_r50.onnx），下载后放在~/.insightface/models/buffalo_l/目录下。首次运行时会自动加载。

RTSP拉流部分，如果只是测试，用ffmpeg就够了：

ffmpeg -rtsp_transport tcp -i "rtsp://admin:password@192.168.1.64:554/Streaming/Channels/101" -f image2 -r 1 frame_%04d.jpg

这条命令每秒抓一帧存成图片，方便快速验证RTSP地址和画面质量。正式代码里用OpenCV的VideoCapture拉流：

import cv2 cap = cv2.VideoCapture("rtsp://admin:password@192.168.1.64:554/Streaming/Channels/101") cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) # 减少缓冲，降低延迟 while True: ret, frame = cap.read() if not ret: # 重连逻辑 cap.release() cap = cv2.VideoCapture(rtsp_url) continue # 处理帧

CAP_PROP_BUFFERSIZE设为1很重要，默认缓冲会累积好几帧，导致延迟越来越大。

3.2 人脸检测与特征提取的完整代码

下面是我在实际项目中用的核心代码，做了简化但保留了关键逻辑：

import cv2 import numpy as np from insightface.app import FaceAnalysis # 初始化模型 app = FaceAnalysis(name='buffalo_l', providers=['CUDAExecutionProvider']) app.prepare(ctx_id=0, det_size=(640, 640)) def extract_feature(image_path): img = cv2.imread(image_path) faces = app.get(img) if len(faces) == 0: return None # 取最大人脸 face = max(faces, key=lambda f: (f.bbox[2]-f.bbox[0])*(f.bbox[3]-f.bbox[1])) # 特征向量已归一化 return face.normed_embedding def compare(feature1, feature2): # 余弦相似度 return np.dot(feature1, feature2)

det_size设为640x640是精度和速度的平衡点。如果画面中人脸较小，可以调到1024x1024，但推理时间会翻倍。ctx_id=0表示用第一块GPU，CPU推理时设为-1。

特征提取返回的normed_embedding已经是归一化的512维向量，直接点乘就是余弦相似度。这里有个细节：InsightFace的get方法内部做了检测和对齐，返回的normed_embedding是对齐后的特征。如果自己手动对齐，要注意关键点顺序和仿射变换的参数。

3.3 底库构建与Faiss索引

底库用Faiss的IndexFlatIP（内积索引）就够了，因为特征已经归一化，内积等于余弦相似度：

import faiss import numpy as np # 假设有1000个人，每人1个特征 dimension = 512 index = faiss.IndexFlatIP(dimension) # 特征矩阵，shape为(1000, 512) features = np.random.randn(1000, 512).astype('float32') faiss.normalize_L2(features) # 归一化 index.add(features) # 查询 query = np.random.randn(1, 512).astype('float32') faiss.normalize_L2(query) scores, indices = index.search(query, k=5) # 返回top5

k=5是为了拿到次高分做差距判断。实际使用中，如果最高分和次高分差距小于0.05，就认为结果不可靠，需要人工确认。

底库数据建议存两份：一份是Faiss索引文件，一份是原始特征和人员信息的映射表。Faiss索引只存向量和ID，ID对应到映射表里的姓名、工号等信息。这样重建索引时不会丢失业务数据。

3.4 通行决策与闸机联动

识别出身份后，需要做通行决策。我的做法是维护一个状态机：

class AccessController: def __init__(self, threshold=0.42, gap_threshold=0.05): self.threshold = threshold self.gap_threshold = gap_threshold self.last_pass = {} # 记录上次通行时间 def decide(self, scores, indices, person_ids): top_score = scores[0] second_score = scores[1] if len(scores) > 1 else 0 # 阈值判断 if top_score < self.threshold: return None, "低于阈值" # 差距判断 if top_score - second_score < self.gap_threshold: return None, "相似度过高，需人工确认" person_id = person_ids[indices[0]] # 时间窗口判断 now = time.time() if person_id in self.last_pass: if now - self.last_pass[person_id] < 5: # 5秒内重复 return None, "重复通行" self.last_pass[person_id] = now return person_id, "通过"

闸机联动通常走串口或网络接口。串口的话用pyserial发指令，网络接口一般是HTTP或TCP。海康的闸机支持HTTP接口，发一个POST请求就能开闸。这里要注意指令的幂等性，网络抖动导致重发时不能重复开闸。

4. 常见问题与排查技巧实录

4.1 RTSP连接失败与花屏排查

RTSP相关的问题占了调试时间的一大半。我整理了一个速查表：

海康摄像头的RTSP地址有个坑：如果用户名或密码包含@或:，必须做URL编码，否则解析会出错。比如密码是p@ss:word，要写成p%40ss%3Aword。

还有一个常见问题是摄像头连接数限制。海康的消费级摄像头通常只支持4到6路RTSP并发连接，超过后会拒绝新连接。如果后端服务重启时没有释放旧连接，就会出现“明明没人用却连不上”的情况。解决办法是等几分钟让摄像头自动释放，或者在代码里确保异常时释放VideoCapture。

4.2 人脸识别准确率低的优化方向

识别准确率低通常不是单一原因，我一般按这个顺序排查：

第一步，检查抓拍图质量。把抓拍图存下来人工看，如果人脸模糊、过曝、过暗，那问题在前端。调整摄像头曝光参数，或者换抓拍机。

第二步，检查对齐效果。把对齐后的112x112人脸图存下来看，如果人脸没有居中或者角度不对，说明关键点检测有问题。可以换检测模型，或者调整检测阈值。

第三步，检查底库质量。底库照片如果本身质量差，识别率肯定上不去。建议底库照片用专业设备拍摄，光照均匀、正脸、无遮挡。

第四步，调整阈值。阈值太高会拒真，太低会认假。通行场景下，我一般把阈值设在0.4到0.45之间，然后根据实际测试微调。如果误识率高，提高阈值；如果拒识率高，降低阈值。

第五步，换模型。如果以上都优化了还是不行，考虑换更大的模型。buffalo_l用的是ResNet50，可以换成ResNet100的模型，精度会提升2到3个百分点，但推理时间翻倍。

实操心得：识别率低的时候，先别急着调算法，把抓拍图和对齐图存下来看，80%的问题出在图像质量上。

4.3 安卓端RTSP缓存的性能优化

安卓端做RTSP缓存和检测，性能是最大的瓶颈。我试过几种方案，分享下经验：

硬解码优先。用MediaCodec做硬件解码，比FFmpeg软解快3到5倍。但MediaCodec的兼容性是个坑，不同芯片平台的参数不一样，需要做适配。

降低检测频率。不需要每帧都做检测，可以每3到5帧检测一次。通行场景下，人走过摄像头的时间通常有1到2秒，按25帧算就是25到50帧，每5帧检测一次也有5到10次检测机会，足够抓到清晰人脸。

限制缓存大小。只缓存最近2秒的帧，检测到人脸后从缓存里取最优帧。缓存太大浪费内存，太小可能错过最优帧。

用NNAPI或GPU加速。安卓端可以用NNAPI调用NPU加速推理，或者用GPU delegate。但NNAPI的兼容性也是问题，建议做降级方案，NNAPI不可用时回退到CPU。

4.4 1:N识别的误识与拒识平衡

1:N识别中，误识（把A认成B）和拒识（没认出A）是一对矛盾。降低阈值可以减少拒识，但会增加误识；提高阈值则相反。通行场景下，误识的后果比拒识严重得多——把陌生人放进去是安全事故，把授权人员拦住只是体验问题。所以策略是宁可拒识，不可误识。

具体做法：

• 阈值设高一点，比如0.45
• 加差距约束，最高分和次高分差距小于0.05就拒绝
• 加活体检测，防止照片攻击
• 加人工确认通道，拒识的人员可以通过其他方式验证身份

活体检测在通行场景很重要。我遇到过用手机照片试图通过门禁的情况，后来加了活体检测才解决。活体检测有几种方案：动作配合（眨眼、转头）、红外双目、3D结构光。动作配合体验差但成本低，红外双目和3D结构光体验好但成本高。根据项目预算选择。

4.5 系统稳定性与容错设计

安防系统要求7x24小时运行，稳定性设计不能马虎。我总结了几条：

服务健康检查。后端服务要暴露一个健康检查接口，监控系统定期调用。发现异常时自动重启。

RTSP断线重连。拉流代码必须有重连逻辑，断线后等待几秒重试，重试次数超过阈值就告警。

底库备份。Faiss索引文件和映射表要定期备份，最好存两份，一份本地一份远程。

日志记录。每次识别都要记录：时间、抓拍图路径、识别结果、相似度、决策结果。出问题时可以回溯。

降级方案。识别服务不可用时，闸机应该支持刷卡或密码通行，不能完全堵死。

注意：抓拍图涉及个人隐私，存储和传输要加密，保留时间要符合相关规定。建议抓拍图只保留最近30天，过期自动删除。

5. 工具选型与部署建议

5.1 抓拍机与摄像头选型对比

海康的抓拍机我用得比较多，DS-2CD7系列支持人脸抓拍和RTSP预览，配置简单。大华的抓拍机也不错，价格稍低。宇视的抓拍机在逆光场景下表现好。

5.2 服务器配置与GPU选型

后端服务器的配置取决于底库大小和并发量。以10000人底库、4路抓拍机为例：

• CPU：8核以上，用于图像预处理和业务逻辑
• 内存：16GB以上，Faiss索引和模型加载占内存
• GPU：NVIDIA T4或RTX 3060，用于模型推理
• 存储：256GB SSD，用于系统、模型和日志

GPU选型上，T4是性价比之选，功耗低、支持FP16推理。RTX 3060性能更强但功耗高。如果并发量不大，用CPU推理也行，但单张推理时间会从20ms增加到200ms左右。

5.3 部署架构与网络规划

小型项目（1到4路）可以单机部署，所有服务跑在一台服务器上。中型项目（4到16路）建议前后端分离，抓拍机上传图片到图片服务器，识别服务从图片服务器拉图。大型项目（16路以上）需要分布式部署，识别服务做集群，Faiss索引做分片。

网络规划上，抓拍机和服务器建议在同一局域网，减少传输延迟。如果必须跨网段，要确保带宽足够，单张抓拍图约200KB，4路抓拍机每秒各抓1张，需要约6.4Mbps带宽。

6. 实际项目中的经验与踩坑记录

6.1 光照问题的处理

光照是影响识别率的最大因素之一。我做过一个项目，摄像头装在门口，白天逆光严重，晚上补光不足，识别率只有70%多。后来做了几件事：

• 调整摄像头安装角度，避免正对阳光
• 加装补光灯，晚上用红外补光
• 在图像预处理阶段做直方图均衡化，改善对比度
• 底库照片用同款摄像头拍摄，保证光照一致性

调整后识别率提升到95%以上。这里的关键是底库照片和实际抓拍照片的光照条件要尽量一致，否则特征空间会有偏差。

6.2 多人同时通行的处理

通行场景下经常有多人同时出现在画面中。抓拍机通常只抓拍最大人脸，但如果是多人并排走，可能只抓到一个人。解决办法是：

• 抓拍机设置成多人抓拍模式，一次抓拍多张人脸
• 后端对每张抓拍图分别识别
• 闸机联动时，识别到多个人都通过才开闸，或者分别开闸

有些抓拍机支持“人脸去重”功能，同一个人连续抓拍多张只上传一张。这个功能很实用，能减少后端压力。

6.3 底库照片的采集规范

底库照片质量直接决定识别率。我总结了一套采集规范：

• 光照均匀，避免侧光和逆光
• 正脸，头部偏转不超过15度
• 无遮挡，眼镜可以戴但镜片不能反光
• 表情自然，不要夸张表情
• 分辨率不低于640x480
• 每人3到5张，覆盖不同角度

采集时用同款摄像头最好，如果不行，至少保证光照条件相似。我见过用手机自拍照做底库的，识别率惨不忍睹，后来重新采集才解决。

6.4 系统上线后的监控与维护

系统上线不是终点，而是起点。我一般会做这几件事：

• 每天检查识别率统计，低于阈值就排查
• 每周检查底库，删除离职人员，新增入职人员
• 每月检查硬件状态，摄像头镜头清洁、补光灯工作正常
• 每季度做一次全面测试，包括误识率、拒识率、响应时间

监控指标上，重点关注识别率、误识率、平均响应时间、RTSP断线次数。这些指标异常时能提前发现问题。

6.5 一个真实的踩坑案例

最后分享一个真实的坑。有个项目用的是海康抓拍机，RTSP预览正常，但抓拍图一直传不上来。排查了半天，发现是抓拍机的“智能资源分配”设置有问题。海康抓拍机有两种模式：人脸抓拍模式和道路监控模式，默认是道路监控模式，不支持人脸抓拍。要在Web界面里把模式改成“人脸抓拍”，然后重启设备才生效。

这个坑花了我大半天时间，因为RTSP预览正常，很容易误以为是网络问题。后来我养成了一个习惯：拿到新设备先看说明书里的“智能资源”章节，确认工作模式是否正确。

实操心得：海康设备的配置项很多，调试时建议用官方的iVMS-4200客户端，比Web界面直观，而且能看到设备的工作状态和日志。

7. 性能优化与扩展方向

7.1 推理加速的几种手段

如果并发量上来了，推理速度成为瓶颈，可以尝试这几种优化：

模型量化。把FP32模型转成FP16或INT8，推理速度能提升2到4倍，精度损失在1%以内。ONNX Runtime支持FP16量化，TensorRT支持INT8量化。

批处理。把多张抓拍图攒成一批一起推理，GPU利用率更高。但会增加延迟，适合对实时性要求不高的场景。

模型剪枝。去掉模型中不重要的通道，减小模型体积和计算量。这个需要重新训练，门槛较高。

多GPU并行。如果服务器有多块GPU，可以把请求分发到不同GPU上。用Triton Inference Server能方便地做多GPU调度。

7.2 大规模底库的检索优化

底库超过10万人时，Faiss的暴力检索就慢了。这时候需要上近似最近邻（ANN）索引：

• IVF索引：把特征空间聚类，查询时只搜索最近的几个簇
• HNSW索引：基于图的索引，查询速度快，内存占用高
• PQ索引：乘积量化，压缩特征向量，内存占用低但精度有损失

通行场景下，我一般推荐IVF+HNSW的组合，先聚类再图搜索，平衡速度和精度。Faiss的IndexIVFFlat和IndexHNSWFlat都支持。

7.3 多模态融合的扩展思路

人脸识别不是万能的，戴口罩、化妆、整容都会影响识别率。可以考虑多模态融合：

• 人脸+刷卡：人脸识别为主，刷卡为辅，双因素认证
• 人脸+二维码：访客场景下，二维码作为临时凭证
• 人脸+步态：远距离场景下，步态作为辅助特征

多模态融合能显著提升安全性，但成本和复杂度也上去了。根据项目需求选择。

7.4 边缘计算与云端协同

大型项目可以考虑边缘计算+云端协同的架构：

• 边缘端：抓拍机或边缘盒子做检测和特征提取，只上传特征向量
• 云端：做1:N比对和底库管理，支持多站点共享底库

这样做的好处是减少带宽消耗，特征向量只有2KB，比抓拍图小100倍。而且底库可以集中管理，新增人员一次录入，所有站点同步。

边缘端和云端的通信要加密，特征向量虽然不能直接还原人脸，但也属于敏感信息。建议用TLS加密传输，云端存储时也加密。

8. 写在最后的一些个人体会

做安防通行人脸抓拍识别这几年，最大的感受是：算法只是其中一环，工程落地才是真正的挑战。RTSP拉流的稳定性、抓拍图的质量、底库的规范性、系统的容错能力，这些看似不起眼的细节，往往决定了项目的成败。

我见过太多项目，算法选得很好，但抓拍机装歪了，或者底库照片用手机随便拍的，最后识别率上不去，怪算法不行。其实算法很冤，问题出在工程细节上。

另外，隐私保护越来越重要。抓拍图和人脸特征都是敏感信息，存储和传输必须加密，保留时间要合规。我一般建议抓拍图只保留30天，特征向量加密存储，访问要有审计日志。

最后分享一个小技巧：调试阶段把抓拍图、对齐图、特征向量都存下来，出问题时可以逐环节排查。上线后可以关掉这些日志，只保留识别结果和相似度。这样既能快速定位问题，又不会占用太多存储。