4.1.0 业务知识图谱、迁移账本与项目事实映射

范围：本册只建立迁移边界、知识图谱、证据边界和全模块验收索引；不替代后续分册的机制正文。根文档 ../40-支付资金一致性与项目话术.md 是只读基线，任务 1 不移动、不改名、不格式化它。

1. 基线与迁移约束

1.1 根文档基线与可复核口径

基线采集日期为 2026-07-14。采集命令为 wc -l、rg -n '^(#|##|###|####)|^```mermaid|^\\|'、六字段标签计数和 shasum -a 256。根文档为 1085 行、39 个旧 ### 标题、9 幅 Mermaid（图表语法）图、13 张表共 94 个表格行、6 组数据演绎、6 段排障、5 段项目话术；旧题总数为 67，其中 42 道章节题与 25 道综合题。哈希为 113a1eaf3151f776025f3dcdcc95980954641c51d716926b908813c0b53b328e。

根哈希若变化，停止迁移收口：重新执行上述命令、重新标定行范围、补齐新增或变化资产的稳定标识，再讨论目标锚点。哈希相同不等于内容正确，但它保证账本面对的是同一份根资产。

热门面试题

1. 问题：为什么拆分知识库前要记录根文档哈希？ 考点：基线、并发编辑、可追溯性。 回答思路：先说明哈希保护的对象，再说明发现变化后的动作。 详细答案：哈希把“我看过一份文档”变成可复核的版本指纹。拆分期间若根文档被其他协作者修改，旧标题的行号、题目数量和图表边界都可能漂移；继续套用旧账本会导致漏迁或重复迁。这里的哈希只用于检测内容是否变化，不把它误当作业务正确性证明。变化后应重新统计、保留新的基线和差异说明，再把新增资产补进唯一账本。 进阶追问：哈希一致是否足以证明迁移正确？ 进阶回答：不足。还要核对稳定标识唯一性、目标路径和锚点、资产计数守恒、链接状态以及后续分册的实际内容。

2. 问题：为什么要把 67 道旧题拆成章节题和综合题两类计数？ 考点：题库结构、迁移粒度、验收。 回答思路：解释两类题的学习职责不同，不能用总数掩盖缺失。 详细答案：章节题紧邻概念，用于检验基础、原理和项目或故障表达；综合题要求跨领域口述、追问与真实链接。二者即使总数相同，迁入目标、答案长度和验收方式也不同。账本分别记录后，后续可以确认某分册没有只迁正文却遗漏题目，也能避免把一个综合题误写成三道零散问答来凑数。 进阶追问：旧题标题与旧知识标题重合，为什么仍各自编号？ 进阶回答：标题是目录资产，题目是学习资产；它们可能指向同一主题，却有不同的迁入方式和验收字段，必须独立守恒。

3. 问题：发现根文档哈希变化时，为什么不能直接覆盖账本？ 考点：协作边界、证据链、非破坏性。 回答思路：指出覆盖会丢失变化证据，并给出重新建账步骤。 详细答案：直接覆盖会抹掉“哪些资产来自旧基线、哪些由并发编辑新增”的证据，后续无法解释漏项来自哪里。正确动作是保留本次基线记录，采集新哈希和新统计，比较旧稳定标识的标题与行范围；未变化项沿用标识，新增项追加标识，改名项记录别名关系。迁移账本是审计材料，不应以方便为理由把并发改动压平。 进阶追问：行号漂移但标题不变，稳定标识应变吗？ 进阶回答：不变。稳定标识绑定内容身份，行范围是可更新的定位属性；只有内容被拆分、合并或实质替换时才记录关系变化。

1.2 迁移恒等式与零弃用规则

本账本使用两层恒等式。完成态：旧知识小节 39 = 已迁入 + 已拆分迁入 + 明确弃用 0；旧资产总数 145 = 各目标迁入记录 145 + 明确弃用 0。当前态：七个目标分册尚未创建，因此实物迁入为 0 / 145，但 145 个旧资产均已分配一个且仅一个“目标代码路径 + 预期锚点文本”。145 来自 39 + 67 + 9 + 13 + 6 + 6 + 5，依次对应知识标题、题、图、表、演绎、排障和项目话术。这不是坏链接，也不是声称已经迁入；后续任务创建目标文件后才可把链接状态改为真实链接和迁入后计数。

“仅交叉引用”仅在目标分册已有同一资产且能保留原始学习价值时使用；当前所有记录都采用“原样迁入、拆分迁入或深化后迁入”，不以删除根内容来制造完成。每一行中的目标锚点是预期文本，例如 支付状态机与未知态，不是当前 Markdown（标记语言）链接；这样既可稳定规划，也不会引用不存在的文件。

热门面试题

1. 问题：迁移恒等式解决的是什么风险？ 考点：资产守恒、遗漏检测、重复检测。 回答思路：把知识资产看作可计数对象，说明等式两端的含义。 详细答案：迁移恒等式把“感觉都搬过去了”改成可检查的守恒关系。左边是根文档可枚举的标题、题、图、表、演绎、排障和话术；右边是每个资产在唯一目标中的迁入记录，加上明确弃用数。弃用固定为零意味着任何资产都不能悄悄消失。若右边少一项就是遗漏，多一项通常是重复映射或统计口径错误。 进阶追问：一个旧图被拆成两幅新图，恒等式如何处理？ 进阶回答：旧图仍只有一条来源记录，处理方式写“深化后迁入”，迁入后计数可以是 2，并在目标锚点中列出两幅新图的预期名称。

2. 问题：为什么当前态和完成态要分开写？ 考点：计划与事实、状态透明。 回答思路：说明分册未创建时不能伪造完成状态。 详细答案：完成态描述任务全部结束时必须满足的不可变约束；当前态描述此刻磁盘上真实存在的内容。把二者混在一起会让“已规划目标”被误读为“已经迁入”，也可能让后续代理跳过真正的复制、深化和链接校验。分开后，账本既能指导下一步，又不夸大当前交付。 进阶追问：零弃用会不会阻碍内容重构？ 进阶回答：不会。零弃用禁止的是学习资产无证据消失，不禁止重组、合并、拆分或深化；这些操作必须记录来源与目标关系。

3. 问题：为什么预期锚点不能写成不存在的链接？ 考点：链接完整性、渐进式交付。 回答思路：区分文本计划和可导航链接。 详细答案：不存在的链接会在读者点击时失败，也会让自动审计把未来计划误判为当前质量问题。当前应以代码格式记录目标路径和预期标题，清楚声明它是待创建目标；只有文件存在、标题落地且相对路径可解析后，才将其转为真实 Markdown（标记语言）链接。这个顺序保护了可读性和审计信号。 进阶追问：目标文件创建后只改链接状态可以吗？ 进阶回答：不够，还要更新迁入后计数、处理方式、复核人和实物迁入总数，并重新验证恒等式。

1.3 旧标题与旧题的唯一迁移账本

以下表中“目标”均为代码路径与预期锚点文本，刻意不写成链接。复核人统一记为“任务 1 执行者，待后续任务复核”；“迁入后计数”是当前实物计数，目标未创建前均为 0。每个 legacy-40-* 只出现一次。

