15.0 项目串讲迁移账本、事实卡与学习路线

本册是模块 15 的唯一事实入口。它不重复 Java（编程语言）、JVM（Java 虚拟机）、Redis（远程字典服务）、MySQL（关系型数据库）、MQ（消息队列）和分布式系统的机制正文，而是回答三件事：哪些项目陈述有证据，旧题库资产怎样守恒，面试时如何从业务不变量一路讲到失败恢复。所有未经源码、配置、运行记录或简历直接证明的数字，都必须标为 E3（演练设计）或 E0（待核对）。

图解读：正常路径先取事实卡，再按八段式组织项目；失败路径先承认未知态，通过账本、日志、指标、链路和对账确定事实，最后才补偿与恢复。图中的分支不是表达技巧，而是防止把建议方案、演练数字或个人推测说成生产事实的控制门。可编辑源见 project-talk-route.puml。

1. 基线、资产守恒与协作边界

1.1 模块零迁移与旧资产基线

90-项目串讲与面试话术总集.md 和 91-高频追问题库.md 在本次扩展前均不存在，因此属于零迁移新模块；92—94 三个根文件已经存在，必须原文保留，只在最终收口追加导航。2026-07-14 复核得到三个根文件的 SHA-256（安全散列算法）摘要如下。摘要只能证明执行者面对同一版本，不能证明知识内容正确。

flowchart LR
    A["旧根 92—94"] --> B["冻结摘要与资产标识"]
    B --> C["原根全文保留"]
    B --> D["新分册补失败路径和训练结构"]
    C --> E["最终追加轻量入口"]
    D --> E
    E --> F["标题、题、图、表、演绎分别守恒"]

图解读：旧根与新分册不是替换关系。旧根承担历史资产的唯一来源，新分册承担深化；最终入口只负责导航。任何摘要变化都应先重建基线，不能直接用新统计覆盖旧证据。

数据演绎：为何要分类型守恒

演练样例：旧根共有 150 个标题、1 幅 Mermaid（图表语法）图、14 张表和 2 个估算节。若只比较“新文档总字数增加”，即使漏掉唯一的旧图也可能被大量文字掩盖；分别验收后，图资产等式 1 = 1 个原根保留 + 0 个弃用 会立即暴露丢失。结论是迁移质量按资产类型验收，不能用总行数或总字数替代。

热门面试题

1. 问题：为什么项目知识库扩展前要冻结文件摘要？ 考点：并发协作、版本身份、可追溯性。 回答思路：先说明摘要保护的对象，再说明发现变化后的动作。 详细答案：摘要用于确认账本统计所依据的旧根是否仍是同一版本。多人并行写作时，标题、题目、图表或锚点可能变化；若继续沿用旧账本，容易产生遗漏、重复和失效链接。摘要变化后应保留旧基线，重新采集新摘要和分类统计，再比较差异并补充分配记录。摘要不证明内容正确，也不代替链接和语义审查。 进阶追问：只有行号变化但内容未变，是否重建全部标识？ 进阶回答：不重建稳定标识，只更新行范围；标识绑定资产身份，行号只是定位属性。

2. 问题：为什么 90 和 91 不能称为从旧根迁移而来？ 考点：事实边界、零迁移、表达准确性。 回答思路：区分新建组织层与旧资产深化层。 详细答案：基线时两个根和同名目录均不存在，它们是新的项目编排和技术追问层。可以引用 92—94 的旧主题，却不能声称旧内容已被移动到这里，否则会混淆唯一来源并破坏资产守恒。正确说法是“新建分册，链接并深化既有知识”，旧根仍保留全文。 进阶追问：引用旧题算不算复制资产？ 进阶回答：真实链接不算复制；若在新册重写长答案，就要登记它是深化资产并保持旧根可追溯。

3. 问题：摘要一致是否代表迁移完成？ 考点：完整验收、链接、语义守恒。 回答思路：说明摘要只验证源版本，完成还需目标证据。 详细答案：不代表。还要检查每个旧资产有且只有一个归属，目标文件和锚点真实存在，图形能渲染，表格没有破坏，演绎仍可复算，根文件只追加导航且旧正文未减少。摘要是起点证据，不是完成证书。 进阶追问：什么情况允许明确弃用旧资产？ 进阶回答：只有内容错误、重复或已经失效且有书面理由、替代入口和复核记录时才允许；当前计划默认零弃用。

1.2 唯一迁移账本与分类守恒式

旧资产必须以稳定标识登记，不能只靠相似标题搜索。92 使用 legacy-92-*，93 使用 legacy-93-*，94 使用 legacy-94-*；标识后缀按标题、题目、图、表、演绎分类。标题和题目可以讨论同一主题，但承担导航与训练两种职责，因此分别计数。

flowchart TD
    A["读取旧资产"] --> B{"已有稳定标识？"}
    B -- "否" --> C["按根、类型、顺序分配标识"]
    B -- "是" --> D["复核标题和摘要"]
    C --> E["登记唯一归属"]
    D --> E
    E --> F{"目标已存在？"}
    F -- "否" --> G["记录预期路径，不创建坏链接"]
    F -- "是" --> H["写真实相对链接并验证锚点"]
    G --> I["保持当前态为未迁入"]
    H --> J["更新完成态和反向索引"]

图解读：账本显式区分“规划目标”和“已经落地”。目标文件不存在时只写代码路径，不制造可点击的坏链接；文件与锚点落地后才改变完成状态。

数据演绎：守恒式如何发现重复

演练样例：假设 92 的某道“容量权衡”题同时被 92/02 和 94/06 声称为唯一迁入，右侧计数会变成 2，而左侧来源仍是 1。解决方式不是删掉一边内容，而是指定 92/02 为旧题深化归属，94/06 只放真实链接并提供不同的完整系统设计训练。这样既去重，又保留两种学习入口。

热门面试题

1. 问题：迁移账本为什么必须有稳定标识？ 考点：重命名、拆分、反向追踪。 回答思路：说明自然语言标题不稳定，标识承担身份。 详细答案：标题可能重名、改名或被拆成多个小节，用标题作为唯一键会让反向核对失效。稳定标识绑定源资产，行号、标题和目标锚点只是可更新属性。即使旧题被深化为多个失败分支，仍能从一个来源标识追到唯一归属并解释拆分关系。 进阶追问：一题拆成三题后如何计数？ 进阶回答：来源仍计一项，处理字段记录“一对多深化”，列出三个目标锚点；三个新增题属于新增资产，不伪装成三项旧资产。

2. 问题：为什么规划路径不能提前写成链接？ 考点：链接质量、当前态与完成态。 回答思路：区分未来目标和磁盘事实。 详细答案：文件或锚点不存在时，可点击链接会误导读者，也会污染自动检查信号。应先用代码文本记录预期路径；等文件存在、标题稳定且相对路径验证通过后再转成链接，并同步迁入计数。知识库应让“能点击”代表“现在可用”。 进阶追问：文件存在但锚点以后可能改名怎么办？ 进阶回答：收口时运行链接检查，改名必须同步所有引用；长期可用稳定标题或显式锚点降低漂移。

