4.1.2 渠道适配、验签、防重放、回调与主动查单

本册承接 4.1.1 支付交易领域模型，向退款、对账分册输出已验证、待查、未知三种渠道结果。所有渠道输入均按零信任处理；未知态优先于错误成功或错误失败。

1. 简历关联、事实边界与主线

本册绑定跨境物流充值、支付资金一致性、异步任务与 Runner（执行器）调度。E2（源码流程）事实：IPaymentService 定义结账、取消、退款、退款查询、配置校验、方式查询和令牌刷新；PaymentFactoryService 按渠道代码选择实现；PaymentService 提供渠道支付和配置接口；RechargeCallbackRetryService 对 Stripe（国际支付网关）和 PayPal（国际支付平台）按充值单取得最近会话后入队；StripeCallbackTask 使用队列、业务锁、退避、最大存活时间和失败日志推进主动同步。精确路径见 4.1.0 事实卡。

Airwallex（空中云汇）、Stripe（国际支付网关）、PayPal（国际支付平台）和 PhotonPay（光子易支付）的生产签名算法、密钥轮换、状态枚举、速率阈值与部署配置均待源码或现场核对；下文把未证实部分作为演练设计，不将其表述为现网事实。

2. 渠道确认机制

1.渠道端口、适配器与防腐层

核心支付域只保留统一命令和结果；渠道层转换字段、状态与错误，不能让渠道枚举进入订单和账务。

sequenceDiagram
    participant 客户端
    participant 本地支付单
    participant 渠道适配器
    participant 支付渠道
    participant 回调入口
    participant 查单队列
    participant 账务对账
    客户端->>本地支付单: 创建请求和幂等键
    本地支付单->>渠道适配器: 统一命令
    渠道适配器->>支付渠道: 外部请求号
    支付渠道-->>渠道适配器: 受理或超时
    支付渠道-->>回调入口: 回调事件
    回调入口->>回调入口: 验签和防重放
    回调入口->>查单队列: 待确认时排队
    查单队列->>支付渠道: 主动查单
    支付渠道-->>查单队列: 核验结果
    查单队列->>本地支付单: 条件更新
    本地支付单->>账务对账: 已验证事实

数据演绎 1：演练样例

演练样例：支付单 P2026071401 接收一次同步超时和两次回调。先写入请求快照与会话号，状态为处理中；第一条回调通过验签但事件键已存在，条件更新影响行数为 0，返回已受理；第二条查单结果与金额、币种、商户均一致，条件更新影响行数为 1，状态进入已验证成功。若任何核验项不一致，输出待查冲突，不产生账务事实。验证结论是：重复事件不增加副作用，未知态不被错误压成失败。

热门面试题

1. 问题（基础题）：渠道端口、适配器与防腐层中最需要守住的边界是什么？ 考点：Port（端口接口）/Adapter（适配器）/Anti-Corruption Layer（防腐层）、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：核心支付域只保留统一命令和结果；渠道层转换字段、状态与错误，不能让渠道枚举进入订单和账务。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：渠道端口、适配器与防腐层中最需要守住的边界是什么？ 考点：Port（端口接口）/Adapter（适配器）/Anti-Corruption Layer（防腐层）、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：核心支付域只保留统一命令和结果；渠道层转换字段、状态与错误，不能让渠道枚举进入订单和账务。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：渠道端口、适配器与防腐层中最需要守住的边界是什么？ 考点：Port（端口接口）/Adapter（适配器）/Anti-Corruption Layer（防腐层）、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：核心支付域只保留统一命令和结果；渠道层转换字段、状态与错误，不能让渠道枚举进入订单和账务。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2.统一请求、会话与交易标识

把客户端幂等键、本地支付单号、渠道会话号、渠道交易号分别保存，任何确认都必须能回溯四者。

sequenceDiagram
    participant 客户端
    participant 本地支付单
    participant 渠道适配器
    participant 支付渠道
    participant 回调入口
    participant 查单队列
    participant 账务对账
    客户端->>本地支付单: 创建请求和幂等键
    本地支付单->>渠道适配器: 统一命令
    渠道适配器->>支付渠道: 外部请求号
    支付渠道-->>渠道适配器: 受理或超时
    支付渠道-->>回调入口: 回调事件
    回调入口->>回调入口: 验签和防重放
    回调入口->>查单队列: 待确认时排队
    查单队列->>支付渠道: 主动查单
    支付渠道-->>查单队列: 核验结果
    查单队列->>本地支付单: 条件更新
    本地支付单->>账务对账: 已验证事实

数据演绎 2：演练样例

演练样例：支付单 P2026071402 接收一次同步超时和两次回调。先写入请求快照与会话号，状态为处理中；第一条回调通过验签但事件键已存在，条件更新影响行数为 0，返回已受理；第二条查单结果与金额、币种、商户均一致，条件更新影响行数为 1，状态进入已验证成功。若任何核验项不一致，输出待查冲突，不产生账务事实。验证结论是：重复事件不增加副作用，未知态不被错误压成失败。

热门面试题