热门面试题

1. 问题：如何证明一个旧标题只有一个目标？ 考点：唯一映射、稳定标识、账本查询。 回答思路：说明以稳定标识而非标题文本做唯一键。 详细答案：标题可能重复、改名或被拆分，因此不能只搜索自然语言标题。账本以 legacy-40-h01 至 legacy-40-h39 为唯一键，每一键只占一行，行内只给出一个目标文件和一个预期锚点。后续若拆成多段，仍保持一个来源行，在处理方式中说明拆分并列出目标内部的子锚点，而不是复制来源标识。 进阶追问：为什么旧综合题标题也要放在标题账本？ 进阶回答：它们在根文档中就是 ### 目录节点，读者导航与迁移反向定位需要保留这个层面的身份。

2. 问题：账本中的“深化后迁入”是什么意思？ 考点：迁移质量、原意保留、增量扩展。 回答思路：说明不是抄写，也不是替换原有结论。 详细答案：深化后迁入表示保留旧资产提出的核心问题和约束，同时在对应分册补上状态、失败分支、证据边界、数据演绎或排障闭环。它适用于旧文档已有方向但不足以承载高级面试表达的内容。深化必须能反向解释旧内容，而不能借机把未证实的渠道规则或生产指标写成事实。 进阶追问：原样迁入何时更合适？ 进阶回答：当旧题或定义已完整、边界明确且没有新事实需要补充时，可原样迁入，但仍需适配目标分册的术语与链接规范。

3. 问题：为什么账本不直接使用行号作为稳定标识？ 考点：文档演化、稳定性。 回答思路：说明行号可变、内容身份不变。 详细答案：行号会因插入一句说明、修正表格或并发编辑而整体偏移，作为稳定标识会造成无意义的重编号和断链。这里把行范围保留为基线定位信息，把稳定标识绑定到资产身份；后续重统计时更新行范围即可。这样既能回到根文档核验，也能让目标分册长期引用同一来源编号。 进阶追问：标题改名后怎样保持可读性？ 进阶回答：保留稳定标识不变，并在账本增加当前标题和改名前标题的说明；目标锚点按最终读者可理解的标题命名。

1.4 旧题、图表、演绎、排障与话术资产账本

章节题按根中 14 个“热门面试题”块顺序编号 legacy-40-q01 至 legacy-40-q42，每组三题依次为基础、原理、项目或故障；综合题为 legacy-40-q43 至 legacy-40-q67。所有旧图、表、演绎、排障和话术也单独有稳定标识。为避免表格过宽，“目标”使用“文件编号：预期锚点”简写，完整文件名见上一节。

热门面试题

1. 问题：为什么图表和数据演绎也要进入迁移账本？ 考点：非正文资产、可视化证据、学习完整性。 回答思路：说明它们携带的流程与失败分支不可由标题替代。 详细答案：图表包含参与者、时序和状态迁移，数据演绎包含输入、步骤、输出和验证结论；如果只迁正文，读者会失去把抽象原则落到具体场景的桥梁。单独编号后，后续可以要求每幅图真实渲染、每组演绎保留失败分支，并能发现一个分册是否只迁了结论而遗漏了验证材料。 进阶追问：表格行数为什么也记录？ 进阶回答：它能帮助发现表格被误删、截断或合并；行数不是内容质量的唯一标准，但可提供轻量完整性信号。

2. 问题：为什么章节题按三题一组编号？ 考点：题目覆盖、基础原理项目三层。 回答思路：说明固定组别便于复核覆盖而非仅统计数量。 详细答案：每个旧知识小节的三题分别覆盖基础定义、工作原理和项目或故障表达。按三题一组编码能让后续迁移者一眼发现某小节是否少了项目题，或把三题都写成概念题。编号只是索引，实际迁入时仍要按新分册主题深化答案并遵守六字段规范。 进阶追问：遇到旧题答案很短怎么办？ 进阶回答：保留题意和来源编号，补足机制、边界、失败分支和项目表达，不用无关内容填充长度。

3. 问题：如何避免同一旧排障段被多个分册重复复制？ 考点：职责边界、交叉引用、唯一来源。 回答思路：说明主承载分册与引用分册的差别。 详细答案：每个排障段在账本中有唯一主目标，主目标负责完整现象、证据、根因、止血、修复和验证；其他分册如需引用，只保留摘要和指向主目标的真实链接。这样既避免不同分册出现互相矛盾的操作步骤，也让维护者知道哪个位置才是后续更新的权威正文。 进阶追问：主目标尚未创建时能否提前复制摘要？ 进阶回答：不能把摘要当作迁入完成，应先保留账本计划；目标创建后再添加真实交叉引用。

2. 业务知识图谱与事实卡

2.1 交易、资金、库存、履约与物流对象图谱

业务知识图谱把“谁拥有权威事实、何时产生外部副作用、如何回到可证明状态”画清楚。客户发起业务订单或充值意图；卖家、支付渠道、余额账户、账本与结算对象共同处理资金事实；订单、库存和海外仓共同处理履约事实；承运商、包裹、面单和轨迹事件共同处理物流事实。对象间的调用可以失败，权威状态不能因此被同一字段强行承载。

flowchart LR
    C[客户] --> O[业务订单或充值意图]
    S[卖家] --> O
    O --> P[支付单]
    P --> CH[支付渠道]
    P --> L[账本与余额账户]
    P --> F[履约订单]
    F --> I[库存预占与扣减]
    F --> W[海外仓]
    W --> PA[包裹与面单]
    PA --> CA[承运商]
    CA --> TE[轨迹事件]
    L --> ST[结算对象]

热门面试题

1. 问题：为什么支付单不能同时承担履约和账本职责？ 考点：权威状态、职责分治、故障隔离。 回答思路：分别说明三类事实的变化频率和确认来源。 详细答案：支付单回答“本次应付请求是否被确认”，履约单回答“货物是否已由特定仓库处理”，账本分录回答“资金变化为何发生且如何守恒”。三者的确认方、失败模式和终态都不同：渠道回调不能证明仓库出库，仓库回执不能证明分录平衡。分开后可以用关联键串联，也能在某一外部系统未知时只冻结对应流程。 进阶追问：分开后如何让面试表达不显得复杂？ 进阶回答：先讲一个业务订单贯穿全链路，再按支付、资金、履约、物流四类权威事实说明各自的状态和关联键。

2. 问题：知识图谱中为什么把结算对象放在资金链末端？ 考点：费用、账单、结算边界。 回答思路：说明支付成功与结算完成不是同一事实。 详细答案：支付成功只是客户或卖家的某次交易被渠道或内部余额确认；费用可能来自商品、运输、出库和自提等多个来源，需先形成可核对流水和账单，最后才由结算对象推进实际结款。把结算放在末端能避免把“已支付”误写成“已结算”，也便于对账发现中间任一步骤的差异。 进阶追问：源码是否证明了完整结算审批流？ 进阶回答：没有。本册仅确认计费汇总能力与相关文件范围；审批流、账期和实际结算周期均待源码或现场核对。