3. 问题：为什么不同类型资产不能合成一个总数验收？ 考点：质量维度、统计掩盖。 回答思路：用图或题丢失但文字增加的反例回答。 详细答案：总数会把不可替代的资产相互抵消。增加十张表不能补回一幅关键状态图，新增二十道基础题也不能替代一组容量演绎。分类守恒使每类学习功能都有独立证据，最终再做总体导航验收。 进阶追问：新增资产为什么不进入旧基线左侧？ 进阶回答：左侧描述历史事实，新增内容属于扩展量；混入左侧会让守恒式随写作不断变化，失去审计意义。

2. 项目事实卡与证据等级

2.1 E0—E3 证据合同与口述边界

项目表达先判断证据，再决定语气。E1（直接证据）来自本地源码、配置、原始记录、可复现命令或明确简历事实；E2（已有材料映射）表示知识库已有方案能映射到项目，但不能证明生产已经采用；E3（演练设计）是带假设、公式和状态变化的训练；E0（待核对）表示缺少证据，只能提出取证路径。

flowchart TD
    A["准备项目陈述"] --> B{"有源码、配置、原始记录或简历直接证据？"}
    B -- "是" --> C["标记 E1（直接证据）并引用位置"]
    B -- "否" --> D{"已有知识材料可映射？"}
    D -- "是" --> E["标记 E2（已有材料映射）并声明待核验"]
    D -- "否" --> F{"能否构造可复算假设？"}
    F -- "是" --> G["标记 E3（演练设计）"]
    F -- "否" --> H["标记 E0（待核对）并列取证路径"]

图解读：证据等级不是给答案打高低分，而是限制可陈述范围。设计再合理，如果没有生产证据，也只能作为 E2（已有材料映射）或 E3（演练设计）表达。

数据演绎：吞吐数字的正确说法

演练样例：假设导出任务每天 240 个，80% 集中在 2 小时，平均每个处理 90 秒，则到达率约为 240 × 80% ÷ 7200 = 0.0267 个/秒，平均并行在途量约为 0.0267 × 90 = 2.4 个。考虑 3 倍波动与一个执行节点故障，可以规划 10 个并发槽作为 E3（演练设计），但不能说“线上就是 10 个并发”。真实结论还需任务明细、内存水位和对象存储耗时验证。

热门面试题

1. 问题：项目经验里没有完整生产指标，面试时如何回答容量？ 考点：诚实表达、估算能力、验证路径。 回答思路：先说证据缺口，再给可复算演练和上线验证方法。 详细答案：应明确真实峰值和单实例能力待监控或压测记录核对，然后用业务量、峰值窗口、服务时间和冗余假设做 E3（演练设计）。给出单位、公式、敏感性和故障余量，并说明上线前会用压测、灰度和真实指标校准。这样既展示容量方法，也避免编造生产结果。 进阶追问：面试官坚持问真实数字怎么办？ 进阶回答：只给能被简历或记录证明的区间；无法证明时直说保密或待核对，并把重点转回口径和验证方法。

2. 问题：E2（已有材料映射）和 E3（演练设计）有什么区别？ 考点：项目映射、通用推演。 回答思路：前者有既有项目材料支撑关联，后者主要由假设构造。 详细答案：E2（已有材料映射）可以说明某方案与项目问题相符，例如知识库已把库存冻结、幂等键和补偿映射到货盘项目，但仍不能断言具体版本已上线；E3（演练设计）则是为学习构造的量级、故障或状态样例，重点是推理可复算。两者都弱于可定位的 E1（直接证据）。 进阶追问：源码里有一个类名，是否足以证明整套方案上线？ 进阶回答：不足；只能证明代码存在，还需调用链、配置启用、版本和运行记录证明实际生效。

3. 问题：为什么事实等级要写进项目话术而不是只放文档脚注？ 考点：口述风险、可信度、边界意识。 回答思路：说明面试口述最容易把建议说成事实。 详细答案：口述时读者看不到脚注，如果不主动限定，候选方案和演练数字很容易被听成真实上线结果。将“简历事实”“源码显示”“演练假设”“待现场核对”直接说出来，能让面试官区分工程经验和设计能力，也方便进一步追问证据。 进阶追问：主动说待核对会不会显得能力不足？ 进阶回答：相反，资金、库存和履约系统中能识别未知事实并给出取证路径，是资深工程判断的重要部分。

2.2 八条项目事实卡与不可越界陈述

事实卡只登记可定位信息和待核对项。它是后续 90/01—08 的共同来源，分册不得自行发明第二套项目事实。

mindmap
  root((项目能力组合))
    交易正确性
      支付资金
      库存防超卖
    长链路履约
      海外仓
      面单轨迹
      跨境物流
    异步与恢复
      异步导出
      Runner（执行器）
    高吞吐治理
      IoT（物联网）报警
      MQ（消息队列）削峰
    架构能力
      边界与不变量
      证据与复盘

图解读：项目组合不是技术名词堆叠。每条主线对应一种业务风险：资金和库存强调正确性，履约强调外部未知态，导出和调度强调隔离恢复，报警强调反馈控制，最终都收束到证据和复盘。

数据演绎：库存事实卡怎样限制夸大

简历直接支持“大促库存安全方案使用缓存热点和分布式锁”，因此这句话属于 E1（直接证据）；但“把超卖率降到零、吞吐提高十倍”没有原始记录，只能标 E0（待核对）。可以另做 E3（演练设计）：可售 100，并发请求 140，条件更新成功 100、失败 40，随后对账 期初100 - 成功扣减100 = 期末0。这个演练说明机制，不证明真实收益。

热门面试题

1. 问题：如何把多个项目组织成一条自我介绍主线？ 考点：能力抽象、证据、岗位匹配。 回答思路：用业务风险而不是公司时间线组织。 详细答案：先确定岗位需要的两三项能力，例如交易正确性、长链路履约和稳定性治理；每项只选一个最能证明能力的项目，按背景、约束、动作、失败和证据展开。其他项目作为交叉验证，不逐个报技术栈。结尾说明这些能力如何映射目标岗位，并保留可下钻的事实卡和机制链接。 进阶追问：项目很多会不会显得浅？ 进阶回答：主讲一到两个项目，其他项目只用于证明方法可迁移；被追问时再下钻状态机、数据和事故路径。

2. 问题：库存、支付和履约的不变量有什么差别？ 考点：领域边界、正确性定义。 回答思路：分别从数量、金额和业务意图回答。 详细答案：库存关注可售、冻结、已扣和实物之间的数量守恒；支付关注金额币种、支付单状态和不可变账务分录；履约关注一个业务意图不被重复提交、终态不被迟到事件倒退。三者可通过事件协作，却不能共享一个模糊的“成功状态”。 进阶追问：哪个领域应作为订单成功的权威？ 进阶回答：要先定义“支付成功、库存承诺成功、履约受理成功”三种事实，订单聚合它们但不能篡改各领域权威记录。

