16.0 旧资产映射、事实边界与架构追问路线

本册是架构追问训练入口，不是第二本迁移账本。旧根全文仍由架构师高频追问题库唯一保留；稳定标识、摘要与归属只由模块 15 唯一迁移账本维护。本册只做范围映射、事实分级、架构追问分层、学习路线与反向链接。

图解读：训练先从旧资产稳定标识进入，再判断是短追问、故障追问还是完整系统设计；所有路线都必须经过事实分级、唯一正文、项目绑定和反例追问，最终用业务不变量、退出条件与证据收口。可编辑源见 architecture-followup-route.puml。

1. 旧根守恒与唯一账本

1.1 旧根保留、范围映射与职责隔离

热门面试题

1. 问题：为什么本册不能再建立一份逐项迁移账本？ 考点：单一事实源、并行协作、资产守恒。 回答思路：先说明唯一账本的字段职责，再说明本册的训练职责。 详细答案：唯一账本已经登记旧根摘要、稳定标识、源位置和处理原则；本册若复制逐项登记，会出现两个更新时间和两套归属结论。这里仅引用稳定范围并建立训练入口，旧根原文、账本事实和新训练资产三者保持分离。 进阶追问：账本链接失效时能否在本册补一份？ 进阶回答：不能。应把状态降为 E0（待核对），记录失效位置并由唯一账本修复；本册不能用副本掩盖源问题。

2. 问题：88 个标题和 28 个主问题为什么要分别计数？ 考点：资产类型、导航职责、训练职责。 回答思路：区分标题节点与问题语义，解释交叉但不可互相抵消。 详细答案：88 个标题包含根标题、分类标题、十个口述主题及其五类版本标题；28 个主问题则由 18 个分类短追问和 10 个口述主题组成。一个主题可以同时是标题和问题，但两种计数服务不同验收，不能用标题总数替代题目守恒。 进阶追问：20 条必背清单与 10 个口述主题重合怎么办？ 进阶回答：保留各自稳定标识。清单承担抽题入口，口述主题承担分时长训练，语义重合不等于资产重复。

3. 问题：如何证明旧资产没有在扩展中丢失？ 考点：分类守恒、反向索引、源版本。 回答思路：给出标题、主问题、清单和口述主题四类等式。 详细答案：先确认旧根仍可访问且摘要基线未被本册改写，再核对 h001..h088、q001..q018、c001..c020、o001..o010 四个连续范围。每个范围的唯一归属仍是旧根，本册只增加真实链接和训练规则，因此旧资产弃用数为零。 进阶追问：新增 20 道综合题是否进入旧资产等式？ 进阶回答：不进入。它们是对应清单主题的新训练资产，应单独统计，不能反向改写旧基线。

flowchart LR
    A["旧根原文"] --> B["唯一迁移账本"]
    B --> C["88 个标题标识"]
    B --> D["28 个主问题标识"]
    B --> E["20 个清单标识"]
    B --> F["10 个口述主题标识"]
    C --> G["本册仅做训练映射"]
    D --> G
    E --> G
    F --> G

图解读：四类稳定范围都由唯一迁移账本登记，本册只有读取箭头，没有反向覆盖箭头；新增训练题与旧资产分开计数。

数据演绎 1：四类资产守恒

按唯一账本复核：标题 88 = 88 个旧根保留 + 0 个弃用；主问题 28 = 18 个短追问 + 10 个口述主题；清单 20 = 20 个旧根保留；口述主题 10 = 10 个旧根保留。本册新增 20 道综合题，扩展量单列为 20，不能写成旧清单迁入 20 道长答案。

2. 标题与主问题标识路线

2.1 从 88 个标题到 28 个主问题的分组索引

热门面试题

1. 问题：如何从一个标题标识定位到可训练问题？ 考点：稳定标识、语义映射、反向定位。 回答思路：先定位标题所属区段，再选择短追问或口述主题。 详细答案：h004..h026 中的具体问题标题映射到 18 个短追问；h029、h035、h041、h047、h053、h059、h065、h071、h077、h083 映射到 10 个口述主题。其余标题承担分类、时长版本或防守追问导航，不额外制造主问题。 进阶追问：为什么不把每个“防守追问”标题也算主问题？ 进阶回答：它们是十个口述主题下的固定版本节点，题意依赖父主题；若独立计数会把同一主题拆成重复主问题。

2. 问题：稳定标识为何不直接使用行号？ 考点：文档演进、定位属性、资产身份。 回答思路：说明行号可变而顺序标识保持身份。 详细答案：插入导航或补充段落会改变行号，但不会改变旧资产身份。稳定标识承载身份，源标题和行号只用于人工定位；行号变化时更新账本定位，不重新编号，也不在本册创建别名范围。 进阶追问：旧标题文字修正后怎么办？ 进阶回答：保留标识，更新标题摘要与复核记录；若语义发生实质变化，再由唯一账本记录差异，而不是本册自行裁决。

3. 问题：如何避免从分类标题直接跳到组件答案？ 考点：业务约束、问题重述、架构推理。 回答思路：先把分类变成可判定的业务问题，再选机制正文。 详细答案：例如“高可用类”不是让候选人罗列限流、熔断，而要先说明哪个业务能力不可中断、允许何种降级、恢复目标和数据一致性要求。分类标题只负责找题，具体答案必须经约束、不变量、候选方案、失败成本和验证路径展开。 进阶追问：只有 30 秒时如何保留约束？ 进阶回答：至少说出一个业务目标、一个关键约束、一个取舍和一个兜底，组件名放在方案之后。

flowchart TD
    A["输入标题标识"] --> B{"是否具体问题标题"}
    B -- "是，分类区" --> C["映射 q001 至 q018"]
    B -- "是，口述主题" --> D["映射 o001 至 o010"]
    B -- "否" --> E["作为分类或版本导航"]
    C --> F["声明约束与取舍"]
    D --> G["选择时间长度"]
    E --> H["继续下钻，不直接作答"]

图解读：只有具体分类问题和十个父级口述主题进入主问题计数；分类标题、版本标题与防守追问只提供路径。

数据演绎 2：标题压缩为主问题

旧根 88 个标题中，前 28 个标题覆盖根、分类、18 个短追问和两组总标题；后 60 个标题由 10 个口述主题乘以“主题标题加五类版本标题”得到 10 × 6 = 60。主问题只取 18 个短追问与 10 个父主题，所以 88 - 28 = 60 不能误读为还有 60 道独立架构题。

3. 清单与口述主题映射

3.1 二十条清单、十个口述主题与新增综合题

热门面试题

1. 问题：20 条清单如何与 10 个口述主题建立关系？ 考点：多入口映射、资产不重复、训练深度。 回答思路：说明前十条与口述主题的覆盖关系，再说明后十条补充治理题。 详细答案：清单前八条和第二十条直接覆盖订单、库存、支付、履约、报警、选型、高可用、事务与架构思维，清单中的灰度也有旧根口述主题；其余幂等、补偿、慢查询、消息堆积、迁移、缓存、追踪、成本和推动落地用于扩展反例与治理训练。 进阶追问：同主题是否只练一次？ 进阶回答：不是。清单题练完整架构回答，口述主题练时间裁剪，短追问练即时取舍；三者共用事实与机制，但验收合同不同。

2. 问题：为什么综合题按清单顺序建立而不按技术栈排序？ 考点：旧资产可追溯、业务主线、反向索引。 回答思路：强调一一对应与快速抽查。 详细答案：按 c001..c020 顺序能让读者从旧清单直接定位新增训练题，并用连续编号检查是否遗漏。技术机制通过每题的真实链接下钻，避免为了分类方便复制库存、事务或消息原理。 进阶追问：后续新增题如何编号？ 进阶回答：使用本册新增训练标识，不能续写 legacy-92-c*；旧前缀只描述历史资产。

3. 问题：怎样判断口述答案不是旧根的改写副本？ 考点：深化边界、原创训练结构、事实约束。 回答思路：比较输入合同、失败路径和证据边界。 详细答案：新答案必须显式加入事实等级、业务不变量、失败成本、退出条件、恢复验证和唯一正文链接，而不是只扩充旧根的组件列表。旧根仍可独立阅读，本册答案则服务三至五轮追问训练，两者职责不同。 进阶追问：能否引用旧根一句结论？ 进阶回答：可以短引或概括并链接来源，但不复制整段分时长答案，也不改变其稳定标识归属。

flowchart LR
    A["c001 至 c020 清单"] --> B["一一对应 20 道综合题"]
    C["o001 至 o010 口述主题"] --> D["时间裁剪训练"]
    E["q001 至 q018 短追问"] --> F["即时取舍训练"]
    B --> G["共同回链唯一正文"]
    D --> G
    F --> G

图解读：清单、口述主题与短追问是三条训练入口，不是三份知识正文；统一下钻可以避免同一机制在多处漂移。

数据演绎 3：训练覆盖率

若每周抽 10 道综合题并各接受 4 轮追问，则两周可覆盖 20 × 1 = 20 道清单题和 20 × 4 = 80 轮直接回答。十个口述主题各安排一次 3 分钟复述，共 30 分钟；18 个短追问各安排 30 秒复述，共 9 分钟。三种训练总时长和通过标准分别记录，不用“做了 48 个资产”混淆重复主题。

4. 事实等级与陈述边界

4.1 E1 至 E0 的架构回答合同

热门面试题