3. 问题：物流轨迹为什么要独立于面单？ 考点：凭证与事件、乱序保护。 回答思路：对比一次性面单结果和可持续到达的事件流。 详细答案：面单是包裹可运输时取得或上传的凭证，轨迹是承运商在不同时间产生的多个事实。面单成功不等于已出库，更不等于签收；轨迹可能重复、迟到或乱序，因此需要独立事件键和终态保护。分开建模后，面单处理失败可以重拉，轨迹异常可以查询或人工核验，不会污染履约主状态。 进阶追问：已签收后收到运输中事件怎么办？ 进阶回答：保留原始事件用于审计，但不把业务状态从已签收回退；若时间无法排序则标为未知顺序并触发查询或人工核验。

2.2 E1 至 E5 证据事实卡

事实卡只记录源码可证明内容。E1 表示“源码存在”，E2 表示“源码调用、保存或排队流程可读出”，E3 是根文档已有材料，E4 是显式演练设计，E5 是待源码或现场核对。绝不从类名、项目名或渠道名称推断生产配置、版本、金额、成功率或事故。

flowchart TD
    Q[一个业务结论] --> S{能定位源码吗}
    S -->|能| F{能读出调用或保存流程吗}
    F -->|能| E2[E2 源码流程]
    F -->|不能| E1[E1 源码实体]
    S -->|不能| R{仅来自根文档吗}
    R -->|是| E3[E3 根文档资产]
    R -->|否| D{是否明确为演练}
    D -->|是| E4[E4 演练设计]
    D -->|否| E5[E5 待源码或现场核对]

其余三个项目的存在性与相关命中也已检查：hop-java2 命中仓、订单、账单和支付相关代码；hop-java3 命中面单、库存、支付会话和 Airwallex（空中云汇）相关代码；hop-mall 命中订单、余额、费用、退款和仓库前端领域文件。它们未列入本任务的 E1/E2 事实卡，原因是尚未按入口到调用链完成精确核对；不得仅凭命中或名称升级为业务事实。

热门面试题

1. 问题：E1 和 E2 的区别是什么？ 考点：源码证据强度、表述边界。 回答思路：用“存在”与“流程可读出”对比。 详细答案：E1 只证明某个类、任务或字段在源码中存在，因此可说“有独立代码对象”，不能越过调用关系推断实际效果。E2 证明入口、服务调用、保存或入队等流程可从源码读出，因此可以说“该实现调用、保存或排队”。两者都不自动证明生产配置、流量、成功率和运营流程，这些仍需更高质量的现场证据。 进阶追问：看到一个名为补偿的类能否说系统已经实现最终一致性？ 进阶回答：不能。最多是 E1 的对象存在；是否覆盖关键失败分支、是否幂等、是否实际运行均待源码或现场核对。

2. 问题：为什么渠道签名策略必须标为待核对？ 考点：安全事实、证据不足、避免猜测。 回答思路：说明接口字段存在不等于算法和密钥流程已被证明。 详细答案：即使源码接口有 Signature 字段或支付端口有配置校验，也不能推出原文拼接、算法版本、时间窗、密钥轮换和生产密钥管理。安全细节一旦猜错会导致错误实现或误导面试表达。因此本册只记录已看到的接收和转交流程，把具体验签策略标为待源码或现场核对，并列出可验证的文件或配置来源。 进阶追问：面试被问到时怎样回答才稳妥？ 进阶回答：先讲通用设计要求，再明确当前源码已证实的接口边界；未证实的渠道规则说明需以渠道文档和生产配置核对，不编造版本号。

3. 问题：为什么要登记未作为事实卡的项目命中？ 考点：负向边界、调研完整性。 回答思路：说明它避免后续重复扫描和过度推断。 详细答案：登记存在性和相关命中说明七个项目都被检查过，同时明确哪些没有达到 E1/E2 的精确引用标准。这样后续任务可以从已命中的目录继续深挖，也不会把“没有被选为事实卡”误解成“项目不存在”。更重要的是，它把证据缺口公开化，防止项目名称在迁移中被悄悄转述为不受支持的项目事实。 进阶追问：后续如何提升为 E2？ 进阶回答：定位明确入口、读取关键分支和下游调用，记录精确绝对路径及可复述的调用或保存事实，再更新事实卡。

2.3 四类不变量、未知态与证据等级

不变量是系统在成功、失败、超时和补偿后都不能被破坏的约束；它不等于某一张表的当前状态。资金、库存、履约和物流分别拥有权威事实与验证方式。对于外部结果，超时仅说明调用方没有取得结果，不能把未知态压成成功或失败。

stateDiagram-v2
    [*] --> 待确认
    待确认 --> 已确认: 可验证结果
    待确认 --> 未知态: 超时或无响应
    未知态 --> 已确认: 查单或回调证明成功
    未知态 --> 已失败: 查单或回调证明失败
    已确认 --> [*]
    已失败 --> [*]

sequenceDiagram
    participant U as 客户
    participant P as 支付单
    participant C as 支付渠道
    participant Q as 查询任务
    U->>P: 提交支付意图
    P->>C: 发起外部请求
    C--x P: 超时或无响应
    P->>P: 保持未知态
    Q->>C: 按业务键查询
    C-->>Q: 已成功或已失败
    Q->>P: 条件更新确认结果

演练样例 1：资金未知态不记账

输入：支付单 P-100 金额 100，渠道调用超时，本地没有可验证成功结果。步骤：支付单从待确认转为未知态；账本不插入“支付成功”分录；查询任务按 P-100 查单；若返回成功，使用业务键执行一次条件更新和成对分录；若仍无结果，保持未知并纳入对账。输出：余额不因超时而减少。失败分支：重复查询或迟到回调均必须命中同一业务键。验证结论：未知结果不记成功也不记失败。

演练样例 2：库存取消与出库竞争

输入：实物库存 10、有效预占 2、已分配未确认占用 1，可售为 7。步骤：取消任务与出库确认同时到达；二者先读取同一履约单的当前状态，只有合法状态迁移可写库存流水；出库成功则扣减对应占用，取消动作因条件不满足而不释放。输出：不会出现既释放又扣减。失败分支：下游结果未知时不执行两种写入，改为查单。验证结论：每个库存变化都有唯一原因和流水。

演练样例 3：迟到轨迹不回退签收

输入：运单 T-9 已收到签收事件，后到一条事件时间更早的运输中事件。步骤：以承运商、运单号和事件特征计算去重键；保留两条原始事件；比较当前终态与新事件可迁移性，拒绝将签收回退。输出：展示状态仍为已签收。失败分支：若两条事件无法可靠排序，标记未知顺序并创建核验任务。验证结论：审计保留事实，业务状态保护终态。

热门面试题