3. 问题：项目事实卡中为什么必须保留待核对项？ 考点：知识缺口、现场追问、工程风险。 回答思路：说明缺口本身会改变设计和表达强度。 详细答案：通道契约、真实峰值、结算规则和事故时间线会直接影响幂等、容量、重试和合规设计。若不显式记录，后续作者容易用通用经验填空并写成项目事实。待核对项同时给出下一步：查源码、配置、运行数据或业务确认，使知识库能够持续收敛。 进阶追问：待核对项长期拿不到怎么办？ 进阶回答：保持 E0（待核对），给条件化方案和不适用边界，不为了文档完整而虚构结论。

2.3 权威事实、幂等键、状态机与恢复判定

一个项目能否抗住追问，取决于是否说清四个控制点：谁保存权威事实，什么键定义“同一次业务意图”，状态允许怎样迁移，发生未知态后凭什么宣布恢复。分布式锁只能缩小并发窗口，不能替代这四个控制点。

sequenceDiagram
    participant C as 调用方
    participant S as 业务服务
    participant L as 权威账本
    participant E as 外部依赖
    participant R as 恢复任务
    C->>S: 携带稳定业务键提交命令
    S->>L: 条件写入意图和处理中状态
    S->>E: 调用外部动作
    E--xS: 响应丢失，结果未知
    S->>L: 保留未知态与查证依据
    R->>E: 按外部单号主动查询
    E-->>R: 返回权威结果
    R->>L: 按状态机幂等裁决
    R->>L: 写恢复证据与对账结果
    L-->>C: 返回已知终态或待人工裁决

图解读：超时只说明响应未知，不等于业务失败。恢复任务必须复用稳定业务键和外部单号查证，再通过条件状态迁移裁决；直接重发可能制造双扣、重复履约或重复通知。

数据演绎：迟到事件为什么不能按到达顺序覆盖

演练样例：履约状态版本 41 表示“运输中”，版本 42 表示“已签收”。消费者先收到版本 42，数据库条件更新为 version < 42，随后版本 41 迟到，条件不成立而被记录为过期事件。若采用最后到达覆盖，状态会从已签收倒退。恢复验收应检查当前版本仍为 42、迟到事件有审计记录、下游通知没有反向触发。

热门面试题

1. 问题：为什么有了分布式锁仍然要幂等键和状态机？ 考点：并发窗口、超时、重复消息、恢复。 回答思路：说明锁保护的是一段时间，不保护业务全生命周期。 详细答案：锁可能过期、失租、故障转移或在提交后响应丢失，消息和回调也可能在锁释放后重复到达。幂等键定义同一业务意图，唯一约束和条件更新保证重复请求不重复生效，状态机阻止非法倒退，账本为查证和补偿提供依据。锁只是优化竞争，不是正确性的唯一来源。 进阶追问：锁持有期间数据库事务成功，响应丢失怎么办？ 进阶回答：调用方用同一幂等键查询或重试，服务端返回已存在结果；不能生成新键再次执行。

2. 问题：分布式调用超时为什么不能直接标失败？ 考点：未知态、两将军问题、外部副作用。 回答思路：区分通信结果与业务结果。 详细答案：请求可能已经在对方成功执行，只是响应在网络中丢失。直接标失败并重试会产生重复扣款、重复下单或重复面单。系统应保存处理中或未知态，通过外部单号主动查证、等待幂等回调或进入人工裁决，再按状态机落终态。 进阶追问：未知态可以无限保留吗？ 进阶回答：不可以，要有自动查证间隔、最长停留时间、风险分级和人工升级；资金与库存通常优先冻结后续不可逆动作。

3. 问题：如何证明一个故障已经恢复？ 考点：技术恢复、业务恢复、数据正确性。 回答思路：同时检查资源、流量、积压和业务不变量。 详细答案：进程存活和错误率下降只代表技术信号改善。还要确认成功完成率高于到达率、积压斜率持续为负、未知态年龄下降、补偿任务收敛，并按业务主键抽样核对库存、资金、履约或报警事实。恢复后分批放量，观察一个完整业务窗口；出现反弹立即回到前一保护档。 进阶追问：队列深度下降能否单独证明恢复？ 进阶回答：不能，消息可能被快速拉取后失败或丢弃；必须看业务成功完成、重试、死信和对账结果。

3. 项目串讲合同与失败追问路线

3.1 八段式项目话术与三层下钻

项目串讲固定采用“背景、约束、目标、方案、权衡、失败、结果证据、复盘”。八段不是流水账：背景只说明业务冲突，约束限定决策空间，目标写可验证不变量，方案用状态和数据展开，权衡说明为什么不用其他选项，失败展示系统边界，结果只使用证据允许的语气，复盘给出演进触发器。

flowchart TD
    A["背景：业务冲突"] --> B["约束：量级、团队、时间、外部依赖"]
    B --> C["目标：业务不变量和验收信号"]
    C --> D["方案：边界、状态、数据、关键链路"]
    D --> E["权衡：候选、失败成本、不适用边界"]
    E --> F["失败：超时、重复、乱序、重启、积压"]
    F --> G["结果证据：E1/E2/E3/E0"]
    G --> H["复盘：撤销条件和下一阶段演进"]
    H --> I{"面试官下钻"}
    I --> J["机制：唯一正文"]
    I --> K["事故：证据链与恢复"]
    I --> L["设计：容量、成本与治理"]

图解读：回答从业务问题出发，以证据结束。技术组件只出现在方案和权衡中；如果一开口就是 Redis（远程字典服务）、MQ（消息队列）和微服务，通常说明还没有建立业务问题与设计选择之间的因果链。

数据演绎：三分钟回答如何分配时间

演练样例：180 秒口述中，背景与职责 20 秒、约束与目标 25 秒、方案主链路 55 秒、失败与恢复 45 秒、权衡 20 秒、证据和复盘 15 秒。若方案部分超过 100 秒而没有失败路径，面试官得到的是架构导览，不是高级工程能力证明。时间分配只是 E3（演练设计），实际按岗位和追问调整。

热门面试题

1. 问题：项目介绍为什么不能按开发时间线讲？ 考点：信息密度、决策能力、面试结构。 回答思路：区分工作日志和问题解决叙事。 详细答案：时间线容易变成“先建表、再写接口、然后联调”，面试官听不到业务冲突、设计约束和个人判断。八段式围绕一个不变量组织，先讲为什么难，再讲如何决策、怎样处理失败和如何验证，时间线只在事故因果或迁移阶段中使用。 进阶追问：哪些时间信息必须保留？ 进阶回答：状态迁移、故障时间线、灰度阶段和恢复窗口必须保留，因为顺序直接影响因果和风险。

2. 问题：如何避免项目话术像背模板？ 考点：具体事实、状态、反例、证据。 回答思路：每个抽象原则后立即给项目对象和失败样例。 详细答案：不要只说“做了幂等和补偿”，应给幂等键组成、权威表、状态条件、超时后查证路径和一组数据变化；不要只说“提升稳定性”，应给错误率、积压、未知态或对账的验证口径，并标证据等级。模板只控制顺序，内容必须来自事实卡。 进阶追问：没有真实事故可以讲失败吗？ 进阶回答：可以明确标为故障注入或 E3（演练设计），讲触发、信号、止血、恢复和验收，不伪装成生产事故。

