如何使用真实案例

课程先讲通用知识，再用真实代码检验它。一个案例说明某种方案在某个约束下怎样实现，不能自动证明它是所有系统的最佳方案。

四种信息分别阅读

信息	如何理解
通用原理	例如单库事务不能原子覆盖任意远端副作用
教学例子	为解释核心机制省略完整工程代码，不能直接当成生产实现
当前实现	已核对源码的具体行为，有路径、符号与版本
设计计划	ADR、需求与未实现方向，不能冒充当前运行能力

源码证据的粒度

每个证据保存仓库、完整提交 SHA、文件路径、符号、行范围、核对日期及必要片段。文件 SHA-256 用于检查内容是否变化；若文件有未提交修改，则明确标记工作区快照。

提交标识描述核对时的来源，不是线上部署标识。行号可能随代码演进改变；定位时优先看路径和符号。片段在网站内部保存，手机无需打开 Git 仓库也能读关键实现。

五个代码阅读问题

1. 这段逻辑处理命令、事实、投影还是传输消息？
2. 成功的持久化证据是什么？
3. 外部调用发生在事务提交前还是后？
4. 重复请求或消息由哪个键或状态条件吸收？
5. 恰好在下一步崩溃，谁根据什么继续？

不要只看接口名字。Repository 的原子承诺要读适配器与 SQL；调度 Select 的纯计算要继续读事务预留；日志字段 trace_id 要核对是否实际建立分布式 trace。

内容怎样保持同步

网站的 sources:check 在完整 Workbench 中比较源文件内容、提交和片段位置；变化后先审阅差异并修订解释，再显式 sources:update。脚本只更新证据，不会自动保证文章仍正确。

静态构建不读取相邻源码，因此单独检出学习站也可构建阅读；缺少源码时不能宣称已经验证最新实现。章节解释以保存的证据版本为准。

从案例迁移到新系统

先提取问题与不变量，再比较约束：吞吐、延迟、外部幂等能力、权限、数据所有者、部署方式。最后选择机制，而不是照搬库名、目录或租约数字。

例如 Outbox 的一分钟租约和重试次数来自案例实现。邮件发送和 GPU 渲染的时限完全不同，复制常量不能替代设计。

进入 项目证据地图 或 源码快照。