快速开始
集成 / SDK
用户验证
企业验证
交易监控
更新日志概述
活体检测报告中的警告会标记 Didit 在执行活体检测期间观察到的每项情况。它们会记录在liveness_checks[] 每个项目的 warnings[] 数组中（参见活体检测报告），且 feature 设置为 "LIVENESS"。每个条目均遵循通用的警告对象结构：feature、risk、additional_data、log_type、short_description、long_description、node_id。
每个警告包含三个层级：
risk代码：供您在代码中进行匹配的稳定标识符（如下列代码所示）。log_type：information、warning或error之一。自动拒绝风险始终为error。对于可配置风险，它派生自配置的操作：无操作 →information，审核 →warning，拒绝 →error。对于基于阈值的风险（LOW_LIVENESS_SCORE、LOW_FACE_QUALITY），当数值跨过拒绝阈值时为error，仅跨过审核阈值时为warning。- 决策影响：相同的路由机制决定了活体检测报告的
status：审核操作将其变更为In Review，拒绝操作（或任何自动拒绝风险）将其变更为Declined，无操作则保持不变。
PASSIVE 时触发（多张人脸、质量和亮度检查）。下表列出了完整的活体检测风险代码及其严重程度，不存在其他活体检测风险代码。
自动拒绝条件
以下风险始终会将活体检测报告（以及会话）强制置为Declined，且 log_type: "error"：
当触发
NO_FACE_DETECTED 时，LOW_LIVENESS_SCORE 会被抑制（因为没有可评分的人脸）。
可配置的验证设置
在 Didit 控制台中，活体检测风险归类在以下工作流设置下：生成的警告
核心活体检测
采集通道完整性
客户端在采集时报告的注入攻击信号。与呈现攻击（在真实摄像头前放置伪造物）不同，这些信号描述的是摄像头视频流本身被替换或拦截的情况。 每项均可在工作流中单独配置，且默认为无操作，因此启用该功能后，在您主动配置之前不会改变任何决策。浏览器不会向任何供应商公开操作系统级别的摄像头源证明，因此在 Web 端，这些信号属于辅助佐证而非确凿证据。在 Web 端，结论为
null 意味着未确定（在授予摄像头权限之前设备标签不可用），且绝不会触发风险。FRAME_INJECTION_SUSPECTED 报告的原因：它是通过设备环境（即渲染栈和 User-Agent 中报告的设备型号）来检测的，而非依赖摄像头名称。从设备环境中发现的结果会带有 additional_data.reason: "emulated_capture_device"，以此与活体模型自身的帧分析结果区分开来。
从浏览器检测设备环境属于辅助证据，而非确凿证明，坚决的攻击者可以对其进行干扰。原生移动端 SDK 能够报告浏览器无法感知的更强、更底层的操作系统级完整性信号（模拟器、已 Root 或越狱设备、运行时挂钩、附加调试器），在设备与运行时完整性下均有各自的可配置操作。这些信号显著提高了攻击者的成本，但仅凭它们自身并不能证明采集来自真实设备。设备完整性信号独立于活体检测方法，因此可与 Passive、3D Flash 或 3D Action & Flash 中的任意一种结合使用。
录制完整性取证
LIVENESS_VIDEO_ANOMALY 是在服务端对存储的活体录像进行计算的，独立于活体模型。它会检测在多个周期中重复出现的运动序列，这与循环播放的视频流特征相符。
请在您的活体检测或年龄估算节点上设置对应操作：
NO_ACTION 会记录一条信息性发现，REVIEW 可将已得出决策的验证升级为审核中，而 DECLINE 可将其升级为已拒绝。该项检查为异步运行，因此升级结果可能会在初始结果之后产生。已有更严重的决策不会被降级，人工审核决策也会予以保留。
第 2 版的发现包含 forensics_version: 2、repeated_sequence 证据以及 anomaly_reasons 中的 repeated_moving_sequence。传输指标（如 unique_frame_ratio、static_pair_ratio、decoded_fps_ratio 和 max_frame_gap_seconds）仍仅作为诊断数据；它们本身不能作为重放攻击的确凿依据。较早的发现记录了当时使用的检测器版本，不会进行追溯性重新分类。
这是一项保守的附加信号，并非对合成媒体或注入视频的完备检测。没有异常的录像并不能作为活体的充分证明。较短或模糊的采集，以及缺乏可用重放证据的采集，均不会被此项检查标记。缺失或无法读取的录像不会生成此项检查的发现；其他验证检查仍然适用。
跨会话人脸匹配
对于与导入人脸或名单条目人脸（没有对应会话）的匹配，
additional_data 中的 *_session_id、*_session_number 和 api_service 值为 null。
属于同一用户的人脸（相同的 vendor_data，或在可用时为相同的服务商用户）将从整个索引搜索中排除 — 包括重复检测和黑名单筛查。匹配优先级为：黑名单精确 → 白名单精确 → 重复精确 → 黑名单疑似 → 白名单疑似 → 重复疑似 — 这六个互斥代码中每次报告仅会出现一个。DUPLICATED_FACE_NAME_MISMATCH 不属于该优先级组：它是当身份检查同时未通过时，在 DUPLICATED_FACE 之上额外产生的代码，绝不会替代它。additional_data.name_match_score 绝不会包含被比对的姓名 — 仅包含 ID 和分数，因此警告 payload 中不会出现个人身份信息（PII）。
在每份证件上使用不同文字系统书写的姓名（例如一份证件使用希伯来文，另一份使用拉丁文字），即使两个会话属于同一个人，得分也可能低于阈值。在这种特定情况下，当两个会话的身份证件在以下所有方面能够相互佐证时，将不会产生 DUPLICATED_FACE_NAME_MISMATCH：
- 两份证件带有相同的签发国/地区。
- 两份证件之间的标识符完全匹配。
document_number和personal_number可视为等效，因为根据证件类型不同，同一个国民号码可能位于任一字段中。 - 若两份证件均载有出生日期，则该日期相同。
被动活体检测质量（仅在 method = "PASSIVE" 时）
LOW_FACE_LUMINANCE 与 HIGH_FACE_LUMINANCE 互斥 — 亮度要么低于最低值，要么高于最高值，绝不会同时出现。
年龄估算（自适应工作流和 AGE_ESTIMATION 节点）
精确描述字符串
API 会针对每项风险返回以下完全一致的short_description 和 long_description 字符串：
独立被动活体检测 API
独立 活体检测 API 复用了相同的风险代码，但存在一些行为差异：NO_FACE_DETECTED和LOW_LIVENESS_SCORE互斥，仅在检测到人脸时才会运行分数检查。LOW_LIVENESS_SCORE会针对请求中的face_liveness_score_decline_threshold（默认值为 30）触发，并且始终带有log_type: "error"。POSSIBLE_FACE_IN_BLOCKLIST会被视为拒绝（log_type: "error"），而不是人工审核。MULTIPLE_FACES_DETECTED带有log_type: "warning"，而重复人脸风险则保持为信息提示级别。只有error级别的警告才会将独立响应的status变为Declined。- 独立警告条目包含
feature，但不包含node_id。
示例
检测到攻击时自动拒绝
被动采集上的可配置警告
包含 payload 的重复人脸
log_type: "warning"，且活体检测报告的状态为 In Review。若使用默认设置（无操作），它将改为包含 log_type: "information"。api_service 为 null，因为匹配到的人脸来自工作流会话，而非独立的 API 调用。
不同姓名下的重复人脸
DUPLICATED_FACE 保持其自身配置的操作（此处为无操作 - log_type: "information"），而 DUPLICATED_FACE_NAME_MISMATCH 则使用其自身的操作，默认设为审核（log_type: "warning"）。活体检测报告的状态取决于两者中更严重的一个：此处为 In Review，即使仅凭普通重复人脸设置本身并不会对其进行标记。
带有测量数据的录像完整性异常
log_type 为 information，因为配置的操作为 NO_ACTION。为简明起见从本示例中省略的帧投递诊断信息并未触发该检测结果。
警告类型
根据您的应用配置，系统会为每项风险分配一个严重程度级别。三种级别分别为：相关内容
- 活体检测报告 - 完整的报告架构及状态。
- 人脸比对警告 - 配套的 1:1 人脸比对警告。
- Webhook - 活体检测步骤完成后，
session.status.updated会立即携带这些警告。 - 数据模型 - 活体检测 - 包含所有字段的规范架构。
- 数据模型 - 警告对象 -
warnings[]中每个条目的结构。