3. 问题：如何说明自己在团队中的真实贡献？ 考点：职责边界、协作、结果归属。 回答思路：区分参与、负责、主导和团队共同结果。 详细答案：用可定位产物和决策说明贡献，例如负责某状态机、适配层、库存模型或排障流程；主导则需说明如何组织评审、协调上下游和推动验收。团队结果不能全部归到个人，个人也不应只说“参与”。没有证据的收益保持谨慎。 进阶追问：设计是团队讨论的，个人怎么讲？ 进阶回答：说明自己提出或验证了哪些假设、承担哪部分落地与风险，以及团队最终为何采纳，不把共同决策独占。

3.2 失败场景答题合同与跨模块回链

失败追问统一采用“现象、假设、证据、止血、查证、修复、恢复验收、复盘”。现象不能直接等同根因；止血不能破坏业务不变量；修复不能只改代码，还要处理历史脏数据、在途请求和重复消息；恢复验收要证明用户与业务事实都正常。

sequenceDiagram
    participant M as 监控与业务反馈
    participant O as 值班人员
    participant S as 服务与账本
    participant D as 下游依赖
    participant B as 业务验收方
    M->>O: 报告成功率下降和未知态增长
    O->>S: 按业务键抽样，建立影响范围
    O->>O: 提出假设并寻找反证
    O->>S: 限流、隔离或冻结不可逆动作
    O->>D: 主动查证外部结果
    D-->>O: 返回终态与水位
    O->>S: 幂等补偿并处理历史在途
    O->>B: 提交抽样、对账和恢复证据
    B-->>O: 验收业务不变量
    O->>M: 分批恢复并观察完整窗口

图解读：排障不是看到告警就修改代码。先用业务样本限定影响，再止血和查证，修复后还要处理历史状态并由业务验收；最后通过分批恢复防止二次冲击。

数据演绎：积压恢复时间

演练样例：MQ（消息队列）积压 180000 条，新增到达率 800 条/秒，真实成功完成率 1400 条/秒，净排空速度为 1400 - 800 = 600 条/秒，理论最短恢复时间 180000 ÷ 600 = 300 秒。若完成率降到 750，积压仍以每秒 50 条增长，增加拉取线程没有意义。验收还要检查失败、重试、死信和业务对账，不能只看队列深度。

热门面试题

1. 问题：线上排障为什么要先提出假设再找证据？ 考点：因果推断、效率、误操作风险。 回答思路：说明指标异常可能有多个原因，动作会改变现场。 详细答案：同一个响应变慢可能来自数据库锁、外部超时、垃圾回收、连接池或流量结构变化。先写假设和可证伪信号，可以按影响与验证成本排序，避免无目的翻日志。执行止血前还要保留关键样本和版本，因为重启、扩容或清队列会改变现场。 进阶追问：紧急事故来不及完整分析怎么办？ 进阶回答：先执行预先演练且可回滚的保护动作，同时保留证据；高风险不可逆操作仍需双人确认或门禁。

2. 问题：为什么修复代码后事故还没有结束？ 考点：历史数据、在途任务、恢复闭环。 回答思路：区分新请求正确和存量状态正确。 详细答案：故障期间可能积累未知支付、重复库存冻结、迟到轨迹、失败分片和旧租约任务。新版本只阻止继续产生问题，存量仍需按业务键盘点、查证、幂等补偿和对账；恢复后还要验证积压、差异和人工队列收敛。 进阶追问：补偿脚本怎样避免二次事故？ 进阶回答：先只读预览，按小批次和稳定幂等键执行，设置速率、停止条件、审计和回滚，并逐批对账。

3. 问题：面试中如何讲一个自己没有亲历的事故场景？ 考点：演练边界、故障设计、诚实性。 回答思路：明确标为演练，再给完整控制链。 详细答案：应说“这是基于该架构的故障注入设计”，给出触发方式、预期信号、业务影响、止血动作、恢复步骤和验收条件。若引用已有材料，标为 E2（已有材料映射）；数字标 E3（演练设计）。不要使用“我们线上发生过”这类无证据语气。 进阶追问：演练能证明生产一定安全吗？ 进阶回答：不能，只能提高对特定假设的信心；生产依赖、流量和组织响应仍需持续观测与复演。

4. 学习路线、验收与续接合同

4.1 分册依赖、阶段验收与新对话恢复

模块 90 讲项目主线，91 讲按技术栈组织的失败追问，92 讲架构权衡，93 讲三、五、十分钟口述，94 讲完整系统设计。学习时可从项目入口开始，但机制问题必须回链 09—54 的唯一正文；不能在五套题库里复制五遍同一原理。

flowchart LR
    A["90/00 事实卡"] --> B["90/01—08 项目主线"]
    B --> C["91/00—14 技术失败追问"]
    C --> D["92/00—04 架构权衡"]
    D --> E["93/00—04 时间盒口述"]
    E --> F["94/00—06 系统设计"]
    F --> G["错题回写到唯一机制正文"]
    G --> B

图解读：学习路线是反馈环，不是一次性读完。系统设计暴露的机制缺口回到唯一正文补齐，再重新练项目表达；题库只保留问题和上下文，机制解释不复制扩散。

数据演绎：两周训练安排

演练样例：每天 90 分钟，前 20 分钟复习事实卡，30 分钟口述两题，20 分钟画一幅状态或时序图，20 分钟复盘错题。14 天共 90 × 14 = 1260 分钟，可完成 28 次长口述、14 幅图和 14 次错题回链。若某题连续两次无法解释幂等键、权威事实或恢复判定，就回到机制正文，不继续背答案。

新对话续接时先读取项目根 AGENTS.md、00-项目说明-续接必读.md、03-成稿进度看板.md、04-英文术语标注规范.md、08-精通级扩展执行看板.md、本账本和当前模块计划；运行 git status --short，尊重并发改动，再从最小未完成编号继续。

热门面试题

1. 问题：为什么题库不应该复制机制长文？ 考点：单一事实来源、维护成本、知识一致性。 回答思路：说明同一原理多份副本会漂移。 详细答案：分布式锁、垃圾回收、事务日志等机制会持续修订；若在项目、追问和系统设计册各复制一份，术语、边界和图示很快不一致。题库应保留问题特有的项目上下文和回答组织，并用真实链接下钻唯一正文。这样修正一次即可影响所有入口。 进阶追问：只有链接会不会影响离线复习？ 进阶回答：保留足够的口述结论和项目状态即可，底层细节通过同一仓库相对链接访问；不以便利为由复制整章。

2. 问题：如何判断自己是真的理解而不是记住答案？ 考点：迁移能力、反例、数据演绎。 回答思路：用改变条件后的推导检验。 详细答案：随机改变流量、失败顺序、数据版本或一致性要求，仍能从不变量推导设计；能画出状态和时序，计算积压或容量，指出方案不适用边界，并在没有标准答案时列证据与验证路径，才算建立知识模型。只会复述固定段落通常无法处理反例。 进阶追问：最有效的自测方式是什么？ 进阶回答：让他人随机注入一个失败条件，限时画图并口述，随后用文档逐项核对缺失的事实、状态和证据。

