知识图谱迁移账本与架构决策路线

本册是模块 14 的唯一迁移账本与串行起点。五个旧根保留全部原文；这里登记的是兼容入口、唯一深化去向与复核证据，不把“引用”伪称为“迁移”。路径与稳定标识符为机器可读例外，不作为链接。

使用边界

• 账本基线日期：2026-07-14；复核人：Codex；复核状态：仅完成任务 1，不宣告五根完成。
• 五根旧资产只读。本次不存在明确弃用，所有弃用计数均为 0。
• 未创建的分册只记录代码路径和预期锚点；创建前不写 Markdown（标记语言）链接。
• 项目表述只可使用 E1（源码与可复现证据）、E2（已有材料映射）、E3（演练样例）或 E0（待核对）四级边界；不得从候选方案反推真实上线事实。

1. 基线、守恒与零弃用

热门面试题

1. 问题：为什么迁移账本先登记基线而不先写新方案？
   • 考点：兼容性与范围控制。
   • 回答思路：说明旧内容是事实入口，新内容是学习深化。
   • 详细答案：先冻结标题、题、图、表和演绎的数量及散列，才能区分后续新增、并发改动和错误覆盖。账本把每项绑定稳定标识和唯一预期去向，保留原文，因此读者仍能从旧根复习，维护者也能证明没有遗失资产。
   • 进阶追问：散列变化后能否继续收口？
   • 进阶回答：不能；先按当前事实重算并更新账本，再决定是否继续。
2. 问题：本次为什么所有根的弃用数都是零？
   • 考点：非破坏迁移。
   • 回答思路：区分重复阅读入口和删除资产。
   • 详细答案：旧根仍承担兼容入口，分册只承接更细的讲解与交叉引用。没有逐项经过内容、事实和链接复核前，任何旧资产都不应标为弃用；因此五组等式均由“保留在旧根”单独守恒。
   • 进阶追问：以后发现过时内容怎么办？
   • 进阶回答：保留原文并补充纠错说明、证据与替代路径，再单独登记弃用理由。
3. 问题：标题与知识小节为什么不能重复相加？
   • 考点：统计口径。
   • 回答思路：指出知识小节是标题子集。
   • 详细答案：标题用于迁移资产守恒，知识小节只用于核对题量结构。将二者相加会把同一段落算两次，导致基线虚增；图、表和演绎虽可依附标题，但作为可独立复核的资产类别分别登记。
   • 进阶追问：同一标题既是演绎怎么办？
   • 进阶回答：分别保留标题标识和演绎标识，两个类别各自守恒。

2. 逐项账本与稳定标识

热门面试题

1. 问题：一个旧资产为什么只能有一个目标分册？
   • 考点：责任边界。
   • 回答思路：说明主讲解与交叉引用的区别。
   • 详细答案：唯一目标让维护者知道哪一册负责深化、修订和验收，避免两个分册各自复制一段机制后悄悄分叉。其他分册可以引用该目标，但不能成为第二个迁移主账；旧根仍保留原文作为兼容入口。
   • 进阶追问：一个表同时涉及容量和业务指标怎么办？
   • 进阶回答：按其原始主问题指定唯一责任册，另一册只建立引用关系。
2. 问题：为什么账本要保留旧根锚点和行级资产摘要？
   • 考点：可追溯性。
   • 回答思路：把人工复核与稳定标识关联起来。
   • 详细答案：标题会改名、文档会扩写，稳定标识和旧锚点能让复核者回到原始入口；表以前表头、图以前置标题、题以题干摘要定位，避免仅靠自然语言搜索造成误配。
   • 进阶追问：预期锚点未创建是否算坏链接？
   • 进阶回答：不算；本册以代码路径登记，直到目标文件存在才建立可点击链接。
3. 问题：账本中“保留引用；后续深化”是什么意思？
   • 考点：处理类型。
   • 回答思路：说明当前状态和未来责任。
   • 详细答案：当前处理是保留引用，表示旧资产未删除且计入兼容项；后续深化是计划，不增加或减少本次基线。只有目标分册创建、存在可验证锚点并复核后，才可把状态补充为已深化，但旧根资产仍不从等式中消失。
   • 进阶追问：能否把状态写成已迁移？
   • 进阶回答：不能，因为本次没有移动或删除旧根原文。

账本字段定义

旧根 50 的逐项账本

旧根 51 的逐项账本

旧根 52 的逐项账本

旧根 53 的逐项账本

旧根 54 的逐项账本

3. 从业务问题到可撤销决策

热门面试题

1. 问题：架构设计为什么先问业务目标、角色和不变量？
   • 考点：问题建模。
   • 回答思路：先固定不能错的结果，再讨论实现。
   • 详细答案：业务目标决定成功信号，角色决定操作边界，不变量决定绝不能被并发、重试或失败破坏的事实。以库存为例，先明确可售量不能为负、锁定必须可释放，才讨论缓存、消息或数据库；以支付为例，先定义金额守恒和状态可追溯，才讨论异步化。
   • 进阶追问：量级不清时能否直接选组件？
   • 进阶回答：不能；先登记峰值、增长、时限和不确定项，用演练样例说明假设。