1. 问题（基础题）：统一请求、会话与交易标识中最需要守住的边界是什么？ 考点：请求标识与渠道会话、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：把客户端幂等键、本地支付单号、渠道会话号、渠道交易号分别保存，任何确认都必须能回溯四者。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：统一请求、会话与交易标识中最需要守住的边界是什么？ 考点：请求标识与渠道会话、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：把客户端幂等键、本地支付单号、渠道会话号、渠道交易号分别保存，任何确认都必须能回溯四者。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：统一请求、会话与交易标识中最需要守住的边界是什么？ 考点：请求标识与渠道会话、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：把客户端幂等键、本地支付单号、渠道会话号、渠道交易号分别保存，任何确认都必须能回溯四者。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3.受理、成功、失败与未知语义

同步响应最多证明已受理；成功需要确认事实，明确失败才可失败，超时或缺少核验集必须保持未知。

sequenceDiagram
    participant 客户端
    participant 本地支付单
    participant 渠道适配器
    participant 支付渠道
    participant 回调入口
    participant 查单队列
    participant 账务对账
    客户端->>本地支付单: 创建请求和幂等键
    本地支付单->>渠道适配器: 统一命令
    渠道适配器->>支付渠道: 外部请求号
    支付渠道-->>渠道适配器: 受理或超时
    支付渠道-->>回调入口: 回调事件
    回调入口->>回调入口: 验签和防重放
    回调入口->>查单队列: 待确认时排队
    查单队列->>支付渠道: 主动查单
    支付渠道-->>查单队列: 核验结果
    查单队列->>本地支付单: 条件更新
    本地支付单->>账务对账: 已验证事实

数据演绎 3：演练样例

演练样例：支付单 P2026071403 接收一次同步超时和两次回调。先写入请求快照与会话号，状态为处理中；第一条回调通过验签但事件键已存在，条件更新影响行数为 0，返回已受理；第二条查单结果与金额、币种、商户均一致，条件更新影响行数为 1，状态进入已验证成功。若任何核验项不一致，输出待查冲突，不产生账务事实。验证结论是：重复事件不增加副作用，未知态不被错误压成失败。

热门面试题

1. 问题（基础题）：受理、成功、失败与未知语义中最需要守住的边界是什么？ 考点：结果语义与状态映射、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：同步响应最多证明已受理；成功需要确认事实，明确失败才可失败，超时或缺少核验集必须保持未知。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：受理、成功、失败与未知语义中最需要守住的边界是什么？ 考点：结果语义与状态映射、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：同步响应最多证明已受理；成功需要确认事实，明确失败才可失败，超时或缺少核验集必须保持未知。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：受理、成功、失败与未知语义中最需要守住的边界是什么？ 考点：结果语义与状态映射、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：同步响应最多证明已受理；成功需要确认事实，明确失败才可失败，超时或缺少核验集必须保持未知。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

4.能力矩阵与错误分类

适配器把渠道能力显式化，按可重试、不可重试和结果未知分类；缺能力不能伪装成成功。

sequenceDiagram
    participant 客户端
    participant 本地支付单
    participant 渠道适配器
    participant 支付渠道
    participant 回调入口
    participant 查单队列
    participant 账务对账
    客户端->>本地支付单: 创建请求和幂等键
    本地支付单->>渠道适配器: 统一命令
    渠道适配器->>支付渠道: 外部请求号
    支付渠道-->>渠道适配器: 受理或超时
    支付渠道-->>回调入口: 回调事件
    回调入口->>回调入口: 验签和防重放
    回调入口->>查单队列: 待确认时排队
    查单队列->>支付渠道: 主动查单
    支付渠道-->>查单队列: 核验结果
    查单队列->>本地支付单: 条件更新
    本地支付单->>账务对账: 已验证事实

数据演绎 4：演练样例

演练样例：支付单 P2026071404 接收一次同步超时和两次回调。先写入请求快照与会话号，状态为处理中；第一条回调通过验签但事件键已存在，条件更新影响行数为 0，返回已受理；第二条查单结果与金额、币种、商户均一致，条件更新影响行数为 1，状态进入已验证成功。若任何核验项不一致，输出待查冲突，不产生账务事实。验证结论是：重复事件不增加副作用，未知态不被错误压成失败。

热门面试题

1. 问题（基础题）：能力矩阵与错误分类中最需要守住的边界是什么？ 考点：能力矩阵和错误归一、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：适配器把渠道能力显式化，按可重试、不可重试和结果未知分类；缺能力不能伪装成成功。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：能力矩阵与错误分类中最需要守住的边界是什么？ 考点：能力矩阵和错误归一、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：适配器把渠道能力显式化，按可重试、不可重试和结果未知分类；缺能力不能伪装成成功。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：能力矩阵与错误分类中最需要守住的边界是什么？ 考点：能力矩阵和错误归一、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：适配器把渠道能力显式化，按可重试、不可重试和结果未知分类；缺能力不能伪装成成功。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

5.签名原文与验签边界

回调体是未可信输入，必须保留原始字节、确定规范化规则、使用密钥版本验签后才解析业务字段。