3. 问题：新对话怎样避免丢失当前进度和约束？ 考点：持久化上下文、进度看板、协作安全。 回答思路：把恢复信息写入文件而非依赖聊天记忆。 详细答案：固定入口记录写作规则、术语、模块状态、计划和事实边界；新执行者先读取这些文件与工作区状态，再从看板的最小未完成项继续。新增或明显扩展模块后同步看板，提交时只包含本任务路径，遇到他人改动不回滚。这样上下文由版本化文档承载。 进阶追问：看板与磁盘文件不一致时信哪个？ 进阶回答：以磁盘、审计和提交记录为事实，先修正看板再继续，不能用看板的“已完成”掩盖缺失文件。

4.2 旧根标题资产逐项索引

以下 150 行按旧根与原始顺序分配稳定标识。唯一归属均为原根保留；后续分册只能增加不同训练结构或真实链接，不删除、移动或把旧标题伪装成新资产。

非标题资产稳定范围

5. 综合题库

1. 问题：你如何保证项目经历真实可信，又能展示架构设计深度？

   • 考点：证据等级、事实边界、设计深度。
   • 回答思路：先分证据，再按项目不变量、失败路径和验证方法展开。
   • 详细答案：可信项目表达必须把可定位事实、已有方案、演练假设和待核对项分别陈述。
   • 进阶追问：设计合理但没有生产记录时应怎样表达？
   • 进阶回答：标为候选方案或演练，给出验证路径，不描述为已经上线的结果。
   • 口述答案：我会把“事实”和“设计能力”分层表达。先建立事实卡：简历明确写到的职责、本地源码能定位的类和配置、可复现的命令或运行记录属于 E1（直接证据）；已有知识材料能够映射到项目，但缺少启用与运行证据的内容属于 E2（已有材料映射）；为了说明容量、失败或状态而构造的数据属于 E3（演练设计）；完全缺少依据的规则保留为 E0（待核对）。项目介绍仍按背景、约束、目标、方案、权衡、失败、结果证据和复盘展开，但每个数字和效果都受证据等级限制。例如我可以依据简历说参与 WMS（仓储管理系统）库存安全、热点缓存和分布式锁，也可以用“可售 100、并发 140、条件更新成功 100”的样例演绎不超卖；但没有压测和事故记录，就不会说吞吐提升十倍或超卖率降为零。对于支付和履约，我会主动列出需要继续核验的通道版本、结算规则、真实峰值和恢复时间，并说明如何从源码、配置、账单和监控取证。这样回答既不会把候选方案伪装成上线事实，又能展示我会定义不变量、画状态机、设计幂等、处理未知态和验收恢复。可信度不是少讲技术，而是每个技术结论都能说明证据在哪里、适用边界是什么、证据不足时怎样验证。 我还会准备一条反例：当证据无法区分“代码存在”和“功能已启用”时，宁可降低陈述等级，也不从类名推导生产效果；这能防止面试追问配置、版本和运行数据时自相矛盾。
   • 追问1：源码里存在实现类就属于生产事实吗？
   • 直答1：只证明代码存在；还需配置启用、调用链、部署版本和运行记录证明实际生效。
   • 追问2：演练数字有什么价值？
   • 直答2：它检验公式、状态和失败推理是否完整，但必须明确假设，不能替代生产数据。
   • 追问3：怎样避免事实卡过期？
   • 直答3：记录来源、摘要和复核日期；代码、配置或简历变化后重新核对并更新等级。
   • 对应知识节

2. 问题：请用事实卡方法讲清 WMS（仓储管理系统）库存防超卖项目。

   • 考点：库存不变量、条件更新、幂等补偿。
   • 回答思路：先限定简历事实，再讲权威账本、并发路径和恢复验收。
   • 详细答案：缓存与锁负责削峰和减少竞争，数据库条件与库存账本承担正确性底线。
   • 进阶追问：缓存和数据库出现差异时怎样恢复？
   • 进阶回答：隔离缓存，以数据库流水对账并重建；未裁决请求保持未知态。
   • 口述答案：我会先说明有证据的边界：简历写明参与库存模型、入库在库出库公共能力，并在大促版本中使用热点缓存和分布式锁保护库存，因此这些可作为 E1（直接证据）；真实峰值、锁客户端版本和具体收益仍待记录核对。业务目标不是“用了 Redis（远程字典服务）”，而是同一仓库与 SKU（库存单位）的可售量不能被并发请求扣成负数，重复请求不能重复冻结，失败后可售、冻结、已扣和实物能够对账。我会让数据库库存账本和条件更新承担最终底线，稳定业务键由租户、仓库、SKU（库存单位）、订单行和动作组成；缓存负责热点读取或预扣削峰，分布式锁只减少竞争，不替代唯一约束、状态机和补偿。正常链路先创建库存意图，再条件冻结、提交订单并发布事件；订单失败或支付超时则用同一业务键幂等释放。若缓存预扣成功而数据库提交结果未知，不能立刻换键重扣，要查询库存流水和事务结果，把请求保持在未知态，超时升级人工。演练时可设期初可售 100、140 个并发请求，每次扣 1，数据库条件为 available >= 1，最终最多 100 次成功；再注入重复消息、锁过期和释放回调丢失，验证账本与对账能收敛。结果表述只使用可证明证据，复盘则说明热点进一步升高时如何按仓库与 SKU（库存单位）隔离、限流和迁移，而不是把缓存当永久真值。 对账时我会按业务键抽取成功、失败、释放和未知样本，核对汇总库存能否由流水重算；只有历史差异清零、补偿队列收敛且新请求条件更新稳定，才允许撤销限流和扩大流量。
   • 追问1：为什么不能只用分布式锁保证不超卖？
   • 直答1：锁会过期、失租和故障转移，正确性还需数据库条件、业务幂等和账本兜底。
   • 追问2：缓存与数据库不一致时听谁的？
   • 直答2：权威库存账本和数据库条件更新决定业务事实，缓存隔离后重建并对账。
   • 追问3：释放库存失败怎么处理？
   • 直答3：以原冻结键幂等重试，超限进入补偿清单；不能直接增加汇总库存而跳过流水。
   • 对应知识节