1. 问题：架构面试中如何使用 E1（直接证据）至 E0（待核对）？ 考点：事实等级、语气边界、取证路径。 回答思路：逐级说明来源、可说范围和禁止越界。 详细答案：E1（直接证据）来自简历、源码、配置、原始记录或可复现命令；E2（已有材料映射）表示知识库方案可映射到项目但不能证明已上线；E3（演练设计）使用明确假设与可复算过程；E0（待核对）表示缺证据，只能说明需要什么和如何验证。等级约束的是陈述强度，不是方案质量。 进阶追问：有源码类名能否直接标 E1（直接证据）？ 进阶回答：只能证明代码存在；若要证明生产启用与效果，还需调用链、配置、版本和运行记录。

2. 问题：为什么容量数字最容易越过事实边界？ 考点：量级假设、生产指标、可复算性。 回答思路：区分演练输入与真实记录。 详细答案：吞吐、延迟、峰值和成本往往依赖时间窗、流量结构、硬件、版本与压测条件。缺少记录时可以做 E3（演练设计）并给单位、公式和敏感性，但不能把推演值说成生产成果；真实值待监控、账单或压测报告核对。 进阶追问：面试官要求一个数怎么办？ 进阶回答：先声明是假设值，再完成计算并说出验证方式；无法披露或证明的生产数保持 E0（待核对）。

3. 问题：事实等级如何影响架构选型结论？ 考点：候选方案、证据充分性、可逆决策。 回答思路：先判断证据，再决定是结论、候选还是实验。 详细答案：E1（直接证据）足够时可在已知边界内下结论；只有 E2（已有材料映射）时应称为候选并列待核验项；E3（演练设计）适合比较量级和故障分支；E0（待核对）则先设计取证或小规模验证。证据不足时保持可逆，不把偏好包装成必选。 进阶追问：紧急交付没有验证时间怎么办？ 进阶回答：选择失败成本较低、退出路径清晰的方案，显式记录风险、保护开关和复核日期。

flowchart TD
    A["提出架构结论"] --> B{"有直接证据"}
    B -- "有" --> C["E1：限定范围陈述"]
    B -- "无" --> D{"已有材料可映射"}
    D -- "有" --> E["E2：候选加待核验"]
    D -- "无" --> F{"可构造可复算演练"}
    F -- "可" --> G["E3：假设加公式"]
    F -- "不可" --> H["E0：列取证路径"]

图解读：证据门决定表达强度；路径从 E1（直接证据）向 E0（待核对）并不是能力下降，而是在不确定条件下保持诚实和可逆。

数据演绎 4：容量陈述降级

假设 WMS（仓储管理系统）峰值每分钟到达 600 个库存意图，平均处理 0.2 秒，则到达率为 600 ÷ 60 = 10 个/秒，平均在途量约为 10 × 0.2 = 2。考虑 5 倍突发和一个节点故障，可演练 20 个并发槽，但该数字只能标 E3（演练设计）；没有监控和压测报告时，真实峰值仍为 E0（待核对）。

5. 架构追问分层

5.1 从结论到反例、故障、演进与治理

热门面试题

1. 问题：架构追问为什么要分层而不是平铺问题？ 考点：认知深度、递进证据、回答收束。 回答思路：说明每层验证不同能力。 详细答案：第一层验证能否给出结论和约束，第二层验证能否比较候选与取舍，第三层用反例检验边界，第四层检查故障止血和恢复，第五层检查容量、成本与演进，第六层检查组织治理。分层能暴露答案在哪一层断裂，而不是用更多组件名掩盖缺口。 进阶追问：所有题都要讲六层吗？ 进阶回答：不必。短答至少覆盖前两层，面试官继续追问时再展开；完整系统设计应覆盖到恢复和演进。

2. 问题：反例追问和故障追问有什么区别？ 考点：设计边界、运行处置、证据链。 回答思路：前者挑战适用条件，后者挑战运行恢复。 详细答案：反例追问问“什么条件下你的方案不成立”，要求给淘汰条件和替代方案；故障追问问“已经偏离时怎么证明、止血和恢复”，要求现象、假设、证据、处置与验收。两者都不能只重复原方案。 进阶追问：网络超时属于哪一类？ 进阶回答：既可作为反例挑战同步调用边界，也可作为事故现象进入未知态查证；取决于题目是在设计前还是故障后。

3. 问题：治理层追问如何避免空泛？ 考点：责任、门禁、指标、复核。 回答思路：把规范转成可执行机制。 详细答案：回答应包含决策责任人、适用范围、自动或人工门禁、例外流程、度量指标、退出条件和复核日期。例如技术债不能只说定期偿还，而要按业务风险排序，绑定负责人和完成证据，并确认修复没有引入新的业务偏差。 进阶追问：团队不接受规范怎么办？ 进阶回答：先用真实故障和交付成本说明问题，在高风险链路试点最小门禁，收集收益与摩擦，再决定推广或撤销。

flowchart TD
    A["一层：结论与约束"] --> B["二层：候选与权衡"]
    B --> C["三层：反例与淘汰"]
    C --> D["四层：故障与恢复"]
    D --> E["五层：容量成本与演进"]
    E --> F["六层：组织治理"]
    D -. "证据不足" .-> G["降级事实结论"]

图解读：每一层都以前一层为输入；事实证据不足时可以降低陈述强度，但不能跳过恢复判定直接进入治理成果。

数据演绎 5：六层追问计时

一次 5 分钟训练可分配为：结论与约束 40 秒、候选权衡 60 秒、反例 40 秒、故障恢复 100 秒、演进 40 秒、治理 20 秒，共 40 + 60 + 40 + 100 + 40 + 20 = 300 秒。若故障层无法在 100 秒内说清证据和退出条件，应回到对应正文，不靠压缩结论层掩盖缺口。

6. 唯一正文与项目绑定

6.1 从架构题下钻 50 至 54 与项目事实

热门面试题

1. 问题：架构题为什么要链接 50 至 54 的唯一正文？ 考点：知识去重、职责分层、持续修订。 回答思路：说明路线册负责组织，机制册负责结论。 详细答案：架构设计方法正文及 50—54 分册分别承担约束权衡、选型、案例、稳定性容量和业务指标。路线册只保存如何抽题与追问，机制变化时修订唯一正文即可，避免五套题库出现不同版本。 进阶追问：综合题能否完全不写机制？ 进阶回答：不能。口述答案要给足自包含结论和边界，但深入原理、完整图表与参数应通过真实链接下钻。

2. 问题：项目绑定如何避免编造个人贡献？ 考点：事实卡、团队成果、证据语气。 回答思路：先取项目事实等级，再讲个人可证明动作。 详细答案：WMS（仓储管理系统）、支付、跨境履约、异步任务、Runner（执行器）调度和 IoT（物联网）报警都先回到唯一事实卡。能定位到简历、代码或记录的动作按 E1（直接证据）表达；知识映射、演练和未知项分别按 E2（已有材料映射）、E3（演练设计）、E0（待核对）表达，不把团队整体收益归于个人。 进阶追问：没有事故记录还能讲排障吗？ 进阶回答：可以明确说是故障演练，给触发、信号、处置和验收，但不能说成亲历生产事故。

3. 问题：同一机制如何跨项目迁移？ 考点：业务不变量、机制复用、裁决差异。 回答思路：保持机制不变，替换权威事实和恢复判定。 详细答案：幂等机制都需要稳定业务键和副作用判定，但库存看冻结与流水，支付看支付意图与账务分录，履约看下游单与轨迹，调度看租约与栅栏。迁移的是推理框架，不是把一个项目的状态和指标直接套到另一个项目。 进阶追问：怎样证明迁移成功？ 进阶回答：能在新项目中指出权威事实、重复判定、未知态、补偿边界和恢复验收，而不是只替换名词。

flowchart LR
    A["架构追问题"] --> B["50 约束与权衡"]
    A --> C["51 技术选型"]
    A --> D["52 项目方案"]
    A --> E["53 稳定性容量"]
    A --> F["54 业务指标"]
    B --> G["项目事实卡"]
    C --> G
    D --> G
    E --> G
    F --> G
    G --> H["91 故障追问合同"]

图解读：50—54 提供不同维度的唯一知识，项目事实卡限制陈述范围，模块 91 再检验故障处置；路线册不取代任何一层。

数据演绎 6：跨项目追问矩阵

选择库存、支付、履约、Runner（执行器）调度和 IoT（物联网）报警五类项目，每类分别接受权衡、故障、容量和指标四类追问，可形成 5 × 4 = 20 个训练单元。每个单元至少引用一个唯一正文并声明一个业务不变量，若 20 个单元中有 3 个无法定位权威事实，则当前事实定位通过率为 17 ÷ 20 = 85%，应先补事实卡而不是继续扩题。

7. 学习路线与复习节奏

7.1 从旧根速答到跨层复练的闭环

热门面试题

1. 问题：第一次学习本模块应该按什么顺序？ 考点：事实优先、框架建立、渐进训练。 回答思路：先旧根和账本，再机制正文，最后综合题。 详细答案：先读旧根了解 28 个主问题与 20 条清单，再读唯一账本掌握稳定标识和事实等级；随后用模块 50—54 补权衡、选型、案例、容量和指标，最后在本册完成 20 道综合题与反例追问。顺序保证先知道来源和边界，再追求表达深度。 进阶追问：时间只剩三天怎么办？ 进阶回答：优先库存、支付、履约、高可用、事务和架构思维，仍保留事实分级与恢复验收，不用背组件清单代替推理。

2. 问题：间隔复习如何避免只记住原句？ 考点：主动回忆、变式题、反证。 回答思路：安排不同时间点和不同项目变体。 详细答案：首次学习当天做短答，次日闭卷画图并答三轮追问，第三天换项目和失败条件，第七天做完整口述，第十四天抽查证据链接。每次必须改变至少一个约束或反例，连续两次在不同变体下通过才算掌握。 进阶追问：什么算通过？ 进阶回答：时间内讲清目标、约束、权衡、风险、证据、恢复与边界，且链接和事实等级正确；复述原文不算。