2. 问题：候选方案为什么必须包含不选它的条件？
   • 考点：权衡与反例。
   • 回答思路：方案不是名词清单，而是约束下的选择。
   • 详细答案：候选方案要同时陈述收益、代价、前提、失败成本和退出路径。只罗列优点会把局部最优包装成普适答案；写出淘汰条件，才能在约束变化时重新评估，也让评审者知道哪些验证必须由概念验证完成。
   • 进阶追问：什么时候应保留单体？
   • 进阶回答：当边界、流量、团队和发布节奏都不能证明拆分收益大于协作成本时。
3. 问题：什么是可撤销决策？
   • 考点：演进与风险。
   • 回答思路：比较接口、数据和组织层面的回退成本。
   • 详细答案：可撤销不是“可以回滚按钮”，而是数据、契约、流量和运行能力都能回到已验证状态。先用兼容字段、双读校验、灰度与回放把风险切小；若涉及资金账务或历史数据语义，撤销成本高，必须先补证据、评审和明确停止条件。
   • 进阶追问：撤销条件谁来定义？
   • 进阶回答：决策记录中由业务、研发和运行责任人共同定义，并绑定观测信号。

flowchart LR
  A[业务目标与角色] --> B[不变量与量级]
  B --> C[约束与质量属性]
  C --> D[候选方案]
  D --> E[证据与概念验证]
  E --> F[决策记录]
  F --> G[架构方案]
  G --> H[容量与服务目标]
  H --> I[业务指标]
  I --> J[迁移与复审]
  J -->|失败或约束变化| B

图解读：节点依次表示问题、边界、候选、证据、决策、运行与演进；箭头表示前一项必须提供下一项的输入。前提是先确认业务语言，正常路径形成可评审方案；失败路径由指标或复审回到量级与约束，结论是架构不是一次性画图。

sequenceDiagram
  participant 业 as 业务负责人
  participant 架 as 架构负责人
  participant 研 as 研发负责人
  业->>架: 目标、角色、成功与失败
  架->>研: 不变量、峰值、已有约束
  研-->>架: 未知项与实现边界
  架-->>业: 可验证澄清清单
  alt 量级或规则缺失
    架-->>业: 标记为演练假设
  else 信息足够
    架->>架: 进入质量属性排序
  end

图解读：参与者是业务、架构与研发；请求箭头汇集约束，返回箭头暴露未知项。前提是没有先指定技术，正常路径进入排序；失败路径保留假设而非虚构数据，结论是问题澄清是后续决策的输入。

4. 事实等级、版本与指标禁区

热门面试题

1. 问题：为什么不能把演练容量写成项目真实吞吐？
   • 考点：证据边界。
   • 回答思路：区分公式正确与事实成立。
   • 详细答案：演练可用于说明估算方法，却不能证明线上环境、数据分布、依赖延迟或发布配置相同。没有源码、运行记录或原始数据时，量级、成本、服务目标和业务结果都只能标为 E3（演练证据）或 E0（待核对），并写出输入、公式、观测信号和需核对来源。
   • 进阶追问：已有简历描述能到哪个等级？
   • 进阶回答：通常是 E2（已有材料映射），可讲候选设计，不可宣称已上线效果。
2. 问题：版本禁区解决什么问题？
   • 考点：可验证陈述。
   • 回答思路：版本、阈值和供应商能力都必须可追溯。
   • 详细答案：没有锁文件、配置、运行记录或权威材料时，不能写具体版本行为、默认参数、性能排名或兼容承诺。版本禁区防止读者把教材式机制误认为当前环境事实；需要版本结论时，登记待核对来源和复现步骤。
   • 进阶追问：可否引用旧文档中的版本？
   • 进阶回答：可以作为历史材料，但仍需标注来源时间与适用边界。
3. 问题：指标禁区为什么覆盖业务与技术两侧？
   • 考点：反馈控制。
   • 回答思路：解释单一指标会误导优化。
   • 详细答案：只看错误率会忽略支付成功与履约完成，只看转化会忽略数据迟到和重复，只看平均延迟会忽略长尾。指标必须有口径、归属、采集链路、质量检查和行动阈值；缺任何一项，都不能作为架构演进的事实依据。
   • 进阶追问：指标异常先扩容吗？
   • 进阶回答：先核验数据质量、变更与依赖，再判断饱和度和容量。

flowchart TD
  A[陈述请求] --> B{有直接证据}
  B -->|有| C[E1或E2]
  B -->|无| D{可复算假设}
  D -->|有| E[E3演练]
  D -->|无| F[E0待核对]
  C --> G[限定结论]
  E --> G
  F --> H[列出缺失证据]

图解读：节点是陈述、证据、假设与结论；判断箭头把事实与演练分开。前提是先查本地材料，正常路径给出等级；失败路径进入待核对，结论是证据等级限制语言强度。

5. 架构决策九维与权衡

热门面试题

1. 问题：为什么质量属性不能只列可用性和性能？
   • 考点：完整决策面。
   • 回答思路：把安全、成本和演进纳入同一约束。
   • 详细答案：系统在流量正常时可用并不表示可维护、可恢复或可承担成本。九维把业务价值、正确性、性能、可靠性、安全、可观测性、成本、团队与演进放在同一张表，迫使方案同时说明收益、代价、验证与退出，而不是只展示一张架构图。
   • 进阶追问：九维是否每次等权？
   • 进阶回答：不等权；支付优先正确性与审计，报警风暴优先削峰与可恢复。