sequenceDiagram
    participant 客户端
    participant 本地支付单
    participant 渠道适配器
    participant 支付渠道
    participant 回调入口
    participant 查单队列
    participant 账务对账
    客户端->>本地支付单: 创建请求和幂等键
    本地支付单->>渠道适配器: 统一命令
    渠道适配器->>支付渠道: 外部请求号
    支付渠道-->>渠道适配器: 受理或超时
    支付渠道-->>回调入口: 回调事件
    回调入口->>回调入口: 验签和防重放
    回调入口->>查单队列: 待确认时排队
    查单队列->>支付渠道: 主动查单
    支付渠道-->>查单队列: 核验结果
    查单队列->>本地支付单: 条件更新
    本地支付单->>账务对账: 已验证事实

数据演绎 5：演练样例

演练样例：支付单 P2026071405 接收一次同步超时和两次回调。先写入请求快照与会话号，状态为处理中；第一条回调通过验签但事件键已存在，条件更新影响行数为 0，返回已受理；第二条查单结果与金额、币种、商户均一致，条件更新影响行数为 1，状态进入已验证成功。若任何核验项不一致，输出待查冲突，不产生账务事实。验证结论是：重复事件不增加副作用，未知态不被错误压成失败。

热门面试题

1. 问题（基础题）：签名原文与验签边界中最需要守住的边界是什么？ 考点：签名原文规范化和验签、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：回调体是未可信输入，必须保留原始字节、确定规范化规则、使用密钥版本验签后才解析业务字段。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：签名原文与验签边界中最需要守住的边界是什么？ 考点：签名原文规范化和验签、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：回调体是未可信输入，必须保留原始字节、确定规范化规则、使用密钥版本验签后才解析业务字段。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：签名原文与验签边界中最需要守住的边界是什么？ 考点：签名原文规范化和验签、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：回调体是未可信输入，必须保留原始字节、确定规范化规则、使用密钥版本验签后才解析业务字段。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

6.时间窗、随机数与事件唯一键

验签通过不代表新鲜；时间窗、随机数和事件键共同限制可重放范围，重复键只返回已处理结果。

sequenceDiagram
    participant 客户端
    participant 本地支付单
    participant 渠道适配器
    participant 支付渠道
    participant 回调入口
    participant 查单队列
    participant 账务对账
    客户端->>本地支付单: 创建请求和幂等键
    本地支付单->>渠道适配器: 统一命令
    渠道适配器->>支付渠道: 外部请求号
    支付渠道-->>渠道适配器: 受理或超时
    支付渠道-->>回调入口: 回调事件
    回调入口->>回调入口: 验签和防重放
    回调入口->>查单队列: 待确认时排队
    查单队列->>支付渠道: 主动查单
    支付渠道-->>查单队列: 核验结果
    查单队列->>本地支付单: 条件更新
    本地支付单->>账务对账: 已验证事实

数据演绎 6：演练样例

演练样例：支付单 P2026071406 接收一次同步超时和两次回调。先写入请求快照与会话号，状态为处理中；第一条回调通过验签但事件键已存在，条件更新影响行数为 0，返回已受理；第二条查单结果与金额、币种、商户均一致，条件更新影响行数为 1，状态进入已验证成功。若任何核验项不一致，输出待查冲突，不产生账务事实。验证结论是：重复事件不增加副作用，未知态不被错误压成失败。

热门面试题

1. 问题（基础题）：时间窗、随机数与事件唯一键中最需要守住的边界是什么？ 考点：Timestamp（时间戳）/Nonce（随机数）/事件唯一键、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：验签通过不代表新鲜；时间窗、随机数和事件键共同限制可重放范围，重复键只返回已处理结果。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：时间窗、随机数与事件唯一键中最需要守住的边界是什么？ 考点：Timestamp（时间戳）/Nonce（随机数）/事件唯一键、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：验签通过不代表新鲜；时间窗、随机数和事件键共同限制可重放范围，重复键只返回已处理结果。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：时间窗、随机数与事件唯一键中最需要守住的边界是什么？ 考点：Timestamp（时间戳）/Nonce（随机数）/事件唯一键、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：验签通过不代表新鲜；时间窗、随机数和事件键共同限制可重放范围，重复键只返回已处理结果。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

7.回调幂等与条件更新

先落接收事实与唯一键，再核验并使用条件更新推进状态；终态拒绝迟到事件覆盖。

sequenceDiagram
    participant 客户端
    participant 本地支付单
    participant 渠道适配器
    participant 支付渠道
    participant 回调入口
    participant 查单队列
    participant 账务对账
    客户端->>本地支付单: 创建请求和幂等键
    本地支付单->>渠道适配器: 统一命令
    渠道适配器->>支付渠道: 外部请求号
    支付渠道-->>渠道适配器: 受理或超时
    支付渠道-->>回调入口: 回调事件
    回调入口->>回调入口: 验签和防重放
    回调入口->>查单队列: 待确认时排队
    查单队列->>支付渠道: 主动查单
    支付渠道-->>查单队列: 核验结果
    查单队列->>本地支付单: 条件更新
    本地支付单->>账务对账: 已验证事实