3. 问题：错题应该回写到哪里？ 考点：责任文件、缺口分类、知识去重。 回答思路：按事实、机制、处置和表达分类。 详细答案：事实错误回唯一账本核对，机制错误回 50—54 对应正文，故障处置错误回模块 91，本册只记录训练状态和入口；表达超时调整裁剪顺序，不在多个文件复制修正版长答。 进阶追问：一道题同时错事实和机制怎么办？ 进阶回答：先修会改变结论的事实，再修机制，最后重练表达；记录一个首要缺口和最多两个次要缺口。

flowchart LR
    A["当天：来源与短答"] --> B["第 1 天：闭卷图与追问"]
    B --> C["第 3 天：跨项目变式"]
    C --> D["第 7 天：完整口述"]
    D --> E["第 14 天：随机复核"]
    E --> F{"连续两次通过"}
    F -- "否" --> G["按缺口回唯一正文"]
    G --> C
    F -- "是" --> H["进入新约束题"]

图解读：复习不是线性阅读，而是带间隔和变式的反馈环；失败时按缺口回到唯一责任文件，再从跨项目变式继续。

数据演绎 7：十四天复习负荷

每天 60 分钟，前 10 分钟回忆标识与事实等级，20 分钟完成两道综合题，15 分钟接受追问，10 分钟画图，5 分钟记录缺口。十四天总计 60 × 14 = 840 分钟；可完成 28 次综合题口述、14 次追问训练和 14 幅闭卷图，足以让 20 道题至少覆盖一次，并给 8 道高风险题二次复练。

8. 验收门禁与续接规则

8.1 守恒、链接、长度、图表与协作验收

热门面试题

1. 问题：本册完成验收必须同时检查什么？ 考点：结构、内容、链接、渲染、事实。 回答思路：按旧资产、新内容、图形和自动审计分层。 详细答案：旧资产检查四类稳定范围与零弃用；新内容检查八个知识节、每节三道六字段题、20 道综合题及三至五组直接追问；再检查真实相对链接、八幅 Mermaid（图表语法）图、八张表、八组数据演绎和 PlantUML（开源建模工具）图片渲染；最后运行指定审计命令。 进阶追问：自动审计通过是否足够？ 进阶回答：不够。还要人工核对答案是否自包含、事实等级是否准确、图表表意是否一致以及旧根是否未被修改。

2. 问题：并行写作时怎样避免覆盖其他人的改动？ 考点：文件所有权、最小改动、工作区尊重。 回答思路：限定负责文件，修改前后检查状态。 详细答案：只编辑任务明确分配的三个文件，不更新看板、不整理无关格式、不回退陌生变化。若负责文件在写作中出现他人修改，应先比较差异并合并；无法安全合并时报告冲突，不用覆盖写解决。 进阶追问：发现相关文档有错怎么办？ 进阶回答：在本册用 E0（待核对）限制结论并报告问题，不越权修改其他文件。

3. 问题：后续维护者如何继续增加训练题？ 考点：编号边界、真实链接、质量门禁。 回答思路：新增资产单独编号，保持旧范围冻结。 详细答案：先读旧根、唯一账本和本路线，确认新题不是旧资产迁移；再为新训练题分配本模块新标识，链接唯一机制正文，补事实等级、失败分支、恢复验收和三至五轮追问。不得延长 legacy-92-* 范围伪造历史资产。 进阶追问：旧根新增标题后怎么办？ 进阶回答：由唯一账本重新采集摘要和增量范围，本册随后更新范围引用；不能在本册抢先登记。

flowchart TD
    A["完成写作"] --> B["核对旧资产守恒"]
    B --> C["统计知识题与综合题"]
    C --> D["检查链接与口述长度"]
    D --> E["渲染 Mermaid 与 PlantUML"]
    E --> F["运行知识库审计"]
    F --> G{"全部通过"}
    G -- "否" --> H["定位责任项并修正"]
    H --> B
    G -- "是" --> I["报告结果，不提交版本"]

图解读：验收按守恒、结构、内容、图形和自动审计逐层推进；任何一层失败都回到对应责任项，不能用最终退出码掩盖人工质量问题。

数据演绎 8：验收计数

本册结构目标为 8 × 3 = 24 道知识型六字段题，加 20 道综合题，共 44 道新增训练题；图、表、数据演绎各 8 组，形成 8 + 8 + 8 = 24 个辅助学习资产。旧资产仍按 88/28/20/10 四类守恒，两个统计集合不能相加后宣称“迁移完成”。

9. 综合架构追问题库

1. 问题：legacy-92-c001，如何从零设计一个订单系统？

• 考点：订单边界、状态事实、跨域一致性与恢复。
• 回答思路：从约束和不变量展开到模型、协作、故障与验收。
• 详细答案：完整回答以本题口述为准，并由订单与库存方案链接补充机制。
• 进阶追问：如果外部结果未知，订单主状态如何收口？
• 进阶回答：保留待确认状态，以稳定业务键查证支付、库存和履约事实后条件迁移。
• 口述答案：我不会先画服务框，而会先澄清订单类型、租户与地区边界、峰值窗口、库存承诺方式、支付通道、履约模式、取消退款规则和审计要求，并声明哪些是 E1（直接证据）、哪些只是 E3（演练设计）。核心不变量是一笔业务意图只能形成一个有效订单，金额与币种在确认后不可被普通更新改写，状态只能沿允许路径迁移，库存、支付和履约的未知结果必须可查证。模型上拆分订单主单、明细、价格快照、状态事件、库存承诺、支付意图和履约单，避免一个大表同时承担事实、过程和展示。同步链路只完成订单受理与必要校验，跨域副作用通过本地事务保存待发布事件，再由 MQ（消息队列）异步驱动；消费者以业务键、状态条件和唯一约束保证重复到达只生效一次。查询侧可用缓存和读模型，但数据库订单事实仍是裁决来源。外部超时不能直接重建订单，要进入待确认状态，通过回调、主动查询或对账确定结果。高可用设计包括入口限流、依赖隔离、重试预算、降级开关和按租户保护；容量用到达率、服务时间、在途量和故障余量推演。发布时按租户灰度，监控创建成功率、状态停留年龄、事件积压和账实差异。恢复不是服务起来就结束，还要扫描未知订单、补投事件、核对库存与支付，并确认积压斜率持续为负。项目表达可绑定 WMS（仓储管理系统）和跨境履约，但生产规模、效果和个人贡献只在证据范围内陈述。最终还要用取消、退款、迟到支付和重复履约四类反例检验状态模型，而不是只验正常下单。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：为什么不用一个订单状态字段解决全部流程？ 直接回答 1：单字段会把库存、支付、履约的独立事实压成一个结果，无法表达并行、未知和补偿；应保留主状态与各域事实，再用规则汇总展示状态。
• 追问 2：消息重复导致状态倒退怎么办？ 直接回答 2：事件保存业务键、版本和发生时间，消费使用唯一约束与条件迁移；旧事件保留审计但不能覆盖更高版本终态。
• 追问 3：上线后怎样判定可以结束观察？ 直接回答 3：创建成功率、未知态年龄、积压、库存支付差异都在完整业务窗口内稳定，并完成高风险订单抽样核对后才退出保护。
• 订单与库存项目方案

2. 问题：legacy-92-c002，如何设计库存防超卖？

• 考点：库存语义、并发裁决、流水对账与实物边界。
• 回答思路：先定义可售与冻结，再讲防重、条件更新、补偿和抽盘。
• 详细答案：完整回答以本题口述为准，并由库存预占方案链接补充机制。
• 进阶追问：缓存、数据库与实物三者冲突时谁裁决？
• 进阶回答：先以数据库流水和快照定位系统事实，再结合仓内作业与抽盘裁决实物差异。
• 口述答案：库存防超卖首先要定义可售、冻结、已扣减、释放和实物库存的语义，不能把缓存里的一个数字当全部事实。我的核心不变量是可售量不得小于零，同一订单行的同一冻结意图只能生效一次，期初数量加全部流水可以重算当前快照，释放必须引用原冻结责任。受理时生成稳定业务键，在 MySQL（关系型数据库）中用唯一约束防重复，并通过带版本或条件的更新保证只有 available >= request 时才能减少可售；热点场景可以在 Redis（远程字典服务）预判或削峰，但数据库流水与快照仍承担最终裁决，缓存失败不能旁路业务条件。冻结、确认扣减和释放都写不可变流水，再在同一本地事务中更新快照与待发布事件。网络超时或消息重投时，不重新创造业务意图，而是按原键查询已有结果。仓内拣货、取消、超时释放可能乱序，因此状态迁移要有前置条件，已出库责任不能被迟到取消直接释放。热点治理要识别少数仓库和 SKU（库存单位），采用分片排队、批量合并、限流或预约，而不是盲目扩大锁范围。故障时先暂停问题库存键的新承诺，保留查询和已确认作业，再串联请求、唯一约束、库存流水、缓存版本、消息和仓内任务寻找首个分叉。修复必须按原业务键补偿或冲正，禁止直接把汇总数量改回正数。恢复验收同时检查可售非负、流水可重算、冻结责任守恒、积压收敛和高风险实物抽盘。真实超卖次数与收益若无记录，应保持 E0（待核对）。上线前还应注入同键并发、重复释放和仓内迟到三类故障，确认每条保护线都能独立生效。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：Redis（远程字典服务）预扣成功但数据库失败怎么办？ 直接回答 1：预扣只是受理层保护，数据库失败后按原业务键释放预占并记录补偿状态；对账持续核对缓存预占与数据库冻结。
• 追问 2：为什么分布式锁不能单独解决超卖？ 直接回答 2：锁可能超时、误释放或被旁路，且不能表达重复业务意图；数据库条件、唯一约束、流水和对账才构成完整防线。
• 追问 3：直接修正库存快照有什么风险？ 直接回答 3：会掩盖重复冻结、漏释放或已发生的实物副作用，导致下一次重算再次出错；应以可审计流水冲正。
• 库存预占与对账补偿