1. 问题：为什么“超时不是失败”是资金系统的硬约束？ 考点：未知态、外部副作用、资金安全。 回答思路：解释调用结果与业务结果的差别，再给出确认路径。 详细答案：超时只说明当前调用链没有及时收到响应，不说明渠道未扣款，也不说明下游未创建。若把超时直接标失败并允许重试，可能产生重复扣款、重复仓单或重复扣减；若直接标成功，又会虚增资金和履约事实。正确模型保留未知态，以业务键主动查询、接收回调和最终对账来确认，确认前不写成功分录。 进阶追问：未知态能长期存在吗？ 进阶回答：可以暂存，但必须有重试预算、超龄告警、对账归集和人工核验出口，不能无限静默。

2. 问题：库存不变量为什么不能只靠分布式锁？ 考点：并发控制、数据库正确性、审计流水。 回答思路：说明锁降低冲突但不能构成最终事实。 详细答案：锁可能过期、失效、被绕过或在故障恢复时失去上下文，不能单独证明某次释放和扣减的因果关系。库存正确性必须由条件更新、唯一业务流水、合法状态迁移和下游确认共同保证；锁只能作为减少同一业务并发的辅助。即使有锁，取消和出库的竞争仍要在权威存储层被拒绝其中一个非法迁移。 进阶追问：库存负数出现后先做什么？ 进阶回答：先停止相关自动补偿和重复任务，按库存流水、订单状态和下游查询重建事实，再决定补账或人工处置。

3. 问题：轨迹乱序为什么不能简单按接收时间排序？ 考点：事件时间、迟到事件、终态保护。 回答思路：区分事件发生时间与系统收到时间。 详细答案：接收时间反映网络和投递延迟，不能替代承运商事件发生时间；仅按接收时间可能把早发生、晚到达的运输中事件盖过已签收状态。应保存两个时间维度和原始标识，优先使用可信事件时间及终态迁移规则。时间不可比较时不伪造顺序，保持未知并触发查询或人工核验。 进阶追问：为什么仍要保存被拒绝的迟到事件？ 进阶回答：它是审计和问题定位证据，可用于发现承运商数据质量问题；拒绝的是业务状态回退，不是抹掉原始事实。

2.4 设计职责矩阵、正式图资产与全模块验收索引

固定设计思想不是堆叠技术名词，而是把每类失败交给有权证明它的机制：状态机负责合法迁移和终态保护，账本负责不可变资金事实，事务边界把本地原子性与外部副作用分开，事件驱动负责提交后投递与消费幂等，分治给各域保留权威状态，补偿遵循先确认再补做，对账提供闭环证明，未知态避免把超时误判为失败，故障域使渠道、仓库、承运商和任务队列可以独立降级。

flowchart TB
    A[本地意图与状态机] --> B[本地事务]
    B --> C[不可变事实与待投递事件]
    C --> D[外部渠道或仓库]
    D --> E{结果可确认吗}
    E -->|是| F[条件更新与审计]
    E -->|否| G[未知态与查询任务]
    G --> D
    F --> H[对账与差异闭环]

sequenceDiagram
    participant O as 业务订单
    participant I as 库存域
    participant W as 海外仓
    participant R as 恢复任务
    O->>I: 创建有效预占
    O->>W: 创建下游履约单
    W--x O: 请求超时
    O->>O: 保持下游未知态
    R->>W: 按本地业务键查询
    alt 已创建
        R->>O: 绑定下游单号
    else 未创建
        R->>O: 在预算内重试创建
    end

sequenceDiagram
    participant C as 承运商
    participant W as 回调入口
    participant T as 轨迹事实库
    participant P as 轮询任务
    C->>W: 推送轨迹事件
    W->>T: 去重后保存原始事实
    alt 回调缺失或顺序未知
        P->>C: 按运单查询
        C-->>P: 返回轨迹集合
        P->>T: 合并并保护终态
    end

| 正式 PlantUML（开源建模工具）资产 | 计划路径 | 引用分册 | 交付状态 | | --- | --- | --- | | 支付状态与确认 | assets/payment-state-and-confirmation.puml | 01 | 待后续任务创建并渲染 | | 渠道回调与查单 | assets/channel-webhook-query-replay.puml | 02 | 待后续任务创建并渲染 | | 复式账与不变量 | assets/double-entry-ledger-invariants.puml | 03 | 待后续任务创建并渲染 | | 退款对账结算闭环 | assets/refund-reconcile-settlement-closure.puml | 04 | 待后续任务创建并渲染 | | 订单库存海外仓补偿 | assets/order-inventory-warehouse-saga.puml | 05 | 待后续任务创建并渲染 | | 面单承运商轨迹恢复 | assets/label-carrier-tracking-recovery.puml | 06 | 待后续任务创建并渲染 | | 项目故障域与可观测性 | assets/project-fault-domain-observability.puml | 07 | 待后续任务创建并渲染 |

演练样例 4：回调重复的条件更新

输入：同一渠道事件 E-11 连续到达两次，支付单当前为待确认。步骤：首次插入事件键成功，条件更新支付单为已确认并生成待投递事件；第二次插入唯一事件键冲突，读取已处理结果并返回确认响应。输出：只产生一次资金与履约联动。失败分支：若首次事务在写事件后失败，事务回滚后允许安全重试。验证结论：事件键与状态条件共同防重，单靠其中一个不足。

演练样例 5：退款上限与冲正分离

输入：原成功支付 100，已成功退款 60，申请退款 50。步骤：先汇总已成功退款和处理中退款的保留金额；本次请求若会超过原成功金额则拒绝；渠道超时则退款单进入未知态，不先增加成功退款累计。输出：不会出现累计退款 110。失败分支：若内部已入账而渠道明确失败，按独立冲正事实处理，不把冲正伪装成退款。验证结论：退款、冲正和未知状态拥有不同语义。

演练样例 6：账单任务重入

输入：账期内三条费用流水，其中两条已聚合进账单，任务在第三条前中断。步骤：重跑按费用流水唯一键查询已归属账单的记录，只补聚合缺失的一条；账单总额由明细重算；对账发现渠道或结算差异时建立差异项而非直接改总额。输出：账单不重复计费。失败分支：重复任务竞争时由唯一约束或条件更新阻断。验证结论：重入依据是明细事实，不是任务执行次数。

热门面试题

1. 问题：为什么本地事务不能覆盖外部支付或仓库调用？ 考点：事务边界、外部副作用、补偿。 回答思路：说明数据库原子性范围与外部系统确认范围不同。 详细答案：本地事务只能保证本地单据、分录和待投递事件一起成功或回滚，不能让渠道扣款或仓库创建与数据库同一原子提交。把外部调用塞进长事务会增加锁持有时间，也无法消除网络超时造成的未知结果。应先提交本地意图与可审计事实，再用幂等外部请求、主动查询、事件消费和补偿来收敛。 进阶追问：这是否意味着只能最终一致？ 进阶回答：跨外部副作用通常采用可证明的最终一致；域内关键约束仍应通过本地事务和条件更新保持强一致。

2. 问题：为什么补偿前必须先确认？ 考点：重复副作用、查询优先、重试预算。 回答思路：以超时创建仓单为例说明盲目重试的后果。 详细答案：外部请求超时后，对方可能已经完成操作但响应丢失。直接补做会创建重复订单、重复扣款或重复面单，后续再补救代价更高。补偿应先用本地业务键查询外部状态；只有确认未发生或超过明确的失败条件，才在重试预算内执行新动作。仍无法确认时进入人工核验而非无限自动重试。 进阶追问：查询接口也失败怎么办？ 进阶回答：保持未知态，记录请求与响应证据，按退避和最大年龄重试；达到预算后告警并转人工处置。