数据演绎 7：演练样例

演练样例：支付单 P2026071407 接收一次同步超时和两次回调。先写入请求快照与会话号，状态为处理中；第一条回调通过验签但事件键已存在，条件更新影响行数为 0，返回已受理；第二条查单结果与金额、币种、商户均一致，条件更新影响行数为 1，状态进入已验证成功。若任何核验项不一致，输出待查冲突，不产生账务事实。验证结论是：重复事件不增加副作用，未知态不被错误压成失败。

热门面试题

1. 问题（基础题）：回调幂等与条件更新中最需要守住的边界是什么？ 考点：Webhook（回调通知）幂等、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：先落接收事实与唯一键，再核验并使用条件更新推进状态；终态拒绝迟到事件覆盖。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：回调幂等与条件更新中最需要守住的边界是什么？ 考点：Webhook（回调通知）幂等、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：先落接收事实与唯一键，再核验并使用条件更新推进状态；终态拒绝迟到事件覆盖。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：回调幂等与条件更新中最需要守住的边界是什么？ 考点：Webhook（回调通知）幂等、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：先落接收事实与唯一键，再核验并使用条件更新推进状态；终态拒绝迟到事件覆盖。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

8.同步超时与回调先后竞争

同步超时不能重建有副作用请求；回调可能先于同步响应，二者都经同一确认入口竞争条件更新。

sequenceDiagram
    participant 客户端
    participant 本地支付单
    participant 渠道适配器
    participant 支付渠道
    participant 回调入口
    participant 查单队列
    participant 账务对账
    客户端->>本地支付单: 创建请求和幂等键
    本地支付单->>渠道适配器: 统一命令
    渠道适配器->>支付渠道: 外部请求号
    支付渠道-->>渠道适配器: 受理或超时
    支付渠道-->>回调入口: 回调事件
    回调入口->>回调入口: 验签和防重放
    回调入口->>查单队列: 待确认时排队
    查单队列->>支付渠道: 主动查单
    支付渠道-->>查单队列: 核验结果
    查单队列->>本地支付单: 条件更新
    本地支付单->>账务对账: 已验证事实

数据演绎 8：演练样例

演练样例：支付单 P2026071408 接收一次同步超时和两次回调。先写入请求快照与会话号，状态为处理中；第一条回调通过验签但事件键已存在，条件更新影响行数为 0，返回已受理；第二条查单结果与金额、币种、商户均一致，条件更新影响行数为 1，状态进入已验证成功。若任何核验项不一致，输出待查冲突，不产生账务事实。验证结论是：重复事件不增加副作用，未知态不被错误压成失败。

sequenceDiagram
    participant 攻击者
    participant 回调入口
    participant 事件存储
    攻击者->>回调入口: 重放旧回调
    回调入口->>回调入口: 校验签名与时间窗
    回调入口->>事件存储: 写入事件唯一键
    事件存储-->>回调入口: 已存在或已过期
    回调入口-->>攻击者: 拒绝且不推进状态

热门面试题

1. 问题（基础题）：同步超时与回调先后竞争中最需要守住的边界是什么？ 考点：超时未知态与先后乱序、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：同步超时不能重建有副作用请求；回调可能先于同步响应，二者都经同一确认入口竞争条件更新。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：同步超时与回调先后竞争中最需要守住的边界是什么？ 考点：超时未知态与先后乱序、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：同步超时不能重建有副作用请求；回调可能先于同步响应，二者都经同一确认入口竞争条件更新。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：同步超时与回调先后竞争中最需要守住的边界是什么？ 考点：超时未知态与先后乱序、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：同步超时不能重建有副作用请求；回调可能先于同步响应，二者都经同一确认入口竞争条件更新。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

9.主动查单与分层确认

回调只提供候选事实，主动查单核验商户、金额、币种和交易号；仍无结果时进入待查而非失败。

sequenceDiagram
    participant 客户端
    participant 本地支付单
    participant 渠道适配器
    participant 支付渠道
    participant 回调入口
    participant 查单队列
    participant 账务对账
    客户端->>本地支付单: 创建请求和幂等键
    本地支付单->>渠道适配器: 统一命令
    渠道适配器->>支付渠道: 外部请求号
    支付渠道-->>渠道适配器: 受理或超时
    支付渠道-->>回调入口: 回调事件
    回调入口->>回调入口: 验签和防重放
    回调入口->>查单队列: 待确认时排队
    查单队列->>支付渠道: 主动查单
    支付渠道-->>查单队列: 核验结果
    查单队列->>本地支付单: 条件更新
    本地支付单->>账务对账: 已验证事实

数据演绎 9：演练样例

演练样例：支付单 P2026071409 接收一次同步超时和两次回调。先写入请求快照与会话号，状态为处理中；第一条回调通过验签但事件键已存在，条件更新影响行数为 0，返回已受理；第二条查单结果与金额、币种、商户均一致，条件更新影响行数为 1，状态进入已验证成功。若任何核验项不一致，输出待查冲突，不产生账务事实。验证结论是：重复事件不增加副作用，未知态不被错误压成失败。