3. 问题：legacy-92-c003，如何设计支付资金一致性？

• 考点：支付意图、渠道未知、账务分录与对账恢复。
• 回答思路：围绕金额币种不变、状态单调和分录可审计展开。
• 详细答案：完整回答以本题口述为准，并由支付正确性方案链接补充机制。
• 进阶追问：渠道事实与本地事实冲突时如何处置？
• 进阶回答：冻结新的不可逆动作，按原意图查单和对账，保留证据后幂等补记或人工裁决。
• 口述答案：支付系统的重点不是把接口返回成功写进订单，而是让业务意图、渠道事实、账务事实和商户状态长期可解释。我会先确认支付方式、币种精度、退款冲正、清结算、对账周期和监管边界。核心不变量是一笔商户支付意图只有一个稳定标识，金额与币种确认后不可变，支付状态只能单调迁移，任何资金变化都有不可变分录，借贷或收支口径可平衡，重复回调只生效一次。发起支付时本地事务保存支付单、请求摘要和待发布事件，调用渠道使用商户请求号作为幂等键；网络超时进入未知态，不能直接判失败并重付，而要通过验签回调、主动查单和渠道账单裁决。回调先验签、校验商户号金额币种和时间，再以渠道事件号与业务键建立唯一约束，条件更新支付状态并落账务分录。支付状态更新和下游订单通知之间通过待发布事件保证最终一致，重复消费由业务键、版本和副作用记录防重。退款必须引用原支付和原分录，部分退款累计不能超过可退金额，冲正不删除历史。高可用上对渠道做隔离、超时、退避和重试预算，单渠道故障不应耗尽全局线程与连接。故障时可暂停新的不可逆资金动作，但保留查单、回调落库和对账。恢复以未知支付年龄下降、渠道账单与本地支付单及分录差异收敛、待发布事件清空为判定。项目中多渠道接入可以按 E1（直接证据）表达，真实差异率、损失和收益必须有账单与运行记录支持。上线门禁还应抽样核对跨币种、部分退款、重复回调和跨日对账，确保状态正确与资金正确同时成立。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：渠道成功但本地事务回滚怎么办？ 直接回答 1：保留原商户请求号，通过主动查单和账单确认渠道事实，再幂等补记本地支付单与分录，不能再次发起扣款。
• 追问 2：为什么支付状态和账务分录要分开？ 直接回答 2：状态回答业务处于哪一步，分录回答资金为何变化；分开才能审计、冲正、对账并发现状态成功但账务缺失。
• 追问 3：对账发现差异是否自动修复？ 直接回答 3：先按差异类型和证据置信度分级；可证明的漏记可幂等补记，金额冲突或重复扣款进入人工裁决，禁止盲目覆盖。
• 支付资金正确性与恢复

4. 问题：legacy-92-c004，如何设计跨境物流履约系统？

• 考点：防腐层、外部未知、状态乱序与异常恢复。
• 回答思路：从统一内部语义讲到渠道隔离、查证和在途清单。
• 详细答案：完整回答以本题口述为准，并由跨境履约方案链接补充机制。
• 进阶追问：渠道无法提供可靠幂等接口怎么办？
• 进阶回答：本地保持稳定意图键和请求摘要，超时先查证，必要时串行化高风险动作并进入人工清单。
• 口述答案：跨境履约的难点是多仓、多承运商和外部平台都可能超时、重复、乱序并拥有不同状态语义，因此我先澄清订单来源、仓库选择、拆合包、面单、轨迹、取消、补发和关务边界。核心不变量是一个履约意图不能重复创建有效下游单，内部终态不能被迟到事件倒退，每个包裹和面单版本可追溯，外部未知结果必须有查证入口。模型上分开业务订单、履约单、下游仓单、包裹、面单版本、轨迹事件和异常工单；通过防腐层把渠道字段映射为内部统一语义，原始报文与映射版本保留审计。创建下游单使用稳定业务键和请求摘要，超时后进入待查证，不立即换一个新键重建；查询接口、回调、库存或费用账单共同帮助确认外部事实。面单保存文件校验值、版本和生成来源，重复获取不能产生新副作用。轨迹同时记录发生时间、接收时间、来源、版本和原始状态，内部状态按条件单调推进，迟到旧事件可审计但不能覆盖已签收。每个渠道使用独立并发舱壁、限流、超时、退避与重试预算，避免一个海外仓拖垮全链路。故障时隔离异常渠道，保留已确认履约和查询，按业务键核对重复下游单、缺面单、轨迹断点与在途订单。恢复要求异常清单收敛、终态单调、重复履约为零且抽样核对外部单号。具体渠道时限、峰值和效果若没有接口契约及运行记录，只能标 E0（待核对）或 E3（演练设计）。此外要定期回放渠道新增状态和契约变更，验证映射仍可解释，避免静默把未知状态归为成功。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：两个超时重试都创建了下游单怎么办？ 直接回答 1：先冻结继续履约，按业务键查出全部外部单，保留唯一合法单并通过渠道取消或人工工单处理重复单，同时修复幂等键和查证流程。
• 追问 2：签收后收到运输中轨迹如何处理？ 直接回答 2：保存原始旧事件用于审计，但条件迁移拒绝内部状态倒退；若来源冲突则进入异常裁决。
• 追问 3：渠道状态无法一一映射怎么办？ 直接回答 3：内部只保留业务必需的稳定状态，渠道细节存扩展字段和原始事件；无法确定的映射进入未知或异常态。
• 跨境履约面单轨迹恢复

5. 问题：legacy-92-c005，如何设计 IoT（物联网）报警治理系统？

• 考点：窗口聚合、背压、报警状态与通知副作用。
• 回答思路：先保护原始事件和高等级报警，再控制噪声与恢复。
• 详细答案：完整回答以本题口述为准，并由报警风暴方案链接补充机制。
• 进阶追问：风暴治理怎样避免把真实故障一起抑制？
• 进阶回答：按等级和同源关系聚合，保留原始事件与高等级直通通道，并用恢复证据复核。
• 口述答案：IoT（物联网）报警治理不能把每个原始点位异常都直接变成通知，否则设备抖动、断网重连和批量恢复会形成报警风暴。我先澄清设备规模、采样周期、报警等级、持续窗口、恢复规则、通知渠道和人工确认要求。核心不变量是原始事件不可丢失且可重放，同一设备同一规则在一个活动窗口内只有一个活动报警，报警开启、确认、恢复和关闭状态单调，通知失败不改变报警事实。入口按设备、租户和规则限流，原始数据写入可追溯事件流；规则计算使用事件发生时间和水位处理迟到数据，通过去抖、持续阈值、滑动窗口、相似告警聚合和抑制关系降低噪声。活动报警以设备、规则和窗口形成稳定键，重复计算只更新证据计数而不重复创建。通知作为下游副作用独立排队，按等级配置重试预算、静默窗口和升级策略，短信或电话故障不能阻塞报警状态落库。风暴时优先保护原始事件接收和高等级报警，降级低等级通知、扩大聚合窗口并按租户隔离；不能简单丢弃所有重复事件，因为恢复判断仍需要证据。故障排查要看入口速率、窗口基数、最老事件年龄、规则耗时、活动报警数和通知积压，区分真实批量故障与规则配置错误。恢复时从可信水位重放，核对活动报警、恢复事件和通知清单，确保高等级报警无漏报、重复通知收敛。设备规模、压缩比例和通知效果没有生产记录时应作为 E3（演练设计），不能包装成真实收益。规则发布也要按租户灰度并保留旧版本回放能力，防止错误阈值在全量设备上同时制造噪声。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：扩大聚合窗口会不会漏报？ 直接回答 1：会增加发现延迟，因此只对低等级、同源且可聚合事件启用；高等级硬阈值保持独立快速通道，并监控延迟护栏。
• 追问 2：如何区分设备故障和网络分区？ 直接回答 2：结合网关心跳、同区域设备相关性、数据新鲜度和网络指标提出并行假设，证据不足时不直接派单更换设备。
• 追问 3：通知成功是否代表报警闭环？ 直接回答 3：不代表；还要有人工确认、处置记录、恢复证据和关闭条件，通知只是副作用之一。
• 报警风暴窗口聚合与恢复

6. 问题：legacy-92-c006，如何做技术选型？