2. 问题：如何处理两个质量属性相互冲突？
   • 考点：权衡。
   • 回答思路：明确不可退让项、可降级项和触发条件。
   • 详细答案：先把冲突转为场景，例如读延迟、写确认和故障恢复不能同时无限优化；再定义不变量、服务目标、降级策略和失败成本。候选方案用同一输入比较，概念验证检查最不确定部分，决策记录写明何时复审或撤销。
   • 进阶追问：谁有权接受失败成本？
   • 进阶回答：业务责任人与技术责任人共同签署，并在决策记录中留痕。
3. 问题：成本为什么是架构属性而不是采购问题？
   • 考点：全生命周期成本。
   • 回答思路：说明资源、运维、迁移和机会成本。
   • 详细答案：组件价格只是成本的一部分，数据存储、流量、值守、告警噪声、培训、锁定和退出都会改变总成本。把成本放入决策表，才能比较“立即快”和“长期可演进”的差异，并避免用未核实价格支持结论。
   • 进阶追问：成本缺数据怎么办？
   • 进阶回答：列成本项、敏感变量和待取证账单，不报虚构金额。

sequenceDiagram
  participant 架 as 架构负责人
  participant 证 as 证据库
  participant 评 as 评审组
  participant 记 as 决策记录
  架->>证: 提交候选与假设
  证-->>架: 返回证据缺口
  架->>评: 比较九维与失败成本
  alt 证据不足
    评-->>架: 要求最小验证
  else 可作决定
    评->>记: 记录决策、后果、撤销条件
  end

图解读：参与者是负责人、证据、评审与决策记录；箭头要求先证据后结论。前提是候选共享同一约束，正常路径留下可复审记录；失败路径返回最小验证，结论是分数不能替代证据。

6. 依赖路线、资产索引与职责

热门面试题

1. 问题：为什么 50 要先于 51、53 和 54？
   • 考点：共同决策语言。
   • 回答思路：先固定问题框架，再并行填充证据。
   • 详细答案：50 定义业务目标、不变量、质量属性、评审和撤销条件，51 才能据此选择候选，53 才能给出容量与恢复约束，54 才能确认业务反馈口径。52 消费这些输入形成端到端案例，避免案例先定技术、再倒推理由。
   • 进阶追问：53 和 54 能否并行？
   • 进阶回答：可以；二者共享事实等级和决策九维，但输出不同约束。
2. 问题：为什么每册都要有可编辑图源和 PNG（便携式网络图形）？
   • 考点：图形可维护性。
   • 回答思路：说明源文件、渲染产物和审阅职责。
   • 详细答案：图源允许后续修改、差异审查和重新渲染，PNG（便携式网络图形）让阅读者无需工具即可查看。只保留图片会失去结构和可验证性，只保留源文件会降低阅读可达性；因此索引同时登记路径、责任册和状态。
   • 进阶追问：为什么当前图用时序图？
   • 进阶回答：本机缺少图布局程序，时序图仍可真实渲染，且最适合表达决策闭环。
3. 问题：案例册为什么依赖容量与业务指标？
   • 考点：端到端闭环。
   • 回答思路：案例不能只讲数据流。
   • 详细答案：架构方案必须回答峰值、恢复、资源边界和业务成功信号，否则无法判断它是否适用。容量约束防止方案在高峰失效，业务指标防止技术优化偏离目标；两者都需带事实等级，不能把预期写成既成结果。
   • 进阶追问：未完成的分册如何被引用？
   • 进阶回答：只写代码路径和预期锚点，文件存在后再转换为真实链接。

flowchart LR
  A[50 决策语言] --> B[51 候选与证据]
  A --> C[53 容量与恢复]
  A --> D[54 指标与事实]
  B --> E[52 端到端案例]
  C --> E
  D --> E
  E --> F[复审与迁移]

图解读：节点是五根的唯一职责，箭头是消费关系。前提是 50 先建立方法，正常路径由三类约束汇入案例；失败路径在复审中回到对应责任册，结论是案例不复制共同机制。

38 个正式图资产索引

7. 容量、可靠性与指标反馈

热门面试题

1. 问题：容量估算如何进入架构决策而不是停留在公式？
   • 考点：约束驱动设计。
   • 回答思路：把输入、假设、瓶颈和行动串起来。
   • 详细答案：从业务峰值、读写比例、单次资源消耗和依赖延迟建立演练输入，再用队列、并发和冗余约束推导候选规模。输出不仅是实例数，还要包含饱和信号、扩容阈值、降级策略和复验方式；没有真实记录时明确标 E3（演练证据）。
   • 进阶追问：平均值够吗？
   • 进阶回答：不够；峰值、长尾、突发和依赖失败会决定排队。
2. 问题：可靠性与业务指标如何相互校验？
   • 考点：因果闭环。
   • 回答思路：技术信号告诉系统是否健康，业务信号告诉目标是否达成。
   • 详细答案：支付接口的成功率、超时和积压应与支付完成、退款和对账差异一起看；库存服务的延迟与超卖拦截、锁定释放和人工介入一起看。两边口径不一致时先检查事件迟到、重复和版本变化，再讨论架构调整。
   • 进阶追问：技术指标正常但业务下降怎么办？
   • 进阶回答：检查业务规则、上游渠道、埋点语义和数据质量，不能仅扩容。