3. 问题：请用事实等级和不变量说明支付资金一致性项目。

   • 考点：支付状态机、账务分录、回调查单与对账。
   • 回答思路：区分订单、支付、渠道和账务，再讲未知态和三方对账。
   • 详细答案：资金正确性依赖稳定业务键、单调状态、不可变分录和可审计差异处理。
   • 进阶追问：渠道结果和本地状态冲突时以谁为准？
   • 进阶回答：先保留双方原始事实，按渠道查单、支付状态机和账务分录共同裁决。
   • 口述答案：支付项目先区分业务订单、支付单、渠道事件和账务分录。简历可以直接证明接入多支付渠道以及下单、回调、退款、重试、账单和结算等职责；某个通道的真实版本、结算周期、差错金额和线上成功率若没有配置与账单证据，就保持 E0（待核对）或 E3（演练设计）。核心不变量是支付金额与币种在一次支付意图内不可漂移，同一商户请求和同一渠道事件只生效一次，支付成功不能被普通失败通知倒退，所有余额或结算变化都由不可变分录解释。发起支付时先以商户请求号创建支付单，再调用渠道；回调先验证签名、时间窗和重放标识，原始事件幂等入库后按状态机推进。调用超时只进入未知态，主动查单或等待回调裁决，绝不能把通信超时直接当业务失败并生成新支付。余额扣减采用条件更新与账务唯一键，退款有独立退款单和累计上限，对账比较本地支付、渠道账单和内部账务三方明细，差异先分类再用纠正分录处理，不修改历史流水。演练可构造支付 100 元、重复回调 3 次、渠道成功但本地响应丢失：唯一事件只推进一次，分录借贷守恒，查单后订单最终进入已支付。面试结尾我会说明失败重试、人工调账、密钥轮换和审计权限的边界，并把没有生产证据的效果明确留给压测与对账记录验证。 资金恢复的最后一步不是把订单改成成功，而是抽样核对渠道金额、支付单、账务分录、退款累计值和业务订单都指向同一结论，并保留裁决依据与操作者审计。
   • 追问1：为什么支付回调成功还需要主动查单？
   • 直答1：回调可能丢失、延迟或乱序；未知态与对账差异需要主动查询渠道权威结果。
   • 追问2：能否直接修改错误账务流水？
   • 直答2：不能，应追加可追溯纠正分录，保留原始事实和审批依据。
   • 追问3：退款回调重复怎么办？
   • 直答3：按退款请求号和渠道事件标识双层幂等，并用累计退款金额条件限制上限。
   • 对应知识节

4. 问题：海外仓履约和面单轨迹链路最难的设计点是什么？

   • 考点：外部未知态、适配层、状态单调与回放。
   • 回答思路：围绕一个业务意图只履约一次，展开超时查证和乱序保护。
   • 详细答案：外部渠道不可靠时，系统必须保存请求证据、稳定业务键和内部权威状态。
   • 进阶追问：下游不支持幂等键怎么办？
   • 进阶回答：本地登记意图和请求摘要，优先查询外部单号，必要时人工裁决而非盲重试。
   • 口述答案：最难的不是调用多少家下游，而是外部结果长期处于未知、重复和乱序时，仍保证一个业务意图只履约一次且状态可解释。简历能证明参与多仓储渠道适配、产品与库存同步、订单创建取消查询、面单、轨迹、补发和补偿任务；各渠道真实超时、字段和服务等级要从接口契约与运行记录核验。设计上将业务订单、履约单、下游单、包裹、面单版本和轨迹事件分开，内部状态由自己的状态机控制，渠道字段通过防腐层翻译。创建下游订单使用稳定业务键并保存请求摘要；网络超时时进入待查证，不马上重建新单，通过查询接口、回调或人工工单确定外部单号。面单文件保存校验值和版本，重复获取不重复生成业务副作用；轨迹同时保存发生时间、接收时间、来源和版本，已签收终态不能被迟到的运输中事件倒退。渠道限流使用独立线程池、并发舱壁、退避与重试预算，不能让一个仓拖垮所有线路。恢复时从最后可信水位回放，按业务键核对在途、重复下游单、缺面单和轨迹断点。演练可让版本 42 的签收先到、版本 41 后到，条件更新拒绝倒退但保留旧事件审计。项目结果只按证据表述，设计能力则通过未知态、幂等、状态单调和恢复清单完整展示。 如果需要切换渠道，我会先冻结新分配，盘点旧渠道在途单和不可撤销动作，再为新订单切流；历史单仍按原渠道查证，避免迁移时把同一订单同时提交给两家仓。
   • 追问1：创建下游订单超时后为什么不能立即重试？
   • 直答1：对方可能已创建成功；新请求可能产生重复履约，应先用原业务键或外部查询查证。
   • 追问2：轨迹按发生时间排序就够了吗？
   • 直答2：不够，还要有状态优先级、版本和终态保护，并保留接收时间用于排障。
   • 追问3：渠道长期不可用如何止血？
   • 直答3：隔离该渠道、暂停新分配、保留可查询状态，按业务规则切换或人工处理在途单。
   • 对应知识节

5. 问题：如何讲清异步导出既解决 OOM（内存溢出）又保证交付正确？

   • 考点：快照、分片、资源隔离、文件校验与授权。
   • 回答思路：从入口快照讲到分片执行、合并交付、取消竞争和恢复验收。
   • 详细答案：异步化只改变等待方式，正确性仍需任务账本、检查点和文件级校验。
   • 进阶追问：任务显示成功但用户下载失败怎样定位？
   • 进阶回答：分别检查文件对象、摘要、授权、通知和下载审计，不能只看执行状态。
   • 口述答案：我不会把异步导出只描述成“放到 MQ（消息队列）”。简历能证明大于两万条的数据导出采用异步与邮件交付，也能证明跨境项目存在批量导入导出；真实分片大小、对象存储和峰值内存仍需代码与监控核对。设计目标有三层：在线查询不被大任务拖垮，同一查询快照可重放，最终文件与权限可审计。入口先鉴权并固化查询条件、租户、字段权限和快照版本，使用稳定请求键防止重复提交；任务状态从待运行、执行中、合并中、待交付到成功、失败或取消。执行器按主键游标分片读取，边读边写临时文件，限制每个任务和全局并发，不把全部结果放入堆。每个分片记录行数、校验值和检查点，合并后再核对总行数与文件摘要，上传对象存储成功且授权建立后才进入可交付。取消与完成竞争使用版本条件，迟到分片不能把已取消任务改回成功。进程重启从检查点恢复，重复分片由任务与分片唯一键去重；邮件只是通知，权威交付状态仍在任务账本。演练可假设每行 2KB（千字节）、两万行原始数据约 40MB（兆字节），若对象膨胀五倍并全量加载就可能占 200MB（兆字节）以上，而 1000 行分片将工作集压到约 10MB（兆字节）级。最终验收同时看堆水位、在线响应、分片齐全、文件校验和权限过期，不能只看任务显示成功。 对失败任务还要区分查询失败、分片写入失败、合并失败、对象上传未知和通知失败，分别选择重试点；从头重跑既浪费资源，也可能让用户拿到两个口径不同的文件。
   • 追问1：为什么分页查询仍可能漏数或重复？
   • 直答1：导出期间数据变化会改变偏移，需固定快照或按稳定主键游标并记录边界。
   • 追问2：文件上传成功但回执丢失怎么办？
   • 直答2：保持未知态，按对象键查询元数据和校验值，确认后幂等推进，不重复生成文件。
   • 追问3：如何隔离大客户导出？
   • 直答3：按租户配额、任务大小分级、独立队列和并发舱壁，并给在线交易保留资源。
   • 对应知识节