热门面试题

1. 问题（基础题）：主动查单与分层确认中最需要守住的边界是什么？ 考点：主动查单与确认等级、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：回调只提供候选事实，主动查单核验商户、金额、币种和交易号；仍无结果时进入待查而非失败。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：主动查单与分层确认中最需要守住的边界是什么？ 考点：主动查单与确认等级、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：回调只提供候选事实，主动查单核验商户、金额、币种和交易号；仍无结果时进入待查而非失败。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：主动查单与分层确认中最需要守住的边界是什么？ 考点：主动查单与确认等级、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：回调只提供候选事实，主动查单核验商户、金额、币种和交易号；仍无结果时进入待查而非失败。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

10.延迟补偿与查单背压

查询任务必须限流、按渠道隔离并带重试预算；队列积压时降低非终态查询频率，保留人工接管入口。

sequenceDiagram
    participant 客户端
    participant 本地支付单
    participant 渠道适配器
    participant 支付渠道
    participant 回调入口
    participant 查单队列
    participant 账务对账
    客户端->>本地支付单: 创建请求和幂等键
    本地支付单->>渠道适配器: 统一命令
    渠道适配器->>支付渠道: 外部请求号
    支付渠道-->>渠道适配器: 受理或超时
    支付渠道-->>回调入口: 回调事件
    回调入口->>回调入口: 验签和防重放
    回调入口->>查单队列: 待确认时排队
    查单队列->>支付渠道: 主动查单
    支付渠道-->>查单队列: 核验结果
    查单队列->>本地支付单: 条件更新
    本地支付单->>账务对账: 已验证事实

数据演绎 10：演练样例

演练样例：支付单 P2026071410 接收一次同步超时和两次回调。先写入请求快照与会话号，状态为处理中；第一条回调通过验签但事件键已存在，条件更新影响行数为 0，返回已受理；第二条查单结果与金额、币种、商户均一致，条件更新影响行数为 1，状态进入已验证成功。若任何核验项不一致，输出待查冲突，不产生账务事实。验证结论是：重复事件不增加副作用，未知态不被错误压成失败。

热门面试题

1. 问题（基础题）：延迟补偿与查单背压中最需要守住的边界是什么？ 考点：查单队列、退避和抖动、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：查询任务必须限流、按渠道隔离并带重试预算；队列积压时降低非终态查询频率，保留人工接管入口。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：延迟补偿与查单背压中最需要守住的边界是什么？ 考点：查单队列、退避和抖动、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：查询任务必须限流、按渠道隔离并带重试预算；队列积压时降低非终态查询频率，保留人工接管入口。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：延迟补偿与查单背压中最需要守住的边界是什么？ 考点：查单队列、退避和抖动、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：查询任务必须限流、按渠道隔离并带重试预算；队列积压时降低非终态查询频率，保留人工接管入口。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

11.金额币种商户不匹配处置

金额、币种、商户或本地订单不匹配时不可记成功；冻结自动推进并保存脱敏证据，转人工复核或对账确认。

sequenceDiagram
    participant 客户端
    participant 本地支付单
    participant 渠道适配器
    participant 支付渠道
    participant 回调入口
    participant 查单队列
    participant 账务对账
    客户端->>本地支付单: 创建请求和幂等键
    本地支付单->>渠道适配器: 统一命令
    渠道适配器->>支付渠道: 外部请求号
    支付渠道-->>渠道适配器: 受理或超时
    支付渠道-->>回调入口: 回调事件
    回调入口->>回调入口: 验签和防重放
    回调入口->>查单队列: 待确认时排队
    查单队列->>支付渠道: 主动查单
    支付渠道-->>查单队列: 核验结果
    查单队列->>本地支付单: 条件更新
    本地支付单->>账务对账: 已验证事实

数据演绎 11：演练样例

演练样例：支付单 P2026071411 接收一次同步超时和两次回调。先写入请求快照与会话号，状态为处理中；第一条回调通过验签但事件键已存在，条件更新影响行数为 0，返回已受理；第二条查单结果与金额、币种、商户均一致，条件更新影响行数为 1，状态进入已验证成功。若任何核验项不一致，输出待查冲突，不产生账务事实。验证结论是：重复事件不增加副作用，未知态不被错误压成失败。

热门面试题

1. 问题（基础题）：金额币种商户不匹配处置中最需要守住的边界是什么？ 考点：关键核验集与冲突隔离、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：金额、币种、商户或本地订单不匹配时不可记成功；冻结自动推进并保存脱敏证据，转人工复核或对账确认。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：金额币种商户不匹配处置中最需要守住的边界是什么？ 考点：关键核验集与冲突隔离、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：金额、币种、商户或本地订单不匹配时不可记成功；冻结自动推进并保存脱敏证据，转人工复核或对账确认。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：金额币种商户不匹配处置中最需要守住的边界是什么？ 考点：关键核验集与冲突隔离、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：金额、币种、商户或本地订单不匹配时不可记成功；冻结自动推进并保存脱敏证据，转人工复核或对账确认。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