• 考点：工作负载、候选矩阵、验证与退出路径。
• 回答思路：先定义门槛，再淘汰、实验、决策和灰度复核。
• 详细答案：完整回答以本题口述为准，并由候选矩阵正文补充方法。
• 进阶追问：证据相近的两个候选如何决策？
• 进阶回答：优先失败成本低、团队可运维且退出路径清晰的方案，并设置复核触发条件。
• 口述答案：技术选型不是列产品优缺点，而是把工作负载、质量属性、团队能力和退出路径变成可验证决策。我先澄清数据模型、读写比例、峰值与增长、延迟目标、一致性、可用性、合规、部署环境、团队经验和预算，并给每条输入标事实等级。随后定义必须满足的门槛与可以权衡的偏好，例如资金账务必须事务和审计，物流轨迹允许异步检索但要求原始事实可回放。候选方案至少保留两个可行项，用统一矩阵比较功能适配、故障模式、运维复杂度、迁移成本、供应商依赖和总成本；先用淘汰条件去掉不合格项，再对高不确定风险做 POC（概念验证），而不是用演示吞吐替代真实工作负载。验证数据要接近生产数据分布、热点、失败注入和恢复过程，并提前写清成功阈值、停止条件与负责人。最终决策用 ADR（架构决策记录）保存背景、候选、证据、取舍、未决风险和复核日期。对难以撤销的选型，要准备双写校验、数据导出、协议适配和回退路径；可逆的小决策则避免过度评审。上线采用小流量或单租户灰度，观察业务成功率、尾延迟、资源、错误与人工负担，达不到门槛就按预定退出条件撤销。比如订单和资金主事实倾向 MySQL（关系型数据库），轨迹搜索可建立派生索引，但这只是基于工作负载的结论，不是“某技术更先进”。若真实峰值、许可费用或团队熟练度缺证据，我会保持 E0（待核对），先取证再承诺。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：团队最熟悉的方案是否应直接胜出？ 直接回答 1：熟悉度是交付与运维成本的重要维度，但不能突破一致性、合规和恢复门槛；若门槛满足，它可以成为降低风险的决定因素。
• 追问 2：POC（概念验证）只压测性能够吗？ 直接回答 2：不够，还要验证故障恢复、数据迁移、可观测性、权限、备份恢复和日常运维，否则只证明了理想路径。
• 追问 3：如何避免选型被个人偏好绑架？ 直接回答 3：预先公开工作负载、权重、淘汰条件和证据，由不同角色评审，并把异议与复核日期写入 ADR（架构决策记录）。
• 候选矩阵与淘汰条件

7. 问题：legacy-92-c007，如何设计高可用系统？

• 考点：业务目标、故障域、韧性保护与恢复判定。
• 回答思路：从业务分级和故障模型反推冗余、隔离、降级与演练。
• 详细答案：完整回答以本题口述为准，并由容灾恢复正文补充方法。
• 进阶追问：多副本为什么仍可能不满足高可用？
• 进阶回答：副本可能共享配置、网络和状态故障域，还需验证切换、栅栏、容量与业务恢复。
• 口述答案：高可用不是把所有组件部署两份，而是从业务成功定义、故障模型和恢复目标反推保护机制。我先区分核心写入、查询、后台任务和管理操作，给出各自允许的失败、降级、数据丢失窗口和恢复时间；没有真实目标时只做 E3（演练设计）。然后画出依赖图，识别单点、共享故障域、容量瓶颈和不可逆副作用。无状态服务可多实例部署并跨故障域分散，状态组件要明确主从、仲裁、复制延迟、备份和恢复语义；多副本若共享同一网络、配置或数据库，并不等于独立容灾。入口使用超时、限流、熔断、舱壁和有预算的退避重试，防止慢依赖耗尽线程、连接与队列；降级优先保护库存承诺、支付查证和报警接收等核心不变量，暂停报表或低等级通知。数据一致性按业务选择同步、异步、补偿与对账，不能为了可用性让资金和库存无条件多写。观测要同时覆盖技术信号和业务完成率，告警绑定可执行动作。故障切换前验证目标端数据新鲜度和容量，切换后防止旧主继续写入；恢复原站点也要分批回流。演练包括节点、机房、网络分区、下游超时和配置错误，并记录发现、止血、恢复与复盘时间。最终验收不是接口返回，而是积压下降、未知态收敛、账实一致和完整业务窗口稳定。项目回答要说明具体保护了哪个不变量，不能只罗列高可用名词。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：双机为什么仍可能同时不可用？ 直接回答 1：两台机器可能共享电源、网络、配置、数据库或错误发布，副本数量没有消除共同故障域。
• 追问 2：自动切换一定优于人工切换吗？ 直接回答 2：不一定；只有故障判定、栅栏、防脑裂、目标容量和回退经过验证时才适合自动化，否则错误切换会扩大损失。
• 追问 3：恢复后为什么还不能立即解除限流？ 直接回答 3：历史积压、缓存冷启动和重试流量会形成第二波冲击，应在完成率高于到达率且关键水位持续下降后逐级放开。
• 故障模型与容灾恢复

8. 问题：legacy-92-c008，如何处理分布式事务？

• 考点：本地事务、最终一致、补偿与未知态。
• 回答思路：按不一致窗口、参与方控制力和可逆性选择方案。
• 详细答案：完整回答以本题口述为准，并由事务一致性正文补充机制。
• 进阶追问：强一致是否总比最终一致更安全？
• 进阶回答：不一定，跨域强一致可能扩大耦合与不可用范围，应以业务不变量和恢复能力裁决。
• 口述答案：我先拒绝“所有跨服务操作都做成强事务”的前提，先识别业务不变量、参与方是否可控、允许的不一致窗口、外部副作用和补偿可逆性。能在单库单服务内完成的操作优先收敛为本地事务；跨服务但允许短暂不一致时，用本地事务同时保存业务事实与待发布事件，经 MQ（消息队列）投递，消费者通过稳定业务键、唯一约束和状态条件幂等执行，再以对账和补偿收口。需要显式预留资源且参与方都能改造时，可以考虑 TCC（Try Confirm Cancel，尝试确认取消），但要处理空回滚、悬挂、重复确认和资源长期占用。长流程更适合 Saga（长事务补偿模式），每一步有前置条件、补偿语义和人工兜底；补偿是新的反向业务动作，不是数据库回滚，已经发货、短信发送或外部扣款可能无法真正撤销。支付通道、海外仓等外部系统返回超时时，必须进入未知态，通过查单、回调、账单或工单裁决，禁止立刻重做不可逆动作。事务状态与事件投递都要可观测，重点监控待发布年龄、重复率、补偿失败、未知态和对账差异。故障时先阻止继续产生同类副作用，保留查询和证据，再按原业务键查证并执行幂等补偿。恢复验收要求业务不变量重新成立、历史积压与未知态收敛、重复副作用为零且差异可解释。方案选择不以中间件名为中心，而以失败窗口和恢复能力为中心；真实事务规模与恢复效果没有记录时保持 E0（待核对）。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：可靠消息是否就能保证最终一致？ 直接回答 1：不能；还需要本地事务保存事件、可靠投递、幂等消费、失败重试、死信处置、对账和可执行补偿。
• 追问 2：补偿失败怎么办？ 直接回答 2：记录独立补偿状态和重试预算，超过自动边界进入人工清单；原业务事实与补偿证据都不能删除。
• 追问 3：何时不适合 TCC（Try Confirm Cancel，尝试确认取消）？ 直接回答 3：参与方不可改造、预留资源成本高、流程很长或补偿语义复杂时不适合，应选择消息、Saga（长事务补偿模式）或查证对账。
• 分布式事务与消息一致性

9. 问题：legacy-92-c009，如何设计幂等？

• 考点：业务意图、防重裁决、结果重放与外部副作用。
• 回答思路：稳定键、摘要校验、唯一约束、状态条件和查证五层展开。
• 详细答案：完整回答以本题口述为准，并由幂等补偿正文补充机制。
• 进阶追问：处理中记录超时后能否直接删除重做？
• 进阶回答：不能，先查证持有者和外部副作用，必要时通过版本或栅栏接管，保留旧记录审计。
• 口述答案：幂等不是简单加锁，而是保证同一业务意图被重复请求、重复消息或超时重试触发时，最终只产生一次有效业务副作用。我先定义“同一意图”的边界：库存可用订单行与冻结类型，支付可用商户请求号，履约可用订单与仓库动作，Runner（执行器）任务可用任务实例与分片。幂等键必须由业务稳定属性生成，不能使用每次重试都会变化的请求流水号。入口先校验请求摘要，若同一键对应不同金额、商品或动作，应拒绝并报警，不能把冲突当成功重放。数据库用唯一约束承担并发裁决，业务状态用条件更新防止已完成动作再次迁移，副作用表记录渠道调用、消息处理或文件交付结果；缓存可以加速，但不能成为唯一防线。首次处理成功后返回可重放结果，处理中状态要有持有者、版本和超时查证，不能因为等待超时就删除记录。对外部系统调用，传递同一幂等键并保存请求摘要；返回未知时先查证，不更换键重试。消息消费在同一本地事务中保存消费标识与业务变化，提交成功后再确认消息。锁租约过期时用栅栏或业务版本阻止旧执行者迟到写入。故障排查从同一业务键串联入口日志、唯一冲突、状态版本、副作用记录和外部事实，区分重复到达、并发执行与结果回执丢失。恢复验收不仅看重复请求返回成功，还要确认资金、库存、履约和通知没有重复副作用。幂等记录保留期由最长重试与对账窗口决定，不能随意过期。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：为什么请求号随机生成不能天然幂等？ 直接回答 1：如果客户端每次重试都生成新请求号，服务端会把同一业务意图识别成多个动作；键必须跨重试稳定。
• 追问 2：唯一约束冲突后直接返回成功可以吗？ 直接回答 2：要先读取已有记录并比较请求摘要与业务结果；只有语义完全一致才可重放成功，冲突内容必须拒绝。
• 追问 3：幂等记录何时可以清理？ 直接回答 3：超过业务重试、消息保留、外部查证和对账最长窗口，并完成归档或可重建验证后才能清理。
• 分布式事务、幂等与补偿

10. 问题：legacy-92-c010，如何设计补偿机制？