3. 问题：为什么迁移要保留回退路径？
   • 考点：反馈控制。
   • 回答思路：迁移是改变事实链路，必须能验证和撤销。
   • 详细答案：迁移前定义双读或对账口径、灰度范围、异常阈值和停止条件；迁移中观察正确性、容量和业务信号；迁移后复盘差异。若出现不变量破坏或指标无法解释，先停止扩大范围并回退到已验证版本，而不是继续补丁。
   • 进阶追问：回退是否总能恢复数据？
   • 进阶回答：不能；不可逆写入必须在设计前通过兼容和回放降低风险。

sequenceDiagram
  participant 业 as 业务指标
  participant 运 as 运行观测
  participant 架 as 架构负责人
  participant 变 as 迁移执行
  业-->>架: 成功口径与异常信号
  运-->>架: 容量、延迟、错误与恢复信号
  架->>变: 小范围迁移与校验
  alt 信号满足阈值
    变-->>架: 扩大范围
  else 信号异常
    变-->>架: 停止并回退
    架->>架: 复审假设与决策
  end

图解读：业务与运行分别提供结果和机制信号，迁移执行接受限幅指令。前提是阈值已在决策记录中定义，正常路径逐步扩大；失败路径停止并复审，结论是指标是控制器输入而不是展示页。

八个可复算数据与决策演绎

8. 审计、排障与项目表达

热门面试题

1. 问题：架构评审发现指标突变时，第一步是什么？
   • 考点：排障顺序。
   • 回答思路：先验证事实，再定位变更和资源。
   • 详细答案：先确认指标定义、时间窗口、去重规则和数据迟到，再对照发布、配置、依赖、流量和业务活动。若事实链路可靠，继续看错误、长尾、队列、资源饱和与恢复动作；若事实链路不可靠，先修复数据质量，不能直接把异常解释为系统退化。
   • 进阶追问：为什么不先看机器负载？
   • 进阶回答：机器负载可能是结果，且不能证明业务口径正确。
2. 问题：如何在项目口述中避免虚构上线指标？
   • 考点：证据化表达。
   • 回答思路：区分已有材料、候选方案和演练。
   • 详细答案：先说可追溯的业务背景与既有机制，再说“作为面试方案我会如何设计”，对容量、成本和结果使用演练输入与公式，最后列出需要源码、监控或账单核对的证据。这样既展示架构判断，也不把未知内容包装为经验。
   • 进阶追问：面试官追问真实数值怎么办？
   • 进阶回答：如实说明当前无可追溯记录，并给出会如何取数与复验。
3. 问题：完成红线为什么包含图形渲染和差异检查？
   • 考点：交付可用性。
   • 回答思路：内容正确不代表文件可读、可维护。
   • 详细答案：图源可能语法错误，图片可能过期，链接可能指向不存在的文件，格式错误也会让后续合并困难。审计应同时核对题目字段、标记、数量、术语、链接、图形渲染、散列前后不变和差异空白错误；任何一项失败都只报告风险，不标记完成。
   • 进阶追问：旧根散列变了怎么办？
   • 进阶回答：停止根收口，保留并发事实，重新建账后再继续。

sequenceDiagram
  participant 读 as 阅读者
  participant 指 as 指标面板
  participant 变 as 变更记录
  participant 运 as 运行证据
  participant 架 as 架构负责人
  读->>指: 发现异常
  指->>架: 提供口径与时间窗
  架->>变: 对照发布与配置
  架->>运: 查询依赖、队列与资源
  alt 事实链路异常
    架-->>读: 修复口径后重算
  else 系统链路异常
    架-->>读: 限流、回退或扩容并复验
  end

图解读：阅读者触发排查，指标、变更和运行证据提供不同维度输入。前提是异常有时间窗，正常路径定位后复验；失败路径先修复事实链路，结论是排障必须区分数据问题和系统问题。

flowchart TD
  A[审计开始] --> B[数量与守恒]
  B --> C[标记、题目与术语]
  C --> D[链接与图形渲染]
  D --> E[散列与差异检查]
  E --> F{是否全部通过}
  F -->|是| G[报告可复核结果]
  F -->|否| H[记录风险并停止收口]

图解读：节点是交付检查顺序，箭头表示后项依赖前项的事实。前提是只检查本次允许写入的范围，正常路径报告证据；失败路径停止收口，结论是完成状态必须由审计而非主观判断决定。

sequenceDiagram
  participant 架 as 架构负责人
  participant 评 as 评审组
  participant 实 as 实施负责人
  participant 观 as 观测信号
  架->>评: 提交目标、候选、证据与撤销条件
  评->>实: 批准小范围执行
  实->>观: 采集正确性、容量与业务信号
  alt 信号异常
    观-->>实: 触发停止条件
    实-->>架: 回退并提交失败证据
  else 信号稳定
    观-->>架: 进入复审与演进
  end

图解读：评审批准的是小范围执行，不是永久结论；观测信号决定扩大还是回退。前提是停止条件已定义，正常路径进入复审；失败路径回退并保留证据，结论是失败也应成为下一次决策输入。

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