12.重试预算、死信与人工接管

重试不是可靠性的同义词；到期、超过预算或反复冲突的任务进入死信并以双人复核处理。

sequenceDiagram
    participant 客户端
    participant 本地支付单
    participant 渠道适配器
    participant 支付渠道
    participant 回调入口
    participant 查单队列
    participant 账务对账
    客户端->>本地支付单: 创建请求和幂等键
    本地支付单->>渠道适配器: 统一命令
    渠道适配器->>支付渠道: 外部请求号
    支付渠道-->>渠道适配器: 受理或超时
    支付渠道-->>回调入口: 回调事件
    回调入口->>回调入口: 验签和防重放
    回调入口->>查单队列: 待确认时排队
    查单队列->>支付渠道: 主动查单
    支付渠道-->>查单队列: 核验结果
    查单队列->>本地支付单: 条件更新
    本地支付单->>账务对账: 已验证事实

数据演绎 12：演练样例

演练样例：支付单 P2026071412 接收一次同步超时和两次回调。先写入请求快照与会话号，状态为处理中；第一条回调通过验签但事件键已存在，条件更新影响行数为 0，返回已受理；第二条查单结果与金额、币种、商户均一致，条件更新影响行数为 1，状态进入已验证成功。若任何核验项不一致，输出待查冲突，不产生账务事实。验证结论是：重复事件不增加副作用，未知态不被错误压成失败。

sequenceDiagram
    participant 攻击者
    participant 回调入口
    participant 事件存储
    攻击者->>回调入口: 重放旧回调
    回调入口->>回调入口: 校验签名与时间窗
    回调入口->>事件存储: 写入事件唯一键
    事件存储-->>回调入口: 已存在或已过期
    回调入口-->>攻击者: 拒绝且不推进状态

热门面试题

1. 问题（基础题）：重试预算、死信与人工接管中最需要守住的边界是什么？ 考点：重试预算、死信队列与人工接管、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：重试不是可靠性的同义词；到期、超过预算或反复冲突的任务进入死信并以双人复核处理。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：重试预算、死信与人工接管中最需要守住的边界是什么？ 考点：重试预算、死信队列与人工接管、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：重试不是可靠性的同义词；到期、超过预算或反复冲突的任务进入死信并以双人复核处理。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：重试预算、死信与人工接管中最需要守住的边界是什么？ 考点：重试预算、死信队列与人工接管、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：重试不是可靠性的同义词；到期、超过预算或反复冲突的任务进入死信并以双人复核处理。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

13.密钥轮换、脱敏与审计证据

密钥只以受控版本引用，日志记录摘要而不是明文；验签、查单、状态推进和人工动作形成可检索证据链。

flowchart TD
    A[收到不可信回调] --> B{原文验签通过}
    B -- 否 --> C[拒绝并记录脱敏摘要]
    B -- 是 --> D{时间窗和事件键有效}
    D -- 否 --> E[拒绝重放]
    D -- 是 --> F{金额币种商户一致}
    F -- 否 --> G[隔离冲突并查单]
    F -- 是 --> H[条件更新支付单]
    H --> I[账务对账消费已验证事实]

数据演绎 13：演练样例

演练样例：支付单 P2026071413 接收一次同步超时和两次回调。先写入请求快照与会话号，状态为处理中；第一条回调通过验签但事件键已存在，条件更新影响行数为 0，返回已受理；第二条查单结果与金额、币种、商户均一致，条件更新影响行数为 1，状态进入已验证成功。若任何核验项不一致，输出待查冲突，不产生账务事实。验证结论是：重复事件不增加副作用，未知态不被错误压成失败。

热门面试题

1. 问题（基础题）：密钥轮换、脱敏与审计证据中最需要守住的边界是什么？ 考点：密钥轮换和审计证据、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：密钥只以受控版本引用，日志记录摘要而不是明文；验签、查单、状态推进和人工动作形成可检索证据链。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：密钥轮换、脱敏与审计证据中最需要守住的边界是什么？ 考点：密钥轮换和审计证据、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：密钥只以受控版本引用，日志记录摘要而不是明文；验签、查单、状态推进和人工动作形成可检索证据链。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：密钥轮换、脱敏与审计证据中最需要守住的边界是什么？ 考点：密钥轮换和审计证据、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：密钥只以受控版本引用，日志记录摘要而不是明文；验签、查单、状态推进和人工动作形成可检索证据链。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

14.源码映射、项目话术与复习闭环

源码能证明端口、工厂、会话重试与延迟队列存在；生产签名算法、轮换流程和全量状态枚举仍待源码或现场核对。

flowchart TD
    A[收到不可信回调] --> B{原文验签通过}
    B -- 否 --> C[拒绝并记录脱敏摘要]
    B -- 是 --> D{时间窗和事件键有效}
    D -- 否 --> E[拒绝重放]
    D -- 是 --> F{金额币种商户一致}
    F -- 否 --> G[隔离冲突并查单]
    F -- 是 --> H[条件更新支付单]
    H --> I[账务对账消费已验证事实]