• 考点：可逆性、反向业务动作、自动边界与人工裁决。
• 回答思路：逐步识别权威事实、补偿键、未知态和恢复验收。
• 详细答案：完整回答以本题口述为准，并由退款冲正正文补充机制。
• 进阶追问：补偿成功为何仍可能不一致？
• 进阶回答：外部副作用、汇总快照或下游事件可能仍缺失，必须通过对账和不变量复核收口。
• 口述答案：补偿的目标不是把所有状态机械恢复到原值，而是在部分成功、外部未知或流程中断后，用可审计的新动作重新建立业务不变量。我先列出每一步的权威事实、可逆性、截止时间和责任方：库存冻结可按原冻结键释放，支付扣款通常要退款或冲正，已发货履约可能只能拦截、退货或人工处理，通知发送则无法撤回。正向动作与补偿动作都要有稳定业务键、前置状态、版本和唯一约束，补偿必须引用原动作，防止重复补偿或补偿错对象。流程状态显式区分待执行、已成功、明确失败、结果未知、补偿中、补偿成功和人工介入；未知态先查证，不能默认失败后直接反做，否则可能出现渠道已扣款而本地又退款错误。自动补偿采用有上限的退避重试和独立队列，按风险隔离资金、库存与低风险通知，超过时间或次数进入人工清单。每次执行保存请求摘要、结果、证据来源和下一次计划，人工操作也必须审计。对账负责发现正向事实与补偿事实之间的遗漏，例如库存流水已释放但快照未更新，或退款成功但本地分录缺失。故障时先暂停继续制造同类异常，再按业务键盘点未完成和未知流程；修复程序要可重复运行并提供预览。恢复验收要求原业务不变量成立、补偿队列和未知态年龄下降、重复副作用为零、人工清单有明确责任人。真实补偿成功率和时长必须由运行记录证明，设计样例只能标 E3（演练设计）。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：补偿为什么不能直接删除原记录？ 直接回答 1：删除会破坏审计和对账，也无法解释外部副作用；应保留原动作并新增引用它的反向记录。
• 追问 2：补偿重试会不会再次造成副作用？ 直接回答 2：会，所以补偿本身也要稳定键、唯一约束、状态条件和结果重放，且外部调用沿用同一补偿请求号。
• 追问 3：什么时候必须人工介入？ 直接回答 3：证据冲突、金额或实物不可自动裁决、超过安全时限、外部系统无幂等能力或自动重试可能扩大损失时。
• 支付退款冲正与对账闭环

11. 问题：legacy-92-c011，如何防止系统雪崩？

• 考点：反馈放大、资源隔离、重试预算与分级恢复。
• 回答思路：从调用链与资源池识别正反馈，再讲止血和退出条件。
• 详细答案：完整回答以本题口述为准，并由稳定性事故正文补充方法。
• 进阶追问：保护策略自身失效时如何发现？
• 进阶回答：监控限流、熔断、拒绝、探测与业务完成率，并通过故障演练验证保护链路。
• 口述答案：系统雪崩通常不是一个实例失败，而是慢依赖、无界等待、同步重试和共享资源耗尽形成正反馈，所以我要先画调用链、资源池和故障域，确认哪些业务必须保护。入口按租户、接口和业务价值限流，避免突发流量直接进入所有下游；每层设置小于上游预算的连接、读取和总超时，防止请求在链路中无限滞留。对持续失败或超时的依赖使用熔断，让调用快速失败并给恢复探测留容量；不同渠道、任务和优先级使用线程池、连接池和队列舱壁，避免一个海外仓或大导出占满全局资源。重试必须有总预算、指数退避、随机抖动和幂等前提，只在可恢复错误上执行，且重试流量计入容量。降级按业务不变量设计：库存和支付保留查证与核心写入，报表、推荐或低等级通知可以暂停；缓存兜底要有版本、新鲜度和穿透保护，不能返回会导致资金或库存错误的旧值。监控同时观察业务完成率、尾延迟、线程连接占用、队列最老年龄、熔断比例和依赖错误，告警要能指向止血动作。事故发生后先限制新到达、隔离异常依赖、暂停非关键任务并保留证据，再验证完成率是否高于到达率、积压斜率是否转负。恢复采用小步放量，防止缓存冷启动和历史重试形成第二波流量。演练要覆盖下游慢而不报错、网络半开、配置错误和单租户热点。项目中的具体阈值和成功率如果没有监控记录，只能标 E3（演练设计），不能把通用参数说成生产事实。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：为什么超时越短不一定越好？ 直接回答 1：过短会把正常尾延迟变成失败并触发更多重试；超时要基于业务预算、下游分位延迟和剩余链路时间分层配置。
• 追问 2：熔断后如何恢复？ 直接回答 2：保留少量探测请求，满足连续成功、延迟和容量条件后分级放量；探测失败立即回到保护状态。
• 追问 3：只扩容能否解决雪崩？ 直接回答 3：若根因是重试放大、锁竞争或下游瓶颈，扩容只会增加压力；应先控制反馈回路，再按证据扩容。
• 稳定性事故与容量排障

12. 问题：legacy-92-c012，如何做灰度发布？

• 考点：兼容、灰度单元、业务门槛与回退。
• 回答思路：按变更类型设计分阶段发布、观察和停止条件。
• 详细答案：完整回答以本题口述为准，并由渐进交付正文补充方法。
• 进阶追问：灰度期间新旧数据语义冲突怎么办？
• 进阶回答：先保持双向兼容并记录版本，冻结扩量，校验受影响数据后回退或前向修复。
• 口述答案：灰度发布的目标不是把新版本慢慢推完，而是在可控影响面内验证假设，并能在业务不变量受损前停止或回退。我先确认变更类型：无状态代码、数据库结构、消息格式、配置、缓存键或外部契约的回退能力不同。发布前定义灰度单元，可按内部用户、租户、仓库、地区或稳定流量比例选择，要求同一业务链路尽量保持版本一致，避免一次请求跨越不兼容版本。接口和事件采用先兼容后切换再清理的顺序，数据库遵循扩展、双读或双写校验、迁移、收缩，不能先删除旧字段。制品、配置和迁移脚本都要版本化，回退不仅回代码，还要考虑已经写入的新数据和已发送的副作用。灰度门槛同时包含业务成功率、资金或库存差异、尾延迟、错误率、资源和人工工单；每项写明基线、阈值、观察窗口、负责人和自动停止条件。流量逐级扩大，每一级都覆盖完整业务窗口，高风险支付或履约要抽样核对权威事实。若指标恶化，先冻结扩量，判断是版本、流量结构还是依赖变化，再选择回退、关闭功能或前向修复，不能在原因未知时反复发布。消息消费者和定时任务要避免新旧版本同时执行同一副作用，可用稳定业务键、租约与栅栏控制。发布完成后继续观察迟到消息、缓存旧值、历史任务和对账差异。真实灰度比例、阈值和收益要有发布记录支撑；缺证据时只说明方法与 E3（演练设计）门槛。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：数据库变更为什么常常不能一键回退？ 直接回答 1：新版本可能已写入旧版本无法理解的数据，删除列或改语义会丢失信息；应先做向前兼容和可验证迁移。
• 追问 2：技术指标正常就能全量吗？ 直接回答 2：不能，还要检查订单完成、库存差异、支付未知态、履约异常和人工工单等业务指标。
• 追问 3：按百分比灰度有什么盲区？ 直接回答 3：随机百分比可能漏掉大租户、特殊仓库或长流程，应结合业务单元和风险标签定向覆盖。
• 配置发布与渐进交付

13. 问题：legacy-92-c013，如何治理慢 SQL（结构化查询语言）？

• 考点：业务影响、执行证据、索引代价与灰度验证。
• 回答思路：从调用与执行计划定位成本，再按收益风险优化。
• 详细答案：完整回答以本题口述为准，并由数据库排障正文补充机制。
• 进阶追问：测试库优化有效为何上线可能无效？
• 进阶回答：生产数据量、倾斜、缓存、并发和锁不同，必须用接近真实分布的样本与灰度验证。
• 口述答案：慢 SQL（结构化查询语言）治理先从业务影响和证据开始，不看到一条慢日志就立刻加索引。我先确认慢的是单次延迟、总资源消耗、锁等待还是调用次数过多，并按接口、租户、时间窗和版本定位样本。证据包括慢查询日志、执行计划、实际扫描行、返回行、索引选择、锁等待、缓冲命中、临时表、排序、磁盘与数据库负载，同时查看应用是否存在循环查询、超大分页或连接池排队。优化器选择受数据分布、统计信息和参数影响，所以要在接近生产的数据量与倾斜下复现，不能只看测试库。优化顺序通常先减少不必要调用和返回列，再改写过滤、连接与分页方式，随后评估联合索引、覆盖索引和数据归档；索引要匹配等值、范围、排序和选择性，也要计算写放大、空间与维护成本。热点更新慢时要检查事务范围、锁顺序和外部调用是否放在事务内，加索引未必解决。大查询可拆分异步任务、使用快照与分片，但要保持结果口径。线上止血可限制高成本入口、缩小查询范围、暂停报表或将特定租户隔离，不能直接杀掉所有连接。变更通过影子流量或小范围灰度，比较业务成功率、分位延迟、扫描行、数据库中央处理器、锁等待与写入代价。恢复验收覆盖高峰窗口，并确认没有因为索引或改写引入结果错误。具体耗时和提升比例只有在相同条件的前后证据齐全时才能按 E1（直接证据）陈述。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：执行计划用了索引为什么仍然慢？ 直接回答 1：可能扫描范围大、回表多、数据倾斜、排序临时表、锁等待或调用次数过多；“使用索引”不是低成本证明。
• 追问 2：为什么不建议盲目增加联合索引？ 直接回答 2：会增加写放大、缓存压力和优化器选择复杂度，且列顺序不匹配查询时收益有限。
• 追问 3：深分页怎么处理？ 直接回答 3：优先用稳定排序键做游标翻页，或先从覆盖索引取主键再回表；导出场景改为异步快照分片。
• MySQL（关系型数据库）线上排障与综合题