本标题只结束上一个知识小节，以下内容是模块级题库，不计入知识小节数量。

综合题库

综合题 01：从业务目标开始设计库存防超卖

1. 问题：请设计一个库存防超卖方案，并说明为什么不是先选缓存。
   • 口述答案：我会先把问题从“用什么组件”改写成业务约束：谁在什么时刻拥有可售资格，订单取消或超时后怎样释放，库存不能为负这一不变量由谁最终裁决。然后区分读展示、下单预占、支付确认、仓内扣减和对账五条路径，给每条路径标注同步响应要求、可延迟步骤和失败补偿。候选方案至少比较数据库条件更新、缓存预扣加异步确认、以及队列串行化，比较的不是名气而是并发冲突、可恢复性、团队运维能力和回退成本。若没有真实峰值和压测记录，我只会给出以峰值、单实例能力和冗余系数为输入的演练样例，不会报成线上承载量。最终决策记录要写明锁定超时、重复请求、消息丢失、对账差异的处理和停止条件；上线后同时看扣减失败、锁定释放、超卖拦截和人工介入，任一指标异常先验证口径和不变量，再决定限流、降级或回退。旧根的项目背景可见架构设计入口与案例入口。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
   • 进阶追问：缓存预扣失败后如何处理？
   • 进阶回答：以最终库存事实为准，保留可重试事件并对账补偿。
   • 进阶追问：为何不能只靠异步消息？
   • 进阶回答：下单路径需要明确的预占结果，异步只能承接后续确认与修复。
   • 进阶追问：超卖拦截增多说明系统变好了吗？
   • 进阶回答：不一定；还要看规则变化、流量、误拦截和人工修复。

综合题 02：支付正确性优先的方案取舍

2. 问题：支付回调未知态与订单取消并发时，怎样做架构决策？
   • 口述答案：我先固定资金正确性和状态可追溯两个不可退让项：支付单、业务订单和账务记录各自负责什么事实，外部回调、主动查询和人工处理怎样收敛到同一状态机。未知态不能凭一次超时直接判失败，也不能因为回调到达就重复入账；因此每个外部请求都要有幂等键、请求和响应留痕、状态版本与可重试边界。候选方案会比较同步查单、异步补偿和人工审核的时效、成本与误判风险，并把渠道超时、回调伪造、重复通知、订单取消竞争和退款冲正放进失败路径。没有本地运行记录时，成功率、延迟和资损比例只作为演练观察项，不宣称真实效果。决策记录应包含何时停止自动推进、何时转人工、如何对账以及撤销条件；运行中同时观察技术错误、查单积压、账务差异和业务完成，任何差异先保证账务事实可追溯，再改善体验。已有机制可交叉阅读支付与履约模块。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
   • 进阶追问：为什么支付单和订单要分离？
   • 进阶回答：二者生命周期、重试和审计边界不同，分离才能处理未知态。
   • 进阶追问：回调重复怎么防？
   • 进阶回答：以业务幂等键和状态转换条件共同约束。
   • 进阶追问：对账差异先改数据吗？
   • 进阶回答：不能；先保留原始证据、定位来源并走可审计补偿。

综合题 03：跨境履约的边界与演进

3. 问题：如何设计跨境物流履约，并避免服务拆分过度？
   • 口述答案：我会从订单已支付到妥投的业务链路开始，先识别订单、库存、面单、承运商、轨迹和异常处理的责任边界，再问每一段的事实来源、外部契约、允许延迟和失败补偿。拆分不是按技术层或表数量，而是按不变量、变更节奏、组织协作和故障隔离；例如承运商适配可独立演进，订单履约状态仍需有清晰的主责。候选方案必须写出同步调用、事件通知、重试、去重、乱序和第三方超时的处理，以及新承运商接入时的防腐层和退出路径。容量方面只以演练输入说明高峰发货、面单生成与轨迹消费如何影响队列和依赖，不把未知数据说成线上规模。运行反馈既看接口错误、长尾和积压，也看揽收及时、轨迹迟到和异常件处理；若业务指标下降而技术指标正常，要回到契约、数据迟到和规则变更核验。项目机制可见支付与履约模块和存储搜索模块。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
   • 进阶追问：第三方超时应立即重试吗？
   • 进阶回答：先按幂等、限额和退避策略判断，避免放大对方故障。
   • 进阶追问：轨迹乱序怎么处理？
   • 进阶回答：按事件时间、版本和状态机校验，不按到达顺序覆盖。
   • 进阶追问：何时停止拆分服务？
   • 进阶回答：当边界收益不足以覆盖调用、运维和协作成本时停止。

综合题 04：异步导出从排队到回退