热门面试题

1. 问题（基础题）：源码映射、项目话术与复习闭环中最需要守住的边界是什么？ 考点：源码事实和项目表达、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：源码能证明端口、工厂、会话重试与延迟队列存在；生产签名算法、轮换流程和全量状态枚举仍待源码或现场核对。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

2. 问题（原理题）：源码映射、项目话术与复习闭环中最需要守住的边界是什么？ 考点：源码事实和项目表达、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：源码能证明端口、工厂、会话重试与延迟队列存在；生产签名算法、轮换流程和全量状态枚举仍待源码或现场核对。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

3. 问题（项目或故障题）：源码映射、项目话术与复习闭环中最需要守住的边界是什么？ 考点：源码事实和项目表达、不可信输入、幂等状态机。 回答思路：先给出边界，再说明触发顺序、失败分支和证据。 详细答案：源码能证明端口、工厂、会话重试与延迟队列存在；生产签名算法、轮换流程和全量状态枚举仍待源码或现场核对。 处理顺序应先保存可追溯请求事实，再做最小可验证判断；不能确认时只推进到待查或未知。重复和乱序事件通过唯一键、版本或状态条件消除副作用，终态不允许被迟到事件覆盖。任何自动动作都记录触发来源、核验项、前后状态和脱敏摘要，供账务、对账和人工复核使用。 进阶追问：如果外部依赖不可用，是否可以直接重试原请求？ 进阶回答：不可以。对可能产生外部副作用的请求，先依据外部请求号或渠道会话主动查询；查不到才按能力矩阵决定延迟补偿、人工接管或明确失败。

题库与机制的审计边界

该标题只用于把综合题库与最后一个知识小节隔离，避免题库题目被误当作章节题；综合题的字段、答案长度和追问数量仍由下方题库规则单独审计。

3. 高频综合题与追问

1. 问题（综合题）：如何为多渠道支付设计稳定的端口边界？ 口述答案：我会把“如何为多渠道支付设计稳定的端口边界”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

2. 问题（综合题）：如何避免适配器把渠道字段污染核心领域？ 口述答案：我会把“如何避免适配器把渠道字段污染核心领域”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

3. 问题（综合题）：同步下单返回成功时为什么仍不能确认资金成功？ 口述答案：我会把“同步下单返回成功时为什么仍不能确认资金成功”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

4. 问题（综合题）：同步超时后如何避免重复创建渠道交易？ 口述答案：我会把“同步超时后如何避免重复创建渠道交易”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

5. 问题（综合题）：回调先于同步响应到达时如何收敛状态？ 口述答案：我会把“回调先于同步响应到达时如何收敛状态”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

6. 问题（综合题）：如何设计回调验签的原文规范化流程？ 口述答案：我会把“如何设计回调验签的原文规范化流程”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

7. 问题（综合题）：验签通过后为什么仍要校验金额和币种？ 口述答案：我会把“验签通过后为什么仍要校验金额和币种”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

8. 问题（综合题）：如何联合时间窗、随机数和事件唯一键抵御重放？ 口述答案：我会把“如何联合时间窗、随机数和事件唯一键抵御重放”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

9. 问题（综合题）：重复 Webhook（回调通知）怎样做到幂等且可审计？ 口述答案：我会把“重复 Webhook（回调通知）怎样做到幂等且可审计”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

10. 问题（综合题）：乱序成功和失败回调如何保护终态？ 口述答案：我会把“乱序成功和失败回调如何保护终态”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

11. 问题（综合题）：本地支付单找不到对应渠道交易如何处置？ 口述答案：我会把“本地支付单找不到对应渠道交易如何处置”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

12. 问题（综合题）：金额不符的回调为什么不能直接标记失败？ 口述答案：我会把“金额不符的回调为什么不能直接标记失败”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

13. 问题（综合题）：主动查单为什么是未知态的第一选择？ 口述答案：我会把“主动查单为什么是未知态的第一选择”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

14. 问题（综合题）：查单接口超时后状态应如何表达？ 口述答案：我会把“查单接口超时后状态应如何表达”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

15. 问题（综合题）：如何给查单队列设置限流与背压？ 口述答案：我会把“如何给查单队列设置限流与背压”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

16. 问题（综合题）：如何设计退避、抖动和重试预算？ 口述答案：我会把“如何设计退避、抖动和重试预算”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

17. 问题（综合题）：死信任务进入人工接管前需要保留什么证据？ 口述答案：我会把“死信任务进入人工接管前需要保留什么证据”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

18. 问题（综合题）：如何处理商户标识不匹配的渠道结果？ 口述答案：我会把“如何处理商户标识不匹配的渠道结果”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

19. 问题（综合题）：为什么渠道能力矩阵不能只放在文档里？ 口述答案：我会把“为什么渠道能力矩阵不能只放在文档里”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

20. 问题（综合题）：如何对渠道错误做可执行的分类？ 口述答案：我会把“如何对渠道错误做可执行的分类”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

