凌晨一点报警邮件把我和值班工程师同时叫醒某个刚上线的注册通道一夜之间涌进来几千个“真人”账号审核系统全部判定通过。翻完日志才发现对方用的是批量获取的真实身份证照片配合预录视频我们的审核链路只做了姓名、身份证号、银行卡三要素验证压根没有验证“屏幕里的这个人此刻是不是活着的”。那次事故之后我做了一件事在 PHP 风控系统里接入活体识别作为精准合规审查的第一步也就是后来团队里常说的“V1 步骤1”。这篇文章把当时的方案、代码和踩过的坑完整写一遍给同样在用 PHP 做风控开发、准备上活体识别的同学一条能直接参考的路。1. 风控合规审查里活体识别到底补上了哪块短板1.1 传统实名审查的三道门槛大部分 PHP 业务系统做实名审查逃不开这套组合先是姓名、身份证号、手机号的三要素校验再往上一点加银行卡四要素很多平台还接了证件 OCR 识别。这套链路在账号注册、小额支付场景里够用但它有一个天然的盲区它只能证明“信息是真实的”不能证明“操作者就是信息的主人本人”。信息是真的这个前提本身就容易被击穿。身份证照片泄露、手机号被恶意注册、银行卡信息在黑产渠道批量买卖每一个环节都可能让一个攻击者手里握着完全真实的身份资料。更麻烦的是OCR 识别只认证件照片它不会管拍照的人是谁。所以在 2022 年前后我们平台出现了开头那一幕黑产用“身份证照片 预录点头视频”的组合把自动化脚本包装成了“有真实信息、有真人动作”的合规用户直接把注册、领券、拉新奖励的羊毛薅穿。1.2 为什么偏偏用活体识别要堵住这个缺口业内通行的做法有两类一类是人脸比对一类是活体检测真正落地时通常两者一起用。人脸比对解决的是“你是不是证件上那个人”活体识别解决的是“你现在是不是一个真人在摄像头前”。在风控审查链路里这两个问题都必须回答。只做人脸比对不做活体攻击者拿一张证件照或者一段高清视频照样可以骗过比对只做活体不做人脸比对那只是确认了“有个真人”但这个真人可能是黑产花钱雇来的“模特”和账号实名信息完全对不上。活体识别的核心价值是在原有信息校验和 OCR 之外增加了一道对抗“非真人操作”的防线。它针对的攻击手段非常明确照片翻拍、屏幕翻拍、预录视频重放、3D 面具、头模甚至现在很常见的 AI 换脸。不同服务商对这几类攻击的防御能力有差异但从风控视角看只要能把“非真人媒介”挡住黑产自动化的成本就会快速抬升因为买一包真人的实时动作视频比买一批静态身份证照片贵得多、也麻烦得多。1.3 PHP 在这条链路里的真实角色很多刚接触这个方向的 PHP 开发者会有一个困惑活体识别不是要深度学习、目标检测那一套吗PHP 能做吗我的答案是能把调用链做好就是 PHP 的本分也是利润最高的部分。活体识别算法本身实践中几乎不会用 PHP 去训练和推理那是 Python 视觉服务、C 推理引擎甚至专门硬件盒子的活。但在真实的业务系统里算法只是一段能力它需要被“编排”进业务流客户端采集视频 - 上传到你的服务器 - 你调用第三方活体识别接口 - 拿回活体分数和人脸比对分数 - 落库 - 按风控规则决定放行还是转人工。这套编排、鉴权、状态机、日志审计、数据脱敏的活儿PHP 做得非常顺手。所以不要指望用 PHP 从头写一个人脸活体模型那不是工程方案是学术课题。作为风控开发我们真正要做的事情是选对服务商把接口调用做得稳把结果在业务规则里用得准把后续的人工复核闭环补得全。2. 活体识别的核心机制不同方案怎么选2.1 动作活体与静默活体的区别市面上活体识别方案分两大类先搞清楚它们各自的特点再做抉择。动作活体学术上叫“交互式活体检测”。流程是用户对着摄像头按屏幕随机出现的指令做动作眨眼、张嘴、左右摇头、点头过程中连续采集多帧图像算法判断动作是否连贯自然、人脸轮廓是否有真实的形变。它的优势是防御预录视频的能力强因为指令是随机生成的攻击者没法预料下一秒要求做什么代价是用户体验差一些需要在镜头前配合完成几个动作。静默活体也叫“非交互式活体检测”只需要用户正对摄像头拍一张照片算法通过分析纹理细节、反光特征、图像边缘、甚至结构光/深度信息判断面前是真人脸还是纸片、屏幕、面具。它的优势是体验极好打开摄像头一秒出结果劣势是面对预录视频重放时单纯靠 RGB 图像特征老一代方案翻车概率不低需要依赖红外双目模组或者更好的算法才能压住误判率。风控场景里怎么选我的经验是对于注册、登录这种低门槛环节为了体验可以上静默活体但对于绑卡、大额转账、修改关键资料这种高风险动作至少要用动作活体最好是“动作活体 人脸比对 人工复核”三层一起上。2.2 单目、双目与红外方案的实战对比算法之外采集硬件也分档次。手机端 App 集成时前端能拿到的摄像头能力不同方案差异就出来了。方案类型采集设备抗攻击能力适用场景主要成本RGB 单目静默普通前置摄像头中等防不住高级面具低风险注册、登录纯算法费用RGB 动作活体普通前置摄像头较高随机指令多帧分析中等风险场景纯算法费用双目/红外活体专用红外摄像头模组高通过活体特征判断照片视频基本失效金融级实名、大额操作硬件模组算法费用3D 结构光前置结构光模组极高直接重建人脸三维结构顶级合规场景、支付硬件成本较高这里有一个常被忽略的点手机 App 内置的红外摄像头模组和公共场所闸机上那种红外双目效果完全不一样。如果你做的是纯线上 App 业务就老老实实按“单目 RGB”去设计不要指望上万台不同型号手机都有红外能力。反过来如果你做的是线下自助终端、柜面辅助审核可以直接上双目红外方案它对光线、妆容、面具的鲁棒性明显更好。2.3 活体检测与人脸比对的边界划分活体识别只是第一道门别把“活体检测通过”直接等同于“实名审查通过”。在风控链路里这两件事必须分开建模。活体检测回答的是“这帧画面里是否是活人生物特征”。人脸比对回答的是“当前活体人脸和证件底图/历史底库是否是同一个人”。我习惯把这条链路设计成采集原始视频和自拍照调用活体检测接口拿活体判定和活体分数活体通过后再对人脸做特征提取和比对比对通过后继续走三要素、证件 OCR 等其他核验所有结果聚合后落到风控规则引擎里决策顺序上有一个隐性要求一定先把活体过了再去做底库比对。原因很简单人脸比对查询通常按相似度拉取候选集如果这一步把翻拍的照片特征也拉进去了黑产传一堆照片就能套取别人的身份信息反而暴露底库。先挡活体再做比对可以大幅减少底库被恶意批量探测的风险。3. PHP 端集成落地接口设计、签名与完整调用链路3.1 流程编排与审核状态机设计接入之前先把状态机定好。我见过太多项目接口调通了结果一到线上就乱回调重复、超时没结果、人工复核无处安放根源都是状态机没设计清楚。我们当时用的审核状态枚举大概是这样的PENDING用户提交后等待进入活体识别流程PROCESSING已调用活体识别服务等待返回PASSED活体和人脸比对都通过自动放行FAILED活体未通过或有明确风险信号直接拒绝MANUAL_REVIEW分数落在可疑区间转人工复核EXPIRED采集的视频或审核会话超时需要重试对应的业务表结构我简化一下实际项目里还会加分布式 ID、创建人字段等CREATE TABLE audit_record ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, request_id VARCHAR(64) NOT NULL COMMENT 幂等键保证回调与查询唯一, user_id VARCHAR(64) NOT NULL, biz_scene VARCHAR(32) NOT NULL COMMENT register/login/bind_card/withdraw, liveness_request_id VARCHAR(128) NULL COMMENT 服务商侧返回的请求ID, liveness_status TINYINT NOT NULL DEFAULT 0 COMMENT 0-PENDING 1-PROCESSING 2-PASSED 3-FAILED, liveness_score INT NULL COMMENT 活体分数 0-100, face_compare_score INT NULL COMMENT 人脸比对分数 0-100, quality_score INT NULL COMMENT 采集质量分辅助判断, audit_status TINYINT NOT NULL DEFAULT 0 COMMENT 最终审核状态对应状态机, operator_id VARCHAR(64) NULL COMMENT 人工复核人, remark VARCHAR(255) NULL, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_user_scene (user_id, biz_scene), KEY idx_status_time (audit_status, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT统一审核记录表;这个表是整条链路的“地面”后面所有异步回调、人工复核、报表统计都从它来取数。request_id 一定要在入库时就用唯一索引兜底防止重复提交产生脏数据。3.2 客户端采集与上传接口设计活体识别的源头在客户端这一环直接决定识别效果。服务商一般会给 SDK但采集参数的把关要自己做业务侧约束。以动作活体为例我们落地的采集要求大致是视频格式MP4编码 H.264避免用 H.265/HEVC很多服务端解码器兼容性差时长2 到 5 秒太短特征不够太长传输慢且超时风险高分辨率建议 720p 以上但不要盲目上 4K码率太大会拖慢上传光线正面光源避免背光、阴阳脸、遮半边脸动作按 SDK 返回的随机指令执行不要预录表演式动作前端采集完成后把视频和自拍照通过表单上传到我们自己的 PHP 接口。这一步不建议客户端直连第三方活体服务一是 AppSecret 放客户端等于裸奔二是无法做权限控制和审计。自己的服务端做一个中转顺便剥离客户端的实现细节将来换服务商时前端几乎不用动。// 客户端上传接口接收 multipart/form-data public function uploadAction(Request $request): JsonResponse { $user $request-getUser(); $file $request-files-get(video); $scene $request-get(scene); // 基础校验文件类型、大小、用户会话是否有效 if (!$file || !in_array($file-getMimeType(), [video/mp4, video/quicktime], true)) { return $this-json([code 40001, msg 视频格式不正确]); } if ($file-getSize() 20 * 1024 * 1024) { return $this-json([code 40002, msg 视频大小超限]); } $requestId uuid4(); $record new AuditRecord(); $record-request_id $requestId; $record-user_id $user-id; $record-biz_scene $scene; $record-audit_status AuditStatus::PROCESSING; $record-save(); // 上传到对象存储拿到可访问地址回传给异步任务 $videoUrl $this-storage-putFile(liveness/.$requestId./video, $file); $this-queue-push(new LivenessJob($requestId, $videoUrl)); return $this-json([ code 0, data [ request_id $requestId, expires_in 300, ], ]); }有个细节我把视频存到自己对象存储里而不是直接传给第三方。这样做的理由有两点一是后续人工复核要回看视频必须留底二是如果第三方服务商接口抖动可以本地重推不依赖用户重新上传。视频属于敏感数据对象存储要开私有读权限并且按业务需要设置生命周期策略过保留期自动清理。3.3 活体识别 API 的 PHP 调用与签名服务商的接口风格大同小异基本都要求 POST JSON 或表单上传同时带签名参数。以我接触过的某家平台为例签名规则是AppKey Timestamp Nonce Body 摘要用 HMAC-SHA256 算出一个 sign放在 Header 里。AppSecret 只允许留在服务端环境变量中绝不能出现在代码仓库。// 异步队列消费任务调用第三方活体识别服务 class LivenessJob { public function handle(): void { $config config(liveness.provider); $timestamp time(); $nonce random_str(16); $body json_encode([ video_url $this-videoUrl, scene action_liveness, need_face_compare true, compare_image_url $this-idCardUrl, ], JSON_UNESCAPED_UNICODE); $sign hash_hmac(sha256, $config[app_key].$timestamp.$nonce.$body, $config[app_secret]); $resp Http::withHeaders([ Content-Type application/json, X-App-Key $config[app_key], X-Timestamp $timestamp, X-Nonce $nonce, X-Sign $sign, X-Request-Id $this-requestId, ])-timeout(15)-retry(2, 500)-post($config[endpoint], $body); if ($resp-failed()) { $this-markFailed(provider_timeout, 供应商接口调用失败); return; } $result $resp-json(); if (($result[code] ?? -1) ! 0) { $this-markFailed($result[code], $result[msg] ?? 未知错误); return; } // 核心数据落库 $record AuditRecord::where(request_id, $this-requestId)-first(); $record-liveness_request_id $result[data][request_id] ?? null; $record-liveness_status 2; // PASSED $record-liveness_score $result[data][liveness_score] ?? 0; $record-face_compare_score $result[data][face_compare_score] ?? 0; $record-quality_score $result[data][quality_score] ?? 0; $record-audit_status $this-decideAuditStatus($record); $record-save(); // 触发后续风控规则 event(new AuditPassed($record)); } private function decideAuditStatus(AuditRecord $record): int { // 分数区间80 直接 PASSED60-79 转人工60 FAILED if ($record-liveness_score 80 $record-face_compare_score 75) { return AuditStatus::PASSED; } if ($record-liveness_score 60 $record-face_compare_score 60) { return AuditStatus::MANUAL_REVIEW; } return AuditStatus::FAILED; } }超时和重试是这里最容易踩雷的地方。活体识别接口一般需要几秒到十几秒HTTP 客户端默认超时往往不够。我把超时设置为 15 秒重试两次但重试必须在任务队列里做而不是在 Web 请求里同步循环。原因很简单用户等待响应可以接受但 PHP-FPM 进程是宝贵的一个请求占住 30 秒极端情况下会耗尽所有 worker 进程。更合理的做法是上传接口立刻返回 request_id识别过程全部放到队列里异步跑前端轮询状态或接受回调通知。3.4 结果落库与业务侧闭环活体结果落库之后不能停在那里。它必须和后续的三要素、OCR、名单库、规则引擎连起来形成完整的审查闭环。以注册场景为例我们的实际链路是用户提交手机号、姓名、身份证号前端调用活体识别PHP 服务端异步拿到活体结果活体通过后调用公安文本接口做三要素核验三要素通过后把活体自拍照与身份证底图做人脸比对所有核验项汇总进入规则引擎打分评分高于阈值则放行否则触发增强验证或人工复核人脸比对不一定由活体服务商提供有的团队会单独接公安一所的接口或自建人脸底库。无论技术栈怎么拆业务侧最终关心的只是三件事是否真人、是否本人、信息是否真实。把这三件事做成三个可追溯的字段状态机才不会打架。4. 阈值、日志与代码健壮性上线前的细节打磨4.1 活体分数与人脸比对阈值的设定逻辑阈值定多少是整个风控项目里最容易拍脑袋也最容易出事的地方。定高了大量真实用户被机器误杀客诉飙升定低了黑产钻空子风控形同虚设。我当时走了一遍比较笨但有效的流程拿历史一个月的用户上传数据脱敏后打上标签人工标注出一批“确认真人本人”和“确认攻击样本”再用不同阈值回放画 ROC 曲线看误杀率与漏过率的交点。没有数据样本时可以先按经验值上线然后用线上数据持续校准。常用参考区间业务场景活体分数参考阈值人脸比对参考阈值触发动作低风险社区登录 70 60自动放行中风险实名注册 80 75自动放行高风险大额提现、绑卡 90 85自动放行可疑区间60-7960-74转人工复核明确拒绝 60 60直接拒绝这个区间不是一劳永逸的。黑产工具在迭代服务商的算法也在迭代同一个服务商换了新模型版本之后分数分布可能整体偏移。所以上线后至少要按周观察各分数段的人数占比如果发现通过率骤降或骤升第一时间复查而不是等到客诉爆了再处理。4.2 日志记录与敏感数据脱敏风控系统天然和敏感数据打交道活体视频更是重量级。日志里记录什么、不记录什么直接决定后面会不会被合规问题找上门。我定的规矩是这样的日志不落明文手机号、身份证号必须脱敏手机号只保留前 3 后 4人脸自拍照和活体视频存对象存储私有桶不入数据库数据库只存 URL 和应用侧 request_id对象存储 URL 要带签名时效过期自动拒绝访问防止链接被内部人泄露活体识别服务商侧返回的原始报文 JSON可以全量落日志但要先过滤掉其中的 Base64 图像字段人工复核后台操作全程记录审计日志谁看了哪条视频、哪个证件都要有迹可循视频与图片按保留期策略定期清理过了业务留存期就删别为了“以后也许有用”囤数据这里提醒一下很多服务商会把采集的图片存在自己平台上并且可能允许调用方通过管理后台查看。业务侧要评估这部分的合规风险个人信息的处理要有用户授权依据动手前把授权文案写好别等到出了事再补。4.3 并发、超时与重试策略活体识别并发量看着不大但真实场景里会出现尖峰。比如某天渠道投放拉新注册量是平时的十倍消息队列瞬间积压几千个识别任务。针对这种情况队列消费者要加并发控制不能无限拉高并发去请求第三方否则不是把自己的 Redis 打爆就是把服务商限流逼出来。我们当时用 Laravel 队列的--queueliveness --tries3 --timeout60思路配合消费者端的信号量控制做到单消费者并发 5 路整体 20 个消费者实测能扛住单日十万级调用。重试逻辑也要防“雪崩”。第三方接口返回超时或 5xx 时如果无脑重试两次紧接着再来一次可能会卡在“请求已到达服务商但响应丢失”的状态。我的经验是把重试设计成两段第一段只重试一次间隔 500ms第二段把任务延迟到 10 分钟后再跑如果第二次还是失败就转人工。永远不要无限重试服务商出故障时无限重试只是帮它把故障放大。另外状态机里要有一个“探活”任务定时扫描处于 PROCESSING 状态超过 15 分钟的记录主动向服务商查询结果。因为回调通知有丢失概率不主动探活业务就会一直卡在审核中。5. 踩坑实录真实环境里遇到的三类问题5.1 视频编码与分辨率问题引发的误判上线第一周客服就收到大量反馈安卓用户做动作活体经常失败提示“检测不到人脸”或“活体分数低”。排查后发现问题不是算法拉胯而是部分安卓机默认拍出来的是 H.265 编码视频服务商那边的解码器转码后又清晰度损失特征提取不稳定。解决办法有两个方向客户端采集时显式指定 MediaRecorder 输出 H.264 编码格式并在上传前做转封装处理服务端收到视频后如果发现是 H.265调用转码服务统一转成 H.264 再提交给活体接口直接在 PHP 进程里调 ffmpeg 转码也能做但要控制转码进程数量避免把 CPU 打高。我们用了对象存储配合函数计算方式做异步转码PHP 端只负责提交和回调处理对主链路零侵入。这一类问题和算法没有关系完全属于工程细节但在线上就是真实地扎人。5.2 回调重复通知与乱序处理活体识别服务商一般支持“同步返回 异步回调”两种模式。异步回调一旦网络抖动同一个审核结果会推送两三次。如果代码没有幂等处理重复回调会把状态机从 MANUAL_REVIEW 覆盖回 PASSED造成严重事故。我的处理方式很简单回调处理器第一行先查 request_id如果发现该记录已经处于终态PASSED / FAILED / MANUAL_REVIEW直接忽略本次回调再通过 Redis 锁保证同一 request_id 的多个回调串行处理。回调里带的时间戳也要和本地 update_time 比较只有更新的结果才有资格覆盖旧结果防止乱序。public function callbackAction(Request $request): JsonResponse { $requestId $request-input(request_id); $lockKey liveness:lock:.$requestId; if (!Redis::set($lockKey, 1, NX, EX, 10)) { return $this-json([code 0, msg duplicated]); } try { $record AuditRecord::where(request_id, $requestId)-firstOrFail(); if (in_array($record-audit_status, [AuditStatus::PASSED, AuditStatus::FAILED], true)) { return $this-json([code 0, msg already_final]); } // 更新状态与分数 } finally { Redis::del($lockKey); } }5.3 测试环境正常、线上却大量失败的表象与真相真正上线前我们一直以为测试环境就是天下太平模拟的视频全部通过阈值也没有异常。结果灰度开始后失败率直接飙到 30%本地完全复现不出来。最后发现三个叠加因素线上用户大多在弱光环境自拍测试用的是办公室灯光活体质量分骤降部分用户习惯戴帽子、口罩或侧脸对着镜头动作活体的关键点追踪不完整灰度放量时低端安卓机的摄像头帧率只有 15fps动作指令来不及捕捉这类问题无法靠调代码彻底解决我的应对是分三步一是把质量分纳入决策质量分太低时不让进入识别流程而是提示用户“请在光线充足的地方正对镜头”二是将活体失败后的重试次数设为 3 次每次失败都记录原因三是上线前做一轮模拟不同光线环境的测试视频集不要只用理想素材验证。6. 合规审查的边界与最后一道人工复核6.1 活体通过不等于身份真实必须把话说透活体识别能证明“镜头前有真人”人脸比对能证明“这个真人与身份证上的照片高度相似”但一个黑产团伙完全可以雇佣真人、整容或者利用双胞胎关系来完成这两道验证。所以我对“精准合规审查”的理解是活体识别只是审查链路的一个强信号不是终点。完整的合规审查还需要依赖多个信号源的交叉验证。比如设备指纹同一设备是否短时间内关联多个实名信息行为序列提交实名到完成活体识别的时长是否异常位置信息设备所在地与身份证归属地是否明显冲突名单库关联手机号、硬件 ID 是否命中黑名单设备人工复核人工查看采集视频、比对历史照、核验风险标注活体识别是把这个信号源链条的第一环做扎实后面每一环都得分清责任形成闭环。6.2 风控事件分级与处置策略当用户审查链路中某个环节异常应该按风险级别做差异化处置而不是一刀切拒绝。事件类型风险等级处置策略活体分数 60-79 但人脸比对通过中转人工复核24 小时内完成活体分数低于 60高拒绝并做告警加入观察名单人脸比对分数低于阈值但有活体中重新采集自拍照走二次比对活体通过但三要素核验失败高拒绝触发账号安全提醒复核后仍无法确认身份高冻结业务权限引导用户通过线下柜面办理这个表格是对所有业务场景通用的但每个场景还要结合历史数据调权重。比如注册场景允许稍微放宽大额提现场景就必须用最高规格。我们当时是搞了一个简单的配置化规则引擎把阈值、处置动作都做成可配置项业务方提需求时改配置就能上线不用每次改代码发布。6.3 从“步骤1”继续扩展的方向“V1 步骤1”这个名字本身就说明后面还有步骤2、步骤3。在完成了活体识别接入、人脸比对、规则引擎和人工复核闭环之后我在实际项目中感受到的几个值得继续深挖的方向把活体识别日志、规则命中、人工复核结论统一沉淀成特征表为后续引入评分卡或风控模型准备数据将活体识别能力下沉到统一认证服务供账号中心、支付、客服等多个系统复用而不是每个业务方各接一遍对已通过的审核记录做“抽审召回”定期随机抽取一部分重跑一遍识别服务检测历史攻击样本是不是在被算法更新后才会暴露如果业务量继续涨可以考虑自建人脸底库用开源模型做特征提取把比对时延从秒级降到百毫秒级最后再分享一个小经验接入活体识别这件事最耗时间的不是写那几十行调用代码而是把状态机、超时重试、日志脱敏、人工复核这些“配套工程”想清楚。服务商的能力大同小异拉开差距的从来都是工程细节和业务闭环。先把 V1 步骤1 走完整走扎实后面往上加能力就顺了。