6. 问题：Runner（执行器）任务执行一半重启，如何保证恢复正确？

   • 考点：租约、栅栏、检查点、幂等副作用。
   • 回答思路：区分执行权和业务效果，按世代拒绝旧持有者提交。
   • 详细答案：租约控制谁能执行，栅栏控制谁能提交，业务幂等控制外部效果是否重复。
   • 进阶追问：没有栅栏令牌时最危险的场景是什么？
   • 进阶回答：旧执行者暂停后恢复，可能用过期结果覆盖新执行者已完成的状态。
   • 口述答案：先承认事实边界：简历能证明使用常驻任务承载产品、入库、订单、计费、轨迹和回调重试，但是否已经采用租约与 Fencing Token（栅栏令牌）需要从源码和数据库字段核对；因此我会把下面的租约方案标为 E2（已有材料映射）或 E3（演练设计）。任务先持久化状态和业务幂等键，调度者获取带到期时间的租约，每次续租或重新领取递增世代号；执行者提交结果时必须携带当前世代，数据库条件拒绝旧持有者的迟到写入。长任务按业务边界保存检查点，外部副作用仍通过稳定请求号幂等，不能只依赖任务状态。进程重启后，新实例扫描过期租约，先查外部动作是否已经完成，再从最后可信检查点继续；若旧实例网络恢复，它的世代已经过期，无法覆盖新结果。错误按可重试、不可重试和未知结果分类，重试采用退避、上限和随机抖动，避免同时恢复形成风暴。演练可设租约 30 秒、每 10 秒续租，旧执行者暂停 40 秒后恢复，新执行者已取得世代 8；旧世代 7 的提交条件失败，业务幂等键也阻止重复扣费。恢复验收不仅看任务成功，还要看过期租约写入为零、积压净下降、外部单据无重复、失败与人工队列收敛。若源码尚未具备这些能力，我会明确说明当前风险和分阶段改造，而不会把建议方案说成已经上线。 容量上还要限制同一任务类型的并发和重试总量，为支付回调、轨迹和普通同步设置不同优先级；否则恢复阶段所有过期任务同时抢占，会把短暂重启放大成共享依赖雪崩。
   • 追问1：有租约为什么还需要业务幂等？
   • 直答1：租约解决执行权竞争，无法撤销已发生的外部副作用；业务幂等保护最终效果。
   • 追问2：检查点越频繁越好吗？
   • 直答2：不是，频繁写入增加成本；应按可重做成本、外部副作用和恢复目标权衡。
   • 追问3：恢复时为什么先查证再重试？
   • 直答3：旧执行可能已成功但回执丢失，盲目重试会重复扣费、下单或通知。
   • 对应知识节

7. 问题：IoT（物联网）报警风暴为什么不是简单限流问题？

   • 考点：报警优先级、窗口聚合、背压与反馈控制。
   • 回答思路：先保护高危事实，再压缩低级重复，并设计分级恢复。
   • 详细答案：报警治理必须同时满足不漏高危、不过载、可回放和可解释。
   • 进阶追问：聚合规则错误时如何回滚？
   • 进阶回答：保留规则版本和原始事件，从旧版本恢复并按水位回放受影响窗口。
   • 口述答案：简单限流只减少请求量，却可能把最重要的高危报警一起丢掉。简历能证明遥测通过 MQTT（消息队列遥测传输协议）与 MQ（消息队列）上报，报警经过平台展示并要求消息可靠；真实峰值、窗口和通知服务等级仍需监控与规则配置核对。设计目标是高危报警不漏达、重复噪声不无限放大、原始事实可追溯且系统能在风暴后恢复。接入层先验证设备和事件身份，保存原始事件或可回放摘要；处理层按设备、报警码、规则版本和时间窗口聚合，维护首次、最近、次数和严重度。低级重复报警可以抑制或摘要通知，高危报警走独立配额和旁路，不能被普通流量占满。MQ（消息队列）承担削峰，但消费者还要有背压、分级队列和重试预算；通知通道使用稳定事件键和回执状态，未知结果先查证。演练可设每秒一万条，其中 90% 是同类重复低级报警，窗口聚合后只生成少量摘要，同时保留每秒 100 条高危通道容量；若聚合服务失败，原始事件仍可按规则版本回放。恢复时不能一次释放全部积压，要先恢复高危和状态转换事件，再处理摘要与历史；验收检查高危覆盖率、重复压缩率、通知成功、人工确认时间和错误聚合样本。这样回答把流量控制、业务优先级、状态事实和反馈控制连成闭环，而不是只说加消费者。 我还会为降噪率设置反向护栏：压缩比例上升时，高危触达、状态转换完整性和人工抽样不能下降；若护栏异常，自动停止新规则并切回上一版本，避免“系统更安静”掩盖真实漏报。
   • 追问1：聚合会不会掩盖真实故障扩大？
   • 直答1：保留首次、最近、次数、严重度变化和原始引用；高危升级绕过普通抑制。
   • 追问2：积压恢复为什么要分级？
   • 直答2：历史低级噪声若先占满资源，会延迟当前高危报警并形成二次风暴。
   • 追问3：如何验证降噪规则安全？
   • 直答3：用历史回放和故障注入比较原始事件、高危覆盖、误抑制和通知结果，灰度发布规则版本。
   • 对应知识节

8. 问题：跨境物流项目怎样从业务链路讲到成本和架构权衡？

   • 考点：领域边界、单位经济、外部渠道和演进。
   • 回答思路：先讲业务链与历史事实，再比较渠道总成本和可逆演进。
   • 详细答案：订单、支付、履约和结算各有权威事实，渠道选择应比较完整失败成本。
   • 进阶追问：成本优化为什么可能损害稳定性？
   • 进阶回答：过度缩容或选择低价低稳定渠道会增加失败、赔付、重试和人工处理成本。
   • 口述答案：我会先画出报价、下单、库存或仓配、支付、渠道履约、面单、轨迹、异常件、退款和结算的业务链，而不是从框架开始。简历可以证明参与这些核心链路和多角色后台，也能证明多支付与多仓储渠道接入；线路真实量级、毛利、渠道服务等级和账单差异必须从运营与财务材料核验。领域边界上，报价保留版本与有效期，订单冻结当时的价格、币种和地址快照；支付单只表达资金意图，履约单表达仓配承诺，结算根据不可变账单与渠道费用形成，任何后续报价调整不能改写历史订单。外部渠道通过适配层统一能力与错误分类，但不强行抹平差异；创建超时进入未知态，按业务键查证，面单和轨迹异步处理并保持状态单调。成本权衡要把调用费、标签与仓租、网络、存储、重试和人工异常处理纳入单位经济，而不只看服务器。演练可比较两个渠道：甲单价低但失败率与人工处理高，乙单价高但稳定；用总成本 渠道费 + 重试资源 + 赔付预期 + 人工时长 评估，而不是只按面单价格选择。架构演进遵循可逆性：早期单体内保持清晰业务模块，流量和团队边界稳定后再拆服务；先建设幂等、状态机、账本和观测，再引入更多异步与多区域。失败时优先保护资金、库存和履约不可逆动作，查询与报表可降级。结尾用事实等级说明哪些是源码事实、哪些是候选设计和待核对经营数据。 方案评审还要写退出条件：当渠道错误率、账单差异、人工时长或单位总成本连续越过门禁时，暂停新增流量；迁移期间按订单归属保持单一渠道，避免为了降成本造成双履约。
   • 追问1：为什么最便宜的渠道不一定总成本最低？
   • 直答1：失败、重试、赔付、人工处理和履约时效都会进入总成本，单价只是一部分。
   • 追问2：何时应拆分支付或履约服务？
   • 直答2：边界、团队、独立扩容和变更频率形成稳定收益，且治理能力能承担分布式复杂度时。
   • 追问3：如何避免适配层变成巨型条件分支？
   • 直答3：定义能力合同与错误语义，按渠道实现适配器，差异通过能力声明和策略组合表达。
   • 对应知识节