4. 问题：请设计大批量异步导出，并给出容量和失败治理思路。
   • 口述答案：我会先澄清导出对象、数据权限、最大时间窗、文件保留期和用户可见的完成语义，再把请求受理、任务持久化、分片读取、文件生成、通知和下载审计拆开。核心不变量是任务状态可追溯、同一请求不会生成无限重复任务、权限不能因异步过程丢失。候选方案比较进程内线程池、独立任务队列和专用执行器，重点看隔离、限流、取消、重试、资源上限和失败后能否定位分片。容量不报真实数字，而是以单页读取、单任务内存、并发任务数和文件写入速率作为演练输入，观察队列等待、长尾、磁盘与对象存储失败。运行时若任务积压，先检查生产速率、消费速率、慢查询和下游写入，再做限流、暂停或扩容；不能只增加线程，因为数据库和存储可能已饱和。迁移时保留旧下载入口、双写任务审计并可回放。可参考运行与观测模块。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
   • 进阶追问：任务重试如何避免重复文件？
   • 进阶回答：使用任务幂等键、状态机和临时文件原子发布。
   • 进阶追问：如何取消任务？
   • 进阶回答：在分片边界检查取消标记，并记录已产生资源的清理动作。
   • 进阶追问：队列积压先扩消费者吗？
   • 进阶回答：先识别瓶颈是否在读取、计算、写入或外部存储。

综合题 05：执行器调度与隔离

5. 问题：如何设计 Runner（执行器）调度，避免慢任务拖垮关键任务？
   • 口述答案：我会从任务类型、提交者、时限、资源需求、可重试性和结果语义开始建模，而不是把所有任务塞进同一个队列。关键任务与批量任务必须有独立的配额、并发上限、超时、优先级和拒绝策略；任务状态要能表达待执行、运行中、成功、失败、取消和人工介入，任何重试都带幂等键和最大次数。候选设计会比较数据库轮询、消息驱动和独立调度服务，并评估时钟误差、重复领取、执行器失联、长任务心跳、资源泄漏和结果回写的失败成本。若缺少真实容量记录，只提供生产速率、平均执行时长、并发槽位和积压上限的演练推导。运行中把排队时长、成功率、重试率、拒绝数、执行时长分位和业务完成率一起观察；异常时优先隔离噪声任务、暂停入口和回收失联租约，再决定扩容。架构演进应保留旧调度协议和回放能力。可参考运行与观测模块。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
   • 进阶追问：如何防止同一任务被两个执行器执行？
   • 进阶回答：领取要有租约、版本校验和结果提交条件，失联后延迟接管。
   • 进阶追问：长任务为什么需要心跳？
   • 进阶回答：用于区分仍在运行与已失联，避免过早重复领取。
   • 进阶追问：高优先级是否永远抢占？
   • 进阶回答：需要配额和老化策略，否则低优先级会永久饥饿。

综合题 06：物联网报警风暴治理

6. 问题：面对 IoT（物联网）报警风暴，如何从业务目标设计治理方案？
   • 口述答案：我先明确报警不是消息数量竞赛，而是让值班人员在有限时间内识别真正影响业务的异常。因此要区分设备事件、规则命中、告警实例、通知与工单五类事实，规定同一设备、同一规则和同一时间窗内怎样聚合、去重、升级和恢复。候选方案会比较入口限流、规则分级、窗口聚合、队列削峰、通知抑制和人工确认，重点验证故障时是否会丢失关键报警、是否会把恢复通知淹没、以及规则变更是否可追溯。没有生产日志时，吞吐、成本和降噪比例只能写为演练假设，不能说成线上效果。容量设计同时观察入口速率、队列积压、规则计算时长、通知失败与恢复时长；业务侧观察有效告警、确认时长、重复率和漏报复核。指标异常先核验事件时间、规则版本和采集链路，再限流或降级；迁移时先小范围启用新规则，保留旧规则结果用于差异对比与回退。可参考运行与观测模块。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
   • 进阶追问：聚合会不会漏掉关键报警？
   • 进阶回答：关键等级可绕过聚合，普通等级按窗口保留原始事件证据。
   • 进阶追问：如何处理规则版本切换？
   • 进阶回答：事件带规则版本，灰度比较结果后再扩大范围。
   • 进阶追问：通知失败算报警失败吗？
   • 进阶回答：要分开统计；告警生成、通知送达和人工确认是不同状态。

综合题 07：技术选型的证据链

7. 问题：当团队在数据库、缓存和消息方案间争论时，怎样推动技术选型？
   • 口述答案：我不会先给组件排名，而是建立同一份工作负载卡：读写比例、数据形态、一致性、延迟、增长、可用运维能力、合规和退出需求。先用硬约束淘汰不满足不变量或数据边界的候选，再比较剩余方案的正确性、性能、恢复、安全、成本和演进，且每个分数都要有来源和不适用反例。最不确定的假设进入最小概念验证，例如验证高并发写入、故障恢复、索引重建或消息积压时的行为；概念验证只证明实验条件下的结果，不能替代生产承诺。决策记录应写明为何选、为何不选、后果、迁移出口、撤销条件和复审日期。若缺少本地证据，我会把具体版本、价格和性能数字标为待核对，而不引用印象。实施后看技术稳定、容量和业务结果是否一致；若业务变化导致原约束失效，应重新评审，而不是把旧选型当信条。原有选型讨论可见技术选型入口。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
   • 进阶追问：评分矩阵能直接得出结论吗？
   • 进阶回答：不能；它只能暴露权重和差异，关键风险还需证据验证。
   • 进阶追问：概念验证失败意味着什么？
   • 进阶回答：说明假设未被证实，应记录失败成本并调整候选或约束。
   • 进阶追问：如何避免供应商锁定？
   • 进阶回答：预先设计数据导出、接口隔离、双写校验和退出演练。

综合题 08：容量与服务目标的联合评审