3. 问题：对账为什么被称为闭环证明而不是普通报表？ 考点：独立事实源、差异处置、恢复验证。 回答思路：说明对账的输入、差异分类和闭环输出。 详细答案：报表可以只展示本地汇总，而对账必须比对相互独立的内部明细、渠道结果和账单或结算事实，识别本地漏记、渠道差异、金额差异和重复记录。对账的终点不是生成差异列表，而是每条差异有原因、处置动作、审计留痕和复核结果。这样才能证明补偿、冲正或重跑没有制造新的不平。 进阶追问：对账能替代实时幂等吗？ 进阶回答：不能。幂等降低实时重复副作用，对账发现历史遗漏和边界故障，两者互补。

综合题分界（非知识小节）

3. 全模块验收与综合题库

本册交付的八个知识型小节均带知识小节审计标记，每节三道六字段题共 24 道；本册有 8 幅 Mermaid（图表语法）图，其中 4 幅为 sequenceDiagram（时序图）；有 11 张表和 6 组完整演练样例；综合题库有 12 道题。复核顺序固定为根哈希、账本唯一性、题目字段与长度、图形渲染、链接、术语和差异检查。后续任务不得据此宣称七个分册已经完成。

sequenceDiagram
    participant M as 迁移执行者
    participant R as 根文档
    participant L as 迁移账本
    participant F as 后续分册
    M->>R: 统计并计算哈希
    M->>L: 写入唯一来源与预期锚点
    M->>F: 创建后迁入资产
    M->>L: 更新真实链接和迁入计数
    M->>R: 再次计算哈希并核对守恒

4. 综合题库

1. 问题：你如何设计一套支付、资金、履约和物流都可追溯的系统边界？ 口述答案：我不会用一张订单表承载全部状态，而是先划分四类权威事实。支付单表达一次应付意图和渠道确认过程，账本分录表达已经发生的不可变资金事实，履约单表达某个仓库对交付任务的处理，轨迹事件表达承运商在时间轴上的原始事实。它们用业务订单、支付单号、履约单号、下游单号和运单号关联，但各自的状态只能由对应证据推进。外部请求超时进入未知态，不能立即判失败或成功；先按本地业务键查单，再依据确认结果做条件更新。资金链要求分录守恒、余额可由有效分录重算、退款累计不超过原支付；库存链要求预占、扣减、释放有唯一原因；履约链要求每个履约单只有一个生效下游创建结果；物流链要求重复和乱序事件不回退签收终态。这样即使渠道、海外仓或承运商其中一方故障，也只隔离对应故障域，靠查询、补偿和对账把事实收敛，而不会把调用超时放大为重复扣款或重复出库。 实现时还要保留可贯穿四域的关联键和原始证据：支付确认可追到渠道会话，履约可追到下游单，包裹可追到面单和轨迹事件。排障先问哪一域拥有事实，再问该域是否已确认，避免跨域服务用猜测覆盖权威状态。恢复完成也不是某个接口返回正常，而是资金、库存、履约和物流四类不变量都能由明细重新验证；若任一域仍未知，就继续保留证据和恢复任务，不把局部成功扩写成整单完成。 此外，读者复盘时应能从一次异常反向定位到支付事件、库存流水、履约映射和轨迹原文，而不是依赖某个当前状态字段猜测过程。这个可追溯性正是跨域拆分后仍能稳定协作的原因。 追问一：为什么不以支付成功直接驱动出库？ 直接回答：支付成功只是资金确认，履约仍要经过库存、仓库接单和出库确认，不能跳过独立的不变量。 追问 2：外部渠道返回成功但本地事务失败怎么办？ 直接回答：保存可查询的业务键，后续主动查单并补记本地事实；补记必须幂等，不能再次发起扣款。 追问 3：如何向面试官证明不是概念设计？ 直接回答：引用源码事实卡中的支付端口、支付单校验、回调任务、面单任务和轨迹任务，并明确未核对部分的边界。

• 根文档的总体架构

2. 问题：迁移账本如何保证根文档资产零弃用，同时不制造不存在分册的坏链接？ 口述答案：迁移的第一步不是创建新目录，而是把根文档冻结为可复核基线。我会记录采集日期、统计命令、行数、标题、题、图、表、演绎、排障和话术数量，并计算内容哈希。然后给每个旧资产一个稳定标识，例如旧标题、旧题、旧图和旧表分别编号；稳定标识绑定内容身份，原始行范围只承担定位作用。账本中的每条来源记录只写一个目标文件代码路径和一个预期锚点文本，同时标明原样、拆分或深化迁入方式、当前实物迁入数和链接状态。由于后续分册此刻尚未创建，目标不能写成可点击链接，只能以代码格式记录路径和预期标题；这样审计不会出现坏链接，也不会假装资产已经迁入。完成态的等式要求旧知识标题和全部旧资产都等于各目标迁入记录加明确弃用零，当前态则如实记录实物迁入为零。收口前重新计算根哈希，若根被并发编辑就重新统计和补账，而不是覆盖他人的新内容。 账本还要把计划目标和实物迁入并列展示，因为目标路径已经分配不代表文件已经存在。后续分册创建时先核对来源，再落地预期锚点、真实链接和迁入计数；若发现一个来源被多处复制，则保留一个主承载位置，其他位置只做交叉引用。这样读者既能从新分册回看原始资产，也能从根资产追踪到唯一承担正文责任的目标，并能在并发编辑发生时区分旧资产和新增资产。 账本也因此是协作协议：任何后续任务都不能跳过稳定标识直接迁移，避免不同执行者把同一旧资产写成彼此冲突的两个权威版本。 追问一：一项旧图拆成两幅新图会破坏守恒吗？ 直接回答：不会，来源图仍是一条记录，处理方式标为深化后迁入，迁入后计数记录为二并列出两个目标锚点。 追问 2：标题改名后稳定标识要不要重编？ 直接回答：不重编；保留稳定标识，更新当前标题和原始行范围，必要时记录别名关系。 追问 3：为什么还要记录表格行数？ 直接回答：行数不能代表质量，但能快速发现迁移时表格被截断、误删或合并的完整性问题。

• 根文档的复习入口