14. 问题：legacy-92-c014，如何治理消息堆积？

• 考点：到达完成率、分区并行、下游瓶颈与幂等回放。
• 回答思路：先分类根因和影响，再止血、扩缩与恢复核对。
• 详细答案：完整回答以本题口述为准，并由消息积压正文补充机制。
• 进阶追问：如何证明积压正在真正恢复？
• 进阶回答：完成率持续高于到达率，最老年龄与深度下降，下游有余量且业务副作用核对正确。
• 口述答案：消息堆积首先是到达率持续大于完成率的结果，不应一看到队列深度就盲目扩消费者。我先确认主题、分区、消费组、最老消息年龄、到达率、成功完成率、重试率和业务影响，并区分生产突增、分区倾斜、单条毒消息、下游变慢、消费者停顿和提交位点异常。队列条数会受消息大小和保留策略影响，最老年龄更能表达业务等待。证据要串联代理节点吞吐、分区分布、消费者处理时间、线程与连接池、数据库锁、外部调用、重试与死信。止血优先限制非关键生产入口，隔离慢租户或毒消息，暂停会放大副作用的无界重试，并保护支付、库存和报警等高优先级流量。扩容前检查分区数、键分布和下游容量；消费者数量超过有效分区不会提高并行度，下游数据库已饱和时扩容反而加剧锁竞争。可将高成本消息拆到独立主题，批量处理可合并提交但要控制单批失败边界。顺序消息不能随意改键并行，要先确认业务可否按更细粒度分区。恢复时从可信位点继续消费，业务处理与消费标识在本地事务内幂等提交，未知副作用先查证。退出应满足完成率稳定高于到达率、最老年龄和队列深度持续下降、重试死信受控、下游资源有余量，并核对历史消息没有造成重复扣减或状态倒退。真实积压峰值和恢复时长要从监控记录获取；演练值明确标 E3（演练设计）。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：增加消费者后积压反而更严重，为什么？ 直接回答 1：可能受分区上限约束，或更多并发压垮数据库和外部接口，导致单条处理时间和重试率上升。
• 追问 2：毒消息如何处理？ 直接回答 2：按业务键隔离到受控重试或死信队列，保留原消息和失败证据，修复后幂等回放，不能阻塞整个分区。
• 追问 3：队列清空是否代表恢复？ 直接回答 3：不代表，还要核对业务副作用、重复率、状态单调和下游资源，防止只是跳过或丢弃了消息。
• 消息容量、积压与排障

15. 问题：legacy-92-c015，如何做分库分表迁移？

• 考点：分片键、双写差异、权威切换与可逆迁移。
• 回答思路：按路由、全量、增量、校验、切读写和收口分阶段回答。
• 详细答案：完整回答以本题口述为准，并由分片迁移正文补充机制。
• 进阶追问：切换后发现少量差异是否立即回退？
• 进阶回答：先冻结批次，按差异类型和权威侧判断；可安全修复则补齐，系统性语义错误才触发回退。
• 口述答案：分库分表迁移先证明单库问题确实来自容量、写入、锁或数据生命周期，而不是索引和查询设计不足。随后明确分片键、路由稳定性、跨片查询、事务、全局标识、扩容频率和回退要求。分片键应让高频读写尽量单片完成并避免热点，订单可按租户或订单维度选择，但支付、库存和履约的访问模式不同，不能只追求均匀。迁移采用可逆阶段：先引入路由层和全局标识，保持旧库为权威；再全量快照迁移并记录水位，同时用变更日志追增量；完成后开启双写或变更捕获，按业务主键比较行数、摘要、金额和状态；随后小流量双读或影子读，确认结果一致；再按租户逐批切读、切写，最后经过完整业务与对账窗口才下线旧路径。双写不是天然一致，必须记录每侧结果、重试和补偿，避免一个成功一个失败后无证据。迁移期间结构与接口保持兼容，禁止同时进行大规模业务语义改造。跨片分页使用稳定游标与归并，聚合可建立派生汇总，但原始事实仍能追溯。故障时冻结切换批次，保留旧库回读能力，按迁移水位和业务键修复差异；回退前确认新库产生的数据已反向同步。验收不仅比较总行数，还要抽样关键字段、业务不变量、迟到更新、删除和资金库存汇总。容量、迁移时长和差异率应由演练及记录证明，不能把计划值冒充生产结果。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：双写阶段以哪边为准？ 直接回答 1：每个阶段必须预先指定唯一权威侧；切换前通常旧库裁决，新库只校验，切写后再经过门槛变更权威。
• 追问 2：只比较总行数为什么不够？ 直接回答 2：总数相同仍可能是错行、错金额、漏更新或重复抵消，应按业务键、字段摘要和不变量分层校验。
• 追问 3：迁移时能否顺便重构状态模型？ 直接回答 3：高风险，不利于定位差异；应先保持语义等价完成迁移，再单独灰度模型变更。
• 分库分表与迁移

16. 问题：legacy-92-c016，如何做缓存一致性？

• 考点：权威事实、失效窗口、版本回填与回源保护。
• 回答思路：先定缓存适用边界，再讲更新、异常和重建。
• 详细答案：完整回答以本题口述为准，并由缓存一致性正文补充机制。
• 进阶追问：如何发现缓存值已经悄悄过期或倒退？
• 进阶回答：携带数据版本，抽样对账数据库，监控旧版本回填、删除失败和高风险业务差异。
• 口述答案：缓存一致性先要区分权威事实与派生副本。对订单、库存和支付，MySQL（关系型数据库）中的业务事实与流水负责裁决，Redis（远程字典服务）缓存只承担加速，不能让缓存写成功替代数据库提交。我先按数据敏感度、读写比例、允许陈旧时间和回源成本决定是否缓存；资金余额或强实时库存不适合用长时间旧值直接裁决。常见更新路径是先在本地事务提交数据库，再删除或失效缓存；删除失败写入可靠重试任务，消费者按业务键幂等执行。并发读可能在更新窗口把旧值重新写回，因此缓存值携带数据版本，回填前比较版本，必要时使用短暂互斥或逻辑过期控制热点重建。延迟双删只能缩小窗口，不能证明严格一致，仍需要版本、订阅变更日志或对账。缓存穿透用参数校验、空值和布隆结构控制，击穿用单飞、逻辑过期与预热，雪崩用过期抖动、限流、隔离和回源预算；热点键要拆分读压力，但拆分不能破坏业务语义。故障时若发现缓存与数据库分叉，先确认影响的是展示还是业务决策；高风险键可临时旁路缓存并限制回源，按数据库版本重建，不能批量清空全部缓存造成冲击。监控命中率之外，还要看回源量、重建耗时、删除失败、版本倒退和业务差异。恢复验收要求高风险样本版本一致、回源受控、热点无持续重建，且数据库资源有余量。缓存有效期、命中率和收益只有监控记录支持时才按 E1（直接证据）陈述。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：为什么先更新缓存再更新数据库风险高？ 直接回答 1：数据库失败会留下不存在的缓存事实，并发覆盖顺序也难控制；应让数据库先形成权威版本，再失效派生缓存。
• 追问 2：删除缓存失败怎么办？ 直接回答 2：记录可靠失效事件并有预算重试，值携带版本限制旧回填，关键数据再用变更日志订阅和对账兜底。
• 追问 3：缓存全挂时如何保护数据库？ 直接回答 3：按业务优先级限流、单飞回源、预热热点、降级非关键查询并逐步恢复，不能让所有请求同时穿透。
• 缓存一致性与缓存问题

17. 问题：legacy-92-c017，如何做链路追踪？

• 考点：上下文传播、异步因果、采样与隐私成本。
• 回答思路：从业务键和追踪标识展开到日志指标联合排查。
• 详细答案：完整回答以本题口述为准，并由链路追踪正文补充机制。
• 进阶追问：追踪上下文丢失如何补救？
• 进阶回答：用稳定业务键跨日志、消息和账本关联，修复传播边界并增加连续性监控。
• 口述答案：链路追踪的目标是把一次业务请求跨服务、线程、消息和外部依赖的因果关系串起来，但它不是日志和指标的替代。我先定义业务关联键，例如订单号、支付意图、履约单或任务实例，再在入口生成追踪标识和跨度标识，通过 HTTP（超文本传输协议）头、消息属性和异步上下文传播。每个跨度记录服务、操作、开始结束时间、状态、父子关系、关键标签和错误，但避免把密码、令牌、完整报文与个人敏感信息写入。异步消息要区分生产、代理等待和消费处理时间，重试和死信保留同一业务关联并创建新的处理跨度，不能把多次尝试伪装成一次。采样策略按风险设计：正常流量可比例采样，错误、慢请求、支付与库存高风险链路提高保留率；采样决定必须尽量保持整条链一致。指标告诉我影响规模，追踪帮助定位路径，日志提供局部细节，账本和数据库事实负责最终业务裁决。排查慢请求时先用业务成功率和尾延迟缩小时间窗，再从追踪看哪个跨度首次异常，并与线程池、连接池、数据库锁、消息最老年龄和外部通道证据交叉验证，不能把最长跨度直接当根因。追踪后端也要限流、缓冲和降级，观测故障不能拖垮业务。发布时验证上下文传播、时钟偏差、标签基数和采样覆盖；恢复验收要求关键链路连续、错误样本可定位、存储成本受控。具体采样率、保留期和定位收益若无配置和记录，应保持 E0（待核对）。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：有了追踪为什么还需要业务键？ 直接回答 1：追踪标识可能因异步、重试或跨组织丢失，稳定业务键能跨多条追踪核对同一业务意图和权威事实。
• 追问 2：百分之百采样是否最好？ 直接回答 2：不一定，会增加业务开销、网络和存储成本；应按风险、错误和慢请求动态提高采样，并验证覆盖率。
• 追问 3：最长跨度就是根因吗？ 直接回答 3：不是，它可能在等待上游锁或下游资源；要结合因果顺序、资源指标、日志和反证定位首个分叉。
• 链路追踪与上下文传播