8. 问题：如何把容量、可靠性和成本纳入同一次架构评审？
   • 口述答案：我会先明确服务的关键用户路径和允许失败方式，再把峰值请求、依赖延迟、数据增长、恢复时间和预算放到同一张约束表。容量估算从可复算输入开始，例如峰值、单实例能力、冗余和队列积压变化；可靠性讨论故障域、降级、备份、演练和恢复责任；成本讨论资源、存储、流量、值守和迁移，不把任何未知金额说成实际账单。评审的输出不是单一实例数，而是服务目标、饱和阈值、扩容或限流动作、失败回退、验证方法和复审日期。压测或演练发现长尾上升时，先判断是依赖、锁、队列、资源还是数据分布，再选择优化或扩容；若业务成功口径没有同步改善，要检查是否优化了错误目标。对支付、库存等正确性敏感路径，宁可限制入口也不能用超卖或错账换吞吐。容量与稳定性背景可见稳定性入口。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
   • 进阶追问：服务目标由技术单独决定吗？
   • 进阶回答：不应；它体现业务价值、失败成本和可投入资源的共同选择。
   • 进阶追问：冗余系数为何不是固定值？
   • 进阶回答：它取决于故障域、发布方式、流量波动和恢复能力。
   • 进阶追问：成本高就应降低可靠性吗？
   • 进阶回答：应比较失败成本和替代措施，而不是简单削减保护。

综合题 09：业务指标驱动架构演进

9. 问题：业务指标下降时，怎样判断是否需要架构演进？
   • 口述答案：我会先审查指标是否可信：事件定义、主体、时间窗、去重、迟到处理和版本变化是否一致，再把业务漏斗与技术链路按同一时间轴对齐。若支付完成下降，同时检查渠道错误、接口长尾、回调未知态、订单状态和数据迟到；若履约时效下降，同时检查承运商、面单、队列和轨迹消费。只有确认事实链路可靠后，才判断瓶颈是在容量、契约、规则、数据模型还是组织协作。架构演进应从最小可逆改变开始，例如增加限流、修复重试、隔离慢依赖、扩展读模型或调整事件契约，并预设对账、灰度、停止条件和回退。没有原始数据时，任何转化提升、成本降低或吞吐增长都只能描述为待验证目标。复审时同时看业务结果、技术服务目标、数据质量和人工成本，避免只优化页面访问或平均延迟。指标语义可参考业务指标入口。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
   • 进阶追问：技术指标稳定但漏斗下降怎么办？
   • 进阶回答：检查业务规则、渠道、前端流程和埋点语义，不假定系统容量问题。
   • 进阶追问：如何确定灰度样本？
   • 进阶回答：按风险、角色和业务链路分层，并保留对照和停止阈值。
   • 进阶追问：何时回退？
   • 进阶回答：不变量受损、关键护栏越界或差异无法解释时立即停止扩大。

综合题 10：从故障现象回到错误决策

10. 问题：线上出现长尾、积压和业务投诉时，如何判断是实现问题还是架构决策问题？

• 口述答案：我会按事实、变化、资源、依赖和业务影响五层排查。先确认监控口径和时间窗，再对照发布、配置、流量结构和外部依赖；随后看线程、连接、队列、数据库和网络的饱和与排队。实现问题通常能在明确组件、单次变更或局部资源上定位；架构决策问题则表现为边界不清、同步链路过长、缺少隔离、数据所有权冲突、没有回退或指标无法解释。不能因为看到积压就断言消息系统选错，也不能因为一次超时就拆服务。要把现象映射到当初的目标、约束、候选、证据和撤销条件，检查假设是否失效。处置上先保护不变量和关键用户路径，采取限流、降级、回退或暂停迁移；恢复后补足证据、决策记录和演练。项目口述应说明自己掌握的事实与待核对边界，不能编造事故规模。运行排查材料可见运行与观测模块。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
• 进阶追问：长尾先看平均值吗？
• 进阶回答：先看分位、关联依赖和排队，平均值可能掩盖少量关键失败。
• 进阶追问：何时应该回滚发布？
• 进阶回答：有明确变更关联且触及关键护栏或不变量时，先回滚再分析。
• 进阶追问：如何证明是架构问题？
• 进阶回答：用跨组件重复出现的证据与原决策假设失效来说明。

综合题 11：多模型数据边界

11. 问题：交易、搜索、分析和时序数据为何不能共用一个事实模型？

• 口述答案：我会先按事实写入、查询模式、正确性和保留周期区分数据责任。交易数据需要可审计的主事实和明确状态转换，搜索适合面向检索的派生索引，分析适合聚合与批处理，时序数据适合按时间写入和窗口计算。把它们硬塞进同一个模型，常见后果是交易写入被报表拖慢、搜索索引被当成最终事实、分析延迟被误判为业务失败。设计时要明确谁是主责数据源、派生如何生成、延迟和重放如何处理、查询降级时展示什么，以及迁移和回放怎样校验。选型不能只看单点性能，要比较一致性、数据形态、运维、成本、权限和退出路径；没有实测资料时只写验证计划。上线后同时监控主事实与派生差异、索引延迟、查询长尾和业务可见结果，差异异常先暂停扩大同步范围并回放或对账。存储边界可参考存储搜索模块。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
• 进阶追问：搜索索引为什么不能直接做订单事实？
• 进阶回答：索引是派生结果，可能延迟、丢字段或重建，不能替代交易审计。
• 进阶追问：如何处理派生失败？
• 进阶回答：保留可重放事件、幂等写入和差异校验。
• 进阶追问：何时需要新的数据模型？
• 进阶回答：当查询、保留、延迟或正确性需求与主模型长期冲突时。