21. 问题（综合题）：如何在密钥轮换期间兼容历史回调？ 口述答案：我会把“如何在密钥轮换期间兼容历史回调”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

22. 问题（综合题）：日志脱敏如何兼顾排障和密钥安全？ 口述答案：我会把“日志脱敏如何兼顾排障和密钥安全”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

23. 问题（综合题）：如何用条件更新避免并发回调重复记账？ 口述答案：我会把“如何用条件更新避免并发回调重复记账”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

24. 问题（综合题）：支付成功确认为什么要分层而非只信一种信号？ 口述答案：我会把“支付成功确认为什么要分层而非只信一种信号”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

25. 问题（综合题）：如何处理渠道回调长期缺失？ 口述答案：我会把“如何处理渠道回调长期缺失”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

26. 问题（综合题）：如何处理回调、查单和对账给出冲突结论？ 口述答案：我会把“如何处理回调、查单和对账给出冲突结论”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

27. 问题（综合题）：Stripe（国际支付网关）源码事实可以怎样用于面试表达？ 口述答案：我会把“Stripe（国际支付网关）源码事实可以怎样用于面试表达”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

28. 问题（综合题）：PayPal（国际支付平台）源码事实可以怎样用于面试表达？ 口述答案：我会把“PayPal（国际支付平台）源码事实可以怎样用于面试表达”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

29. 问题（综合题）：Airwallex（空中云汇）与 PhotonPay（光子易支付）为什么不能猜测签名规则？ 口述答案：我会把“Airwallex（空中云汇）与 PhotonPay（光子易支付）为什么不能猜测签名规则”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

30. 问题（综合题）：如何把失败恢复限制在单一渠道故障域内？ 口述答案：我会把“如何把失败恢复限制在单一渠道故障域内”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

31. 问题（综合题）：如何将支付确认结果交给后续账务与对账？ 口述答案：我会把“如何将支付确认结果交给后续账务与对账”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

32. 问题（综合题）：跨境物流订单的充值场景如何复用渠道确认模型？ 口述答案：我会把“跨境物流订单的充值场景如何复用渠道确认模型”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

33. 问题（综合题）：如何向面试官说明零信任和未知态优先？ 口述答案：我会把“如何向面试官说明零信任和未知态优先”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。排障时按请求号、会话号、事件键、渠道交易号和状态迁移时间线还原证据，先止住自动副作用，再决定查单、对账、退款或人工补偿。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

34. 问题（综合题）：如何建立支付回调故障的线上排查闭环？ 口述答案：我会把“如何建立支付回调故障的线上排查闭环”放进一条以不可信输入为起点的确认链，而不是把某个同步返回或单条回调当作资金事实。首先在本地支付单创建时冻结金额、币种、商户归属、客户端幂等键、统一请求号和渠道会话，并给每次外发生成独立外部请求号；这样网络断开后仍能判断应该查哪一笔，而不是凭时间重新创建。渠道适配器只负责协议字段、状态和错误的转换，核心域只接收已受理、明确失败、候选成功、待查这类统一语义。收到回调时，先按原始字节与签名头做验签，再校验时间窗、随机数和事件唯一键；任何失败都留下脱敏摘要并拒绝推进。验签通过后还要核对本地单、渠道交易、金额、币种和商户，缺一项或发生冲突就进入待查隔离区。随后使用带允许来源状态的条件更新推进支付单，影响行数为零时读取既有结果，不能重复记账。同步超时、回调乱序或查询超时都保留未知态，由限流的查单队列按退避和预算继续确认；超过预算进入死信和人工双人复核。账务与对账只消费已验证的不可变事实，因此渠道故障不会越过边界污染资金结果。面试中我会明确区分源码能证明的接口、队列和锁，与仍待源码或现场核对的生产签名版本、密钥轮换和告警配置。此外，我会把渠道限流、队列积压、每次查询耗时、预算消耗、死信数量和人工处理时长放入同一审计视图；异常窗口先收紧查单并暂停新的外部写操作，再用已保存的证据逐笔恢复，避免补偿任务放大流量或制造第二次扣款。

• 对应机制
• 追问：为什么不能只依赖分布式锁？直接回答：锁只能减少并发，唯一键和条件更新才决定正确性。
• 追问：查单也失败怎么办？直接回答：保持未知并按预算延迟查询，达到边界后进入死信人工核验。
• 追问：什么时候允许记账？直接回答：仅在渠道结果、金额、币种、商户和本地单全部核验通过后。

4. 本册复习清单

• 能区分受理、候选成功、已验证成功、明确失败、待查和未知，不用同步超时推断失败。
• 能画出客户端、本地支付单、渠道适配器、支付渠道、回调、验签防重放、查单队列、条件更新、账务对账的完整时序。
• 能解释端口、适配器、防腐层、能力矩阵、错误分类、外部请求号和渠道会话的分工。
• 能说明重复、乱序、伪造、金额不符、回调先到、超时与重放的恢复边界。
• 能明确哪些结论来自本地源码，哪些生产规则仍待源码或现场核对。