18. 问题：legacy-92-c018，如何评估架构成本？

• 考点：全生命周期成本、风险损失、单位经济与护栏。
• 回答思路：统一周期与场景，比较资源、人力、故障、变更和退出成本。
• 详细答案：完整回答以本题口述为准，并由成本治理正文补充方法。
• 进阶追问：无法量化故障损失怎么办？
• 进阶回答：给影响区间和敏感性，保留高风险护栏，不用一个虚假精确值消除不确定性。
• 口述答案：架构成本不能只看服务器账单，而要同时计算建设、运行、故障、变更和退出成本，并把它们与业务价值和风险放在同一时间范围内。我先明确评估周期、流量与增长假设、可用性目标和合规要求，再列资源成本，包括计算、存储、网络、备份、跨地域复制、日志追踪与第三方许可；随后加入人力成本，包括开发迁移、值班、升级、安全修复、容量管理和培训。复杂方案还会带来认知负担、交付变慢和故障恢复时间，这些不能因难量化就省略。对每个候选方案建立相同口径的基线、常态、峰值和故障场景，计算单位订单、单位任务或单位设备的边际成本，同时看固定成本和规模拐点。高可用副本、冗余容量和演练预算看似增加支出，却可能降低资金差错、库存错误和长时间停机的预期损失；因此要用发生概率、影响范围和恢复能力比较，而不是单纯选最便宜。成本优化优先找闲置、过度保留、低效查询、无界日志和错误容量假设，再评估降配、自动伸缩、分层存储或采购谈判；不能牺牲业务不变量和恢复目标。每项优化写护栏和回退条件，例如成本下降但尾延迟、完成率或对账差异恶化就停止。账单标签按租户、环境和服务归集，实际值定期与预测比较并复核架构决策。没有真实账单、人天和故障损失时，可以给 E3（演练设计）公式与敏感性，不能宣称已节省具体比例。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：怎样比较自建和采购？ 直接回答 1：统一计算许可、集成、定制、运维、合规、供应商锁定和退出迁移，并比较失败责任与服务边界。
• 追问 2：冗余容量是不是浪费？ 直接回答 2：要看故障目标和扩容准备时间；满足恢复目标所需的安全余量是风险成本，超过证据范围的长期闲置才是优化对象。
• 追问 3：成本优化如何防止伤害稳定性？ 直接回答 3：绑定业务成功率、尾延迟、错误预算、恢复时间和差异率护栏，小步灰度并保留快速回退。
• 成本容量治理与预算

19. 问题：legacy-92-c019，如何推动技术方案落地？

• 考点：共同目标、决策证据、分阶段实施与组织反馈。
• 回答思路：从相关方对齐到实验、门禁、灰度和交接。
• 详细答案：完整回答以本题口述为准，并由架构评审正文补充方法。
• 进阶追问：业务期限不允许完整改造怎么办？
• 进阶回答：先落最小风险控制和可逆接口，记录债务、负责人、触发条件和复核日期，避免临时方案永久化。
• 口述答案：推动技术方案落地不是靠职位要求团队接受，而是把业务问题、证据、决策权和实施风险变成共同可检查的计划。我先与业务、研发、测试、运维、安全和数据角色确认目标、非目标、不可破坏的不变量和成功指标，避免各方讨论的其实是不同问题。方案文档给出至少两个候选、淘汰条件、失败成本、迁移与退出路径，并用 ADR（架构决策记录）保存结论、异议、证据和复核日期。对争议最大的假设做最小 POC（概念验证）或故障演练，验收标准在实验前写定，不能事后挑对自己有利的数据。实施拆成可独立验证的阶段，每阶段明确责任人、依赖、门禁、回退、数据校验和完成证据；高风险数据库、消息契约和资金库存变化先做兼容与影子验证。推广从一个租户、仓库或低风险链路开始，收集业务完成率、质量、交付耗时、值班负担和团队反馈，再决定扩大、调整或撤销。规范尽量通过脚手架、自动检查、模板和监控固化，减少靠口头记忆；例外必须有审批、时限和偿还计划。遇到抵触时先判断是目标不一致、证据不足、迁移成本过高还是责任不清，分别解决，不把不同意见贴成执行力问题。上线后追踪存量迁移、历史脏数据、培训和运维交接，复盘方案是否真的降低风险。个人贡献只陈述能定位的设计、实验、协调或实现动作，团队成果不全部归于自己。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：核心成员反对方案怎么办？ 直接回答 1：把反对意见转成可验证风险，补候选和实验；若触及其责任边界，让对应负责人参与决策并记录异议。
• 追问 2：规范发布后没人遵守怎么办？ 直接回答 2：检查使用成本和例外场景，把关键规则做成自动门禁与模板，保留有时限的例外流程，并用事故和交付指标复核价值。
• 追问 3：如何判断落地完成？ 直接回答 3：不仅代码上线，还要存量迁移、数据校验、监控告警、回退演练、文档培训和责任交接全部有证据。
• 架构决策、评审与技术债

20. 问题：legacy-92-c020，如何证明你具备架构师思维？

• 考点：约束转译、权衡、失败恢复、演进与组织落地。
• 回答思路：用一条可验证决策链和项目证据证明，而非罗列组件。
• 详细答案：完整回答以本题口述为准，并由架构项目题库补充训练。
• 进阶追问：没有架构师头衔能否证明架构能力？
• 进阶回答：可以，用可定位的跨边界决策、风险控制、落地动作和复盘证据说明责任范围。
• 口述答案：我会用一条完整决策链证明，而不是用职位、图的数量或组件清单证明。面对问题时，我先把业务目标转成可验证的质量场景，说明谁在什么条件下发起什么请求、系统要在多长时间内达到什么结果，并识别法规、团队、成本和时间约束。接着找不可破坏的业务不变量与权威事实，例如库存可售非负、支付分录可审计、履约终态不倒退、Runner（执行器）旧租约不能迟到写入。方案阶段保留多个候选，用收益、失败成本、可逆性、运维和演进比较，证据不足就做 POC（概念验证）或保持 E0（待核对），不把偏好包装成结论。设计不仅覆盖正常链路，还明确超时、重复、乱序、网络分区、容量耗尽和外部未知时如何止血、查证、补偿与恢复；退出条件以业务完成率、积压、未知态和对账差异定义。落地阶段用 ADR（架构决策记录）、分阶段迁移、兼容契约、灰度门槛、回退和责任分工控制变化，再通过监控、演练和复盘验证。以 WMS（仓储管理系统）库存为例，我会从冻结责任和流水重算讲到热点隔离与仓内作业；以支付为例，从业务意图、渠道未知和不可变分录讲到对账恢复。哪些是简历或代码能证明的，我按 E1（直接证据）说；哪些只是知识映射或演练，我主动降级。架构师思维最终体现为在约束下做可解释、可验证、可撤销的取舍，并推动团队在长期演进中守住业务事实。面试表达时还要补一句证据边界：旧根资产只是复习入口，新分册负责失败追问和演练深化；若没有源码、监控或工单支撑，所有量级和效果只能按 E3（演练设计）说明，并在后续面试前回到事实卡补证据。
• 追问 1：架构师和高级开发的边界是什么？ 直接回答 1：不是是否写代码，而是是否对跨边界约束、关键取舍、失败恢复、演进和组织落地承担系统性责任。
• 追问 2：方案上线效果不好如何处理？ 直接回答 2：回到原质量场景和证据，区分假设错误、实施偏差和环境变化，先止损，再按预设退出或修正路径行动并更新决策记录。
• 追问 3：怎样避免过度设计？ 直接回答 3：只为当前和可验证增长解决问题，优先可逆方案，用触发阈值决定何时演进，不为不确定未来提前引入高复杂度。
• 架构项目口述与综合题库

10. 复习清单

• 能说明唯一账本为何是旧资产稳定标识的唯一维护点。
• 能复算 88 个标题、28 个主问题、20 条清单和 10 个口述主题的关系。
• 能在回答前声明 E1（直接证据）、E2（已有材料映射）、E3（演练设计）或 E0（待核对）。
• 能从结论、权衡、反例、故障、演进和治理六层接受追问。
• 能把机制链接到 50—54 唯一正文，把故障合同链接到模块 91。
• 能用 WMS（仓储管理系统）、支付、履约、Runner（执行器）调度和 IoT（物联网）报警替换项目场景而不改变事实边界。
• 能在 570 至 900 字内完成纯口述，并直接回答三至五轮追问。
• 能说明止血退出条件、恢复验收和复盘证据，不以“服务恢复”替代业务恢复。
• 能验证 Mermaid（图表语法）图、PlantUML（开源建模工具）图、表格、演绎和真实相对链接。
• 能在并行协作中只修改负责文件，不覆盖、回退或提交他人改动。