3. 问题：支付请求超时后，怎样避免重复扣款并保持资金账实一致？ 口述答案：超时的核心判断是调用方没有拿到响应，而不是渠道一定失败。我的处理会先把支付单停在未知态，保留请求号、支付单号、渠道会话号和原始响应信息；这个阶段不写支付成功分录，不释放或扣减与支付结果相关的资金。随后由回调或主动查询按业务键确认渠道真实结果：确认成功时，事件唯一键、支付单条件更新、账务分录和待投递事件在本地事务内形成一次可审计事实；确认失败时才终结失败；仍无结果则按重试预算继续查询并进入对账清单。重复回调或重复查询必须命中同一事件键和业务键，第一次生效后后续请求读取既有结果，不能再次入账。余额快照只是查询加速结果，真正可复算的依据是有效分录，且每笔入账要满足借贷守恒。若发现渠道成功、本地无记录，则按查询证据补记而非再次扣款；若本地已记账而渠道明确失败，则按独立冲正事实纠偏。这样把“网络不确定”限制在未知态，而不是让它变成资金事实的猜测。 排查还要区分未发出请求、对方已受理但未回应、回调遗漏和本地提交失败四种位置，因为补救动作不同：未发出才可以安全发起，已受理必须查单，回调遗漏可以补同步，本地失败则补记受控事实。所有恢复动作都以同一支付单和业务键为入口，并记录时间、原始响应和处理结论，避免后续对账只能看到金额而看不到因果链；任何补记前还要复查同一业务键是否已经产生有效分录。 当证据不足时，宁可让业务停留在可见的处理中，也不让看似友好的失败提示诱导用户重复触发不可逆的资金操作。 追问一：为什么不能在超时后直接给用户返回失败？ 直接回答：界面可提示处理中，但业务状态不能写失败，否则用户重试可能触发第二次扣款。 追问 2：主动查询也超时时如何处理？ 直接回答：保持未知态，记录每次查询证据并退避重试；超过预算后转人工核验和对账，不盲目重发支付。 追问 3：分布式锁能防住重复扣款吗？ 直接回答：锁只能降低并发窗口，最终仍要靠事件唯一键、条件更新和账务业务键保证一次生效。

• 根文档的支付回调查单说明

4. 问题：如何从源码事实出发讲多渠道支付，而不猜测渠道生产规则？ 口述答案：我的表达会先区分已经证实的接口边界和待核对的渠道细节。源码中 IPaymentService 提供结账、取消、退款、退款查询、配置模板、配置校验、支付方式查询和令牌刷新能力，PaymentFactoryService 依据渠道代码选择实现；这足以证明存在端口和工厂选择边界。另一个项目的 PaymentService 也提供渠道支付及配置模板和校验接口；回调重试服务可以按充值单取最近会话入队，Stripe（国际支付网关）任务可见队列、锁、退避、最长存活时间和失败日志。这些都可以作为“源码调用或排队流程可读出”的事实。相反，签名原文、算法版本、密钥轮换、生产状态码映射、限流阈值和实际告警策略没有在本册被完整核实，必须明确说待源码或现场核对。设计层面我会建议统一请求号、外部请求号、验签后的事件键、错误分类和主动查单，但把它标为演练设计，不伪装成现网实现。这样的边界既展示设计能力，也避免把渠道名称和类名扩写成没有证据的生产承诺。 面试中我会把源码证据说成当前实现可见的能力边界，把状态机、事件键、查单和对账说成针对该边界的通用可靠性设计，两者之间不偷换。若对方要求具体配置，我会指出待验证的路径或配置来源，而不是给出臆测数字。这个表达方式同样适用于 Airwallex（空中云汇）、Stripe（国际支付网关）、PayPal（国际支付平台）等不同渠道；名称不同不改变确认、幂等和未知态处理的基本原则。 追问一：为什么工厂选择不能等同于完整适配器设计？ 直接回答：工厂只证明按代码选择实现；请求归一化、错误映射、验签和防重放细节仍需阅读具体实现。 追问 2：面试官追问签名算法怎么办？ 直接回答：说明通用验签原则，并如实说当前证据未覆盖具体渠道版本，需要以渠道文档和生产配置核对。 追问 3：回调重试为何还要主动查单？ 直接回答：回调和任务都可能丢失或失败，主动查询提供独立确认通道，最终再由对账发现历史差异。

• 根文档的多渠道接入说明

5. 问题：如何解释余额、冻结、账本分录和渠道流水的关系？ 口述答案：我会把余额账户、账本和渠道流水分成三个层次。余额账户保存可用、冻结和在途等快照，便于业务实时判断；账本分录记录每次资金变化的不可变事实，余额应当能够由同一货币、账套和会计期间内的有效分录代数和重算；渠道流水则是外部支付结果的证据，不能替代内部账务。以冻结支付为例，先把可用金额转入冻结，支付确认后冻结转为消费，取消时冻结解开，退款则建立新的退款事实而不是修改原支付分录。每个变化绑定业务键和唯一流水，重复回调只能读取已经生效的结果。并发扣款的正确性依赖账户余额条件更新或等价的权威存储约束，锁只是减压手段，不能替代数据库层的最终判断。当前源码可确认在线充值流程使用锁和延迟取消队列，也可确认计费汇总返回金额与成本；但不能把这些对象描述成已经证实的完整复式账实现。对于未证实的分录方向、会计期间、冲正策略和生产账套，我会标为待源码或现场核对，并在对账中用内部明细、渠道结果和结算事实发现差异。 恢复余额时，先按账户、币种和期间汇总有效分录，再对比快照和渠道证据，差异必须形成可追溯的纠正事实。这样即使快照写入失败、任务重复执行或人工介入，也能从不可变明细恢复，而不会因为直接覆盖余额丢失因果关系。账户、支付单、退款单和费用单之间通过业务键关联，但它们都不能取代对方的权威事实；这一边界也是防止资金口径在项目演进中被悄悄混淆的基础。 追问一：为什么不能直接更新原资金流水完成退款？ 直接回答：原流水是发生事实，直接修改会抹掉历史；退款应以新分录或新业务事实表达，便于审计和重算。 追问 2：余额快照错了怎么恢复？ 直接回答：按账户和期间汇总有效分录重算快照，同时保留纠正过程和差异证据，不能仅人工改一个余额数字。 追问 3：冻结余额为什么不等于已扣款？ 直接回答：冻结只是限制可用额度，外部支付尚未确认前资金不应被当作已经消费。

• 根文档的余额与账务守恒说明

6. 问题：部分退款、冲正、取消和结算差异为什么不能混为一个状态？ 口述答案：这几个动作面向的事实与时点不同。取消通常发生在支付或履约尚未最终生效时，目标是停止后续动作；退款以已成功支付为前提，必须受原成功金额和已成功退款累计的上限约束；冲正是纠正内部已入账事实的会计动作，不能伪装成对客户或渠道的退款；结算则是在费用流水、账单和对账后推进实际结款。设计时我会为退款单维护申请、处理中、成功、失败和未知等状态，渠道无回执时保持未知，不预先累加成功退款金额。对账把内部明细、渠道交易和账单或结算事实并列比对，差异按漏记、重复、金额不符、账期归属或外部状态冲突分类，分别走查询、补记、冲正、挂账或人工复核。源码中 BillingBusiness.calcAmounts 可以确认商品、运输、出库等费用汇总和金额返回；这只能支撑费用构成的流程事实，不能推断实际审批流、结算周期或生产差异阈值。面试表达应强调每个动作都保留原因、业务键和处理证据，最终以可复核的对账闭环证明恢复完成。 差异处理还要分清客户资金、内部账务和供应商费用三个维度。客户退款成功不自动说明供应商结算应减少，内部冲正也不自动说明渠道已退款；每一步都必须有自己的确认来源和唯一业务键。对于需要人工复核的差异，应冻结自动推进并保留请求、回执、账单明细和处理理由，复核完成后再执行受控补记或冲正。这样结算闭环既能解释金额变化，也能解释为什么此刻允许或禁止继续结款。 追问一：退款请求超时能否立即重试？ 直接回答：不能直接重发；先查询退款结果，因为对方可能已经受理或成功，重复请求可能超过退款上限。 追问 2：发现本地已入账而渠道明确失败怎么办？ 直接回答：冻结相关业务并建立独立冲正或差异处置事实，确认原因后再恢复，不能把状态字段直接改回去。 追问 3：对账发现少一笔账单明细如何处理？ 直接回答：按费用流水和账期条件查明是否漏聚合，再幂等补入或建立差异项；不能只改账单总额。

