附录C：术语与工程检查表
| 术语 | 本书中的准确含义 |
|---|---|
| 取消 | 通知执行者工作已无继续价值；需要协作响应，不强杀goroutine |
| 截止 | 一个绝对时间点；有效截止受父context更早时间限制 |
| 资源所有权 | 对停止使用、关闭和等待最终完成承担责任 |
| 接纳 | 工作进入服务负责的范围；本工程仅内存接纳 |
| 排空 | 不再接纳，让已经承担的工作继续走向终结 |
| 强制清理 | 预算到期后关闭连接、发取消并有限等待合作退出 |
| 终结 | 成功、失败或取消等不再继续的状态，不等于业务成功 |
| 背压 | 下游能力通过等待或拒绝影响上游；仍需限制等待资源 |
| 过载 | 到达需求超过可用处理预算，应该受控拒绝或退化 |
| 数据竞争 | 未建立适当同步的冲突内存访问 |
| 逻辑竞态 | 时序影响业务语义，可能完全没有数据竞争 |
| 累计分配 | 某时间范围产生过的对象字节，包括已回收部分 |
| 存活堆 | 采样所反映仍保留的对象，不等同进程RSS |
| 结果未知 | 调用失败但无法判断远端副作用是否已发生 |
代码评审时，优先回答五组问题。第一组是执行：新goroutine由谁取消、谁等待、错误交给谁？第二组是资源：Body、连接、文件、计时器与缓冲区谁拥有，跨函数后责任是否变化？第三组是容量：运行、排队、输入和输出分别在哪里限额？第四组是关闭：接纳与关闭是否原子排序，是否有共享总截止？第五组是证据：测试是否真的触发阻塞并确认恢复，还是仅检查表面状态码？
诊断时先保留版本、配置和现象，再找对应阶段。客户端超时后看服务工作是否退出；CPU低但延迟高时看等待栈；连接等待时看响应体生命周期；部署卡住时看关闭责任与剩余预算。避免在没有证据时同时修改多个限制，否则即使现象消失，也很难知道哪一个动作有效。
扩展时坚持同一原则：新依赖带来新责任，新队列带来新等待，新缓存带来新保留，新协议带来新关闭边界。可靠性来自这些关系保持可解释和可验证，而不是某个库名、语言特性或一次工具通过。