综合题 12：迁移、兼容与退出

12. 问题：请说明一次存储或消息迁移如何做到可验证、可回退。

• 口述答案：我会先写清迁移目的、业务不变量、数据范围、兼容窗口和退出原因，再定义源与目标的主责关系。实施分为准备、双写或回放、差异校验、小范围读切换、扩大流量和下线六步，每步都有输入、观测、停止条件和回退动作。双写不是天然安全，它会带来时序、重复、失败不一致和成本增加，因此要定义幂等键、版本、重试、死信、对账与人工修复。数据量、吞吐、成本和时长没有原始记录时，只能用演练公式说明，不把计划当成果。灰度期间同时看正确性差异、读写延迟、积压、错误、资源与业务完成；任何不变量破坏、差异持续放大或观测缺失都应停止扩大范围，回到已验证版本。下线旧链路前保留足够的回放和审计窗口，并在复审中记录真实证据、剩余风险和下一次检查日期。相关存储机制可见存储搜索模块。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
• 进阶追问：双写失败先重试还是回退？
• 进阶回答：按不变量和幂等边界判断；无法保证一致时先停止扩大范围。
• 进阶追问：何时能下线旧系统？
• 进阶回答：差异稳定为零或在允许范围、回放演练通过且审计窗口结束后。
• 进阶追问：为什么要保留回放？
• 进阶回答：用于补齐失败记录、重建派生结果和验证迁移差异。

综合题 13：评审一份架构方案

13. 问题：拿到一份看起来完整的架构图，你如何做方案评审？

• 口述答案：我先不评价图是否漂亮，而是追问它服务的业务目标、角色、成功与失败定义、量级和不变量。接着检查九维：正确性、性能、可靠性、安全、可观测性、成本、团队和演进是否都有明确取舍；每个候选是否写出不适用条件、证据、失败成本与退出路径。然后沿关键数据流走一遍正常、超时、重复、乱序、依赖不可用和恢复路径，确认状态事实、权限、审计和补偿归属。容量与服务目标必须区分真实证据和演练，业务指标必须有口径和数据质量控制；没有这些内容的图只能算草图，不能算可实施方案。最后要求决策记录写下选择、后果、未决风险、概念验证、停止条件、回退动作和复审日期。评审结论可以是通过小范围验证、补证据后再议或否决，但不能用模糊赞成替代责任边界。架构主线可见架构设计入口。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
• 进阶追问：最常见的遗漏是什么？
• 进阶回答：失败路径、数据主责、容量前提、权限审计和撤销条件。
• 进阶追问：评审发现未知量级怎么办？
• 进阶回答：登记假设与获取方式，限制方案到可验证范围。
• 进阶追问：谁负责复审？
• 进阶回答：决策记录指定业务、技术和运行责任人及日期。

综合题 14：架构师面试中的诚实表达

14. 问题：当面试官要求讲一个没有完整数据的架构项目时，怎样展示能力又不虚构？

• 口述答案：我会明确区分三层内容：已有材料可确认的业务背景和机制、基于这些材料提出的候选设计、以及需要源码或运行记录核对的量级和结果。口述按目标、角色、不变量、约束、候选、证据、决策、容量、指标、迁移和复审展开，先说明为什么这样判断，再说明风险和替代方案。涉及库存、支付、履约、异步任务、Runner（执行器）或 IoT（物联网）时，我只引用可追溯模块作为背景，不说“已上线提升多少”；容量和成本用演练输入、公式和观测信号表达，清楚标注待验证项。被追问时，不回避未知，而是说明会查看哪些配置、监控、账单或原始事件来验证，并给出若假设不成立时的回退设计。这样的回答展示的是结构化决策、证据意识和工程边界，而不是背诵技术名词。已有项目事实可从支付与履约模块核对。 此外，在进入实施前，我会把目标、约束、已知事实、演练假设、责任人和撤销条件写入同一份评审记录，并逐项确认哪个角色负责提供输入、执行动作和验收证据。实施阶段只扩大已经验证的最小范围，持续对比正确性、延迟、资源、成本与业务完成；任何指标变化先核对口径、时间窗、版本和数据迟到，再判断是否属于系统瓶颈。发生异常时优先保护不变量和关键用户路径，采取限流、暂停、降级、回退或人工核验，并保留原始事件和处置时间线。恢复后复盘假设是否成立、监控是否缺失、自动化是否能够减少下一次人工处理，未取得直接证据的结论仍明确标为待核对。
• 进阶追问：如何避免把候选方案说成既有实现？
• 进阶回答：使用“作为面试方案我会”并明确证据等级。
• 进阶追问：面试官只要结论怎么办？
• 进阶回答：先给受约束的结论，再用一两句说明关键前提和风险。
• 进阶追问：未知数据会扣分吗？
• 进阶回答：诚实说明边界并给出取证路径，通常优于编造不可验证数字。

完成红线与本次审计