• 根文档的对账与结算说明

7. 问题：订单、库存和海外仓调用发生超时时，怎样设计查询优先的补偿？ 口述答案：履约链的关键是把客户订单、履约订单、下游仓订单、库存预占、包裹和面单分开建模。一个客户订单可以因仓库或库存拆成多个履约单，但每个履约单只能有一个可生效的下游创建结果，因此本地必须保存履约单号和下游单号映射。创建下游订单超时时，不把超时当失败，也不立刻生成新请求；先以本地业务键查询下游，若已创建则绑定映射并继续，若明确未创建才在预算内重试，若仍未知则保留未知态并转人工核验。库存侧先产生带唯一原因的预占，出库确认后才扣减，取消或下游失败才释放；取消和出库竞争时只能有一个合法状态迁移成功，避免同一占用同时释放与扣减。源码可确认 hiwi-unify 有订单补偿、订单补偿任务、零库存同步重试和面单上传等独立对象，但具体状态迁移与生产重试阈值仍待源码或现场核对。补偿不是“失败后再做一次”，而是根据查询结果修复尚未完成的本地或外部事实，并用业务键、任务记录和人工接管边界控制副作用。 恢复任务还需要明确重试预算和人工接管条件。预算不是固定次数的口号，而是结合外部可查询性、订单时效和重复副作用风险确定；越可能已在下游生效的动作，越应先查而少重试。任务记录应保存查询结果、重试原因和最终处置，使后来的人能判断是仓库故障、映射缺失还是本地状态遗漏。只有当下游明确未创建并且本地状态允许时，才可以再次调用创建操作。 补偿结果写回前再次校验履约单状态，可防止人工或异步任务已经完成处理后，迟到的恢复任务覆盖较新的权威事实。 追问一：为什么履约单必须独立于客户订单？ 直接回答：客户订单表达交付需求，履约单表达一个仓的实际任务；拆仓、缺货和多包裹都会让两者一对多。 追问 2：库存预占成功但仓库拒单怎么办？ 直接回答：确认仓库拒单后按同一库存流水原因释放预占；若拒单结果未知，先查单而不是立即释放。 追问 3：重复补偿任务如何避免重复下单？ 直接回答：任务以履约单业务键查询既有映射，写入使用唯一约束或条件更新，已生效结果只读取不重建。

• 根文档的履约与库存说明

8. 问题：面单、轨迹回调和轮询如何共同保证物流状态不倒退？ 口述答案：我把面单和轨迹视为两类不同事实。面单是包裹运输凭证，可来自客户、物流中台或下游仓；轨迹是承运商持续产生的事件流，所以面单成功既不等于出库，也不等于签收。轨迹事件至少要保留承运商、运单号、事件时间、事件码、地点或原始事件标识，并以这些特征形成去重键；同时保留接收时间，区分事件发生与网络到达。回调入口收到事件后先验证可用性边界、保存原始事实并做幂等合并；回调丢失、延迟或顺序未知时，轮询按运单查询补齐。已签收属于受保护终态，之后即使收到更早发生的运输中事件，也只能作为审计事件保留，不能使展示状态回退；无法可靠排序时标为未知顺序并触发查询或人工核验。源码可确认 WebhookTrack51Api 接收 Timestamp、Signature 和轨迹体后转交处理，也可确认有拉面单、重拉、同步面单以及按日期区间重跑轨迹的任务边界。签名验算、承运商状态表和轮询频率没有被完整证明，必须待源码或现场核对。 轨迹恢复还要把展示状态与原始事实分开。展示状态可由终态保护规则得出，供订单页和客服使用；原始事实完整保留，供承运商争议、数据修复和排序规则调整时回放。回调和轮询的同一事件即使来自不同来源，也要通过稳定事件特征合并，不能因为来源不同重复计数。若承运商没有足够字段生成可靠键，则标为待核对并将无法排序的事件送入人工核验，而不是伪造一个确定的运输进度。 追问一：为什么回调和轮询要并存？ 直接回答：回调更及时但可能丢失或重复，轮询提供兜底确认；两者都写同一事件去重和终态保护规则。 追问 2：面单拉取成功但文件处理失败怎么办？ 直接回答：记录面单来源和版本，重试处理或人工恢复；不能因为文件处理失败否认已经获得面单的事实。 追问 3：重复轨迹事件如何排查？ 直接回答：查看承运商、运单、原始事件标识、事件时间和接收时间，确认去重键与回调或轮询来源，再检查是否重复写入。

• 根文档的面单与轨迹说明

9. 问题：怎样把回调队列、重试、最长存活时间和人工恢复讲成可审计的故障闭环？ 口述答案：可审计的重试不是一个无限循环，而是一条有状态的恢复链。每次待处理项至少关联目标平台、任务编码、数据标识、当前重试次数、计划请求时间、实际请求时间、请求内容、响应内容和失败原因；这些字段在 CallbackQueue 中存在，可以作为源码实体事实。执行时按业务键加锁或使用等价并发控制，取出到期任务后调用外部系统；成功则记录结果并结束，临时失败则增加次数、按退避策略重新安排，超过最长存活时间则记录失败日志并停止自动推进。StripeCallbackTask 的代码可读出队列读取、锁、主动同步、重排和过期处理，因此可说该实现有这类流程，但不能从中推断其他渠道的生产阈值。恢复闭环还需要未知态查询、差异对账和人工入口：当外部结果无法确认时，不再反复制造请求，而是保存证据、告警并由人工按业务键核验。验证标准不是“任务跑过”，而是每一个原始业务事实都有最终确认、明确失败或受控人工处置，并且重复执行不会增加新的资金、订单或轨迹副作用。 为了避免恢复任务本身成为故障源，我会把渠道、仓库、承运商和队列拆成独立故障域，并分别观察待处理量、超龄量、失败原因和人工接管量。任何指标只用于定位和验证，不凭空写成生产阈值或成功率。若同一业务反复进入队列，应回到业务键、当前状态和外部查询结果判断是否已经发生副作用，而不是仅仅增加重试次数。这个过程把自动恢复限制为可证明的范围，把不可证明部分交给人工核验和对账闭环。 追问一：为什么只记录重试次数不够？ 直接回答：没有计划和实际时间、请求响应及失败原因，就无法判断是退避失效、外部不可用还是数据本身不可重试。 追问 2：达到最长存活时间后为什么不继续重试？ 直接回答：持续重试会放大故障和重复副作用；应停止自动推进，保留证据并转告警、对账和人工核验。 追问 3：人工恢复如何避免越权改状态？ 直接回答：人工操作也要按原业务键走受审计的确认、补偿或冲正流程，并记录操作者、原因和复核结果。