9. 问题：请给出一次通用线上事故的完整回答框架。

   • 考点：证据链、止血、存量修复、恢复验收。
   • 回答思路：从业务影响出发，按假设与反证推进，最后验证不变量。
   • 详细答案：事故处理既要恢复服务，也要裁决历史未知态并防止二次冲击。
   • 进阶追问：止血动作和根因修复有什么区别？
   • 进阶回答：止血限制影响且必须可回滚，根因修复消除触发机制并处理历史状态。
   • 口述答案：我会按现象、假设、证据、止血、查证、修复、恢复验收和复盘回答。先用业务成功率、影响租户、订单或任务样本限定范围，不把 CPU（中央处理器）高、队列深或错误码直接当根因；同步记录版本、配置、流量结构和起始时间。根据链路提出可证伪假设，例如数据库热点锁导致完成率下降、外部通道超时耗尽连接、消费者只拉取但业务提交失败。止血选择预先演练且可回滚的动作：限制非关键入口、隔离异常渠道、暂停大导出、冻结资金或库存的不可逆步骤，并保留日志、追踪、线程栈、账本和消息样本。随后按稳定业务键查证未知态，区分未执行、已成功回执丢失和明确失败；修复除了新代码，还包括在途请求、历史脏数据、迟到消息和人工清单。恢复时分批放量，要求业务成功完成率高于到达率、积压斜率持续为负、未知态年龄下降、对账差异收敛，并抽样验证库存、资金、履约或报警不变量。观察完整业务窗口后再解除保护。复盘以事实时间线为基础，分析为什么监控、门禁或演练没有更早发现，行动项写负责人、完成证据和复核日期。若这个事故只是训练，我会明确标为 E3（演练设计）；如果是项目真实事故，则只陈述有运行记录支持的影响和结果，不把团队成果全部归于个人。 在对外沟通上还要固定更新节奏，分别说明已知事实、未知范围、当前保护动作和下一次更新时间；这能避免技术团队忙于排障时，业务方依据过期信息继续扩大风险操作。
   • 追问1：事故中先重启服务是否合理？
   • 直答1：只有在手册已验证且先保留关键证据时；重启可能改变现场并触发重复任务。
   • 追问2：怎样判断积压正在恢复？
   • 直答2：看成功完成率减到达率的净值、队列年龄、失败重试和业务对账，不只看拉取速度。
   • 追问3：复盘如何避免变成追责会？
   • 直答3：先固定事实和系统控制缺口，改进行动与人事责任采用不同流程。
   • 对应知识节

10. 问题：请组织一段面向高级 Java（编程语言）岗位的项目组合自我介绍。

• 考点：能力主线、代表项目、个人职责和岗位匹配。
• 回答思路：用三条能力线串联项目，保留可下钻的问题和证据。
• 详细答案：自我介绍应证明复杂业务建模、分布式恢复、线上稳定性和协作落地能力。
• 进阶追问：如何根据岗位调整项目顺序？
• 进阶回答：交易岗位先支付，供应链岗位先库存履约，平台岗位先异步调度与稳定性。
• 口述答案：我的项目经验可以用三条主线概括。第一条是交易与库存正确性：在 WMS（仓储管理系统）和跨境业务中参与库存模型、热点库存保护、冻结解冻、支付回调、退款、账单和结算，我关注的不只是高并发，而是可售与冻结数量守恒、金额币种不漂移、重复请求只生效一次以及异常后可对账。第二条是外部履约和异步恢复：多海外仓、支付渠道、面单轨迹和常驻任务都不能假设下游稳定，因此我会用清晰领域边界、稳定业务键、状态机、未知态查证、消息幂等和补偿任务，把超时、重复、乱序和重启变成可管理状态。第三条是稳定性与全栈交付：做过大数据量异步导出、Runner（执行器）任务、IoT（物联网）报警消息链路以及运营后台和客户端协作，会从线程、数据库、缓存、队列一直看到业务成功率、积压、对账和人工处置。介绍具体项目时，我会区分简历与源码能直接证明的 E1（直接证据）、已有方案映射、演练数据和待核对项，不把建议设计说成上线事实。我的工作方式通常是先定义业务不变量和权威事实，再设计正常与失败链路，给出容量、观测、灰度和回退，最后通过数据抽样和对账验收。希望应聘的岗位能让我继续承担 Java（编程语言）核心系统设计、复杂业务建模、线上排障和跨团队落地；被追问时，我可以从库存、支付、履约、异步任务或报警任一主线下钻到状态、数据和恢复细节。
• 追问1：最能代表你的项目是哪一个？
• 直答1：按岗位选择；交易岗位主讲支付资金，供应链岗位主讲 WMS（仓储管理系统）与履约，平台岗位主讲异步和稳定性。
• 追问2：为什么介绍中不罗列全部技术栈？
• 直答2：技术栈只有和业务问题、设计取舍、失败处理及证据绑定时才体现能力。
• 追问3：个人贡献如何证明？
• 直答3：定位到负责的模型、接口、适配层、任务或排障动作，并区分个人职责与团队结果。 介绍结束后我会主动给出一个可选择的下钻菜单，例如库存并发、支付未知态、履约乱序、导出内存或报警风暴，让面试官决定深挖方向；每个方向都能回到具体状态、数据与恢复证据。
• 对应知识节

6. 复习清单

• 能说出 92—94 三个旧根的基线摘要和非破坏扩展规则。
• 能解释标题、题、图、表和演绎为什么分别守恒。
• 能区分 E0（待核对）、E1（直接证据）、E2（已有材料映射）与 E3（演练设计）。
• 能为八条项目主线指出权威事实、幂等键、状态机和恢复判定。
• 能用八段式完成三分钟项目串讲，并在追问时下钻状态和数据。
• 能按现象、假设、证据、止血、查证、修复、恢复验收和复盘回答事故。
• 能解释超时未知态、重复、乱序、积压与重启的不同处理方式。
• 能从项目题库回链唯一机制正文，不复制底层长文。
• 能在新对话中通过固定入口和看板恢复进度，不覆盖并发改动。