• 根文档的多源同步说明

10. 问题：面对“渠道已扣款但本地未到账”，你的线上排查顺序是什么？ 口述答案：我会先止住可能扩大的动作，再建立证据链，而不是立即补扣或手工改余额。第一步按支付单号、渠道会话号、客户或卖家归属查询本地支付单、回调事件、账务分录、待投递事件和任务记录，确认本地到底缺的是状态、分录还是后续联动。第二步用相同业务键主动查询渠道，保存查询时间、原始响应和可识别的外部交易号；如果渠道明确成功，本地支付单只允许从待确认或未知态做一次条件更新，并在同一原子范围补记分录和待投递事件。第三步核对余额快照与有效分录，确认没有因为重复回调或人工操作产生第二笔资金变化。第四步检查回调入口、队列积压、锁冲突、任务过期和错误日志，判断为何本地没有及时确认。最后把内部明细与渠道结果放入对账，记录差异原因、修复动作和复核结论。若渠道结果仍未知，保持未知态，不把它写成成功或失败。这个顺序同时保护资金不被重复入账，也让排查结果能被后续审计和面试复述。根文档已有该故障场景，迁移后应由渠道和账务分册分别承载机制与操作证据。 排查完成后还要做恢复验证：重新按业务键查询渠道，核对支付单状态、事件唯一键、有效分录和余额快照是否一致，再检查后续订单或履约事件是否只投递一次。若修复动作涉及退款、冲正或人工补记，应把操作原因、证据快照和复核人留在差异记录中，保证下一次对账能看见处理后的闭环。这样复盘时能区分根因、止血措施和长期修复，而不是只得到一次偶然恢复的结果。 追问一：为什么先止住动作而不是先修数据？ 直接回答：若自动重试或人工补记仍在运行，修复可能与并发操作叠加，造成重复入账或重复扣款。 追问 2：渠道成功但内部余额未变是否可以直接加余额？ 直接回答：不可以，应先补齐支付状态、业务键和分录，再由分录或受控流程更新快照，保留完整审计链。 追问 3：如何判断是回调丢失还是本地事务失败？ 直接回答：比较渠道查询时间、回调原始记录、事件唯一键、事务日志和待投递记录；缺失位置不同，修复路径也不同。

• 根文档的渠道扣款排查

11. 问题：如何在项目串讲中区分源码事实、根文档资产和你的设计建议？ 口述答案：项目串讲最容易失真的是把“看见一个类”说成“线上完整方案”，所以我会先给证据分级。能定位到精确路径的类、任务和字段称为源码实体事实；能从入口读到服务调用、保存或入队过程的称为源码流程事实；根文档的旧结论仅作为迁移资产，不自动升级为项目事实；为了说明机制而构造的金额、库存和回调场景必须明确标为演练样例；渠道签名版本、密钥轮换、实际状态码、阈值、吞吐和事故结果没有证据时统一标待源码或现场核对。以支付为例，可以引用支付端口、支付单创建和校验、充值锁与延迟队列；以物流为例，可以引用回调入口、面单任务、轨迹重跑和回调队列字段；以补偿为例，可以引用独立补偿和库存同步任务对象。随后再讲设计建议，例如状态机、不可变分录、查询优先和三方对账，但使用“建议”或“演练”措辞。这样既能展示我会读源码、能抽象出可靠性边界，又不会虚构生产版本、金额、规模或成功率，面试追问时也能迅速指出证据位置和缺口。 证据分级也决定了项目话术的措辞强度。对 E2（源码流程）可以说“代码中调用、保存或排队”，对 E1（源码实体）只能说“存在独立对象”，对 E4（演练设计）应说“建议或演练样例”，对 E5（待核对）必须明确缺少哪一类证据。这样在多人协作时，新材料不会因转述不断膨胀；在面试追问时，也能把设计能力、源码阅读能力和真实运行事实清楚分层，而不是把所有信息混成不可验证的故事。 追问一：为什么根文档内容不能直接算项目事实？ 直接回答：根文档是学习材料和迁移来源，除非能回到源码或现场证据，否则不能证明某项行为真实运行。 追问 2：演练数据能否用于面试？ 直接回答：可以，但必须明确是演练样例，用它解释状态与验证，不冒充真实生产指标或事故。 追问 3：待核对会不会显得能力不足？ 直接回答：不会；清楚说明证据边界和验证路径体现工程严谨，编造细节才会在追问中失去可信度。

• 根文档的项目话术入口

12. 问题：模块拆分完成前，怎样验收迁移账本本身已经合格？ 口述答案：我会把验收分为静态完整性、事实边界和可演进性三层。静态完整性先复算根文档哈希，确认与任务开始时的基线一致；再核对 39 个旧 ### 标题、67 道题、9 幅图、13 张表、6 组演绎、6 段排障和 5 段话术都拥有稳定标识，并且每个标识只出现一次、只指向一个目标文件和预期锚点。事实边界检查每张事实卡是否带精确绝对源码路径，是否把只能证明对象存在的内容限定为源码实体，是否把签名、阈值、周期和生产指标写为待源码或现场核对。可演进性检查当前未创建的目标没有被写成坏链接，真实相对链接只指向现存根文档；完成态恒等式和当前实物迁入状态没有混淆。最后运行知识库审计、逐幅渲染 Mermaid（图表语法）图、执行差异空白检查，并重新计算根哈希。若任何一项失败，先修账本或停止收口，不修改根文档来让统计好看。这个验收不能证明后续七个分册已经完成，却能证明迁移工作有唯一来源、零弃用约束和可复核的起点。 验收还需要检查写作结构本身：八个知识小节的标记必须紧随标题，每节恰有三道包含问题、考点、回答思路、详细答案、进阶追问和进阶回答的题；综合题每题只保留一个口述答案，并带真实的相对 Markdown（标记语言）链接。所有英文技术词按规范标注，代码、路径、类名和字段保持原样。任何一项统计不一致都应回到原始资产和目标记录修正，不能为了通过检查删除根资产或伪造迁入状态。 追问一：为什么要真实渲染图而不只检查围栏？ 直接回答：文本围栏可能有语法错误、角色名错误或渲染空白，真实渲染才能验证读者看到的是图而不是代码残片。 追问 2：哈希不一致时可以继续写分册吗？ 直接回答：应停止最终收口并重新建账；可先保留当前工作，但不能声称旧资产已经完整守恒。 追问 3：为什么不更新进度看板？ 直接回答：本任务的唯一写入授权只限账本文件，计划也规定看板在最终收口任务统一更新，避免并发改动。

• 根文档的高频题入口