{{书名}} 比喻注册表

概述

本文件管理全书使用的比喻映射关系。每个核心技术概念最多绑定 一个主比喻，在全书范围内保持一致。

比喻质量标准

一个好的比喻应该满足：

• ✅ 准确性: 比喻的关键特征与技术概念的关键特征匹配
• ✅ 熟悉度: 目标读者对比喻本体足够熟悉
• ✅ 可扩展性: 能延伸到概念的多个方面，不会在某个点上"破裂"
• ✅ 无歧义: 不会让读者产生错误理解

比喻注册表

技术概念	绑定比喻	首次使用章节	状态	注意事项
event loop	餐厅服务员：一个服务员（单线程）轮流服务多桌客人（任务），不会在一桌前傻等上菜（非阻塞），而是先去服务下一桌	ch{{N}}	活跃	不要延伸到"多个服务员"的场景，那是多线程。强调的是"单人轮转"而非"并行服务"
middleware	流水线工人：每个工人（中间件）对传送带上的产品（请求）做一道加工，可以加工后传给下一个工人，也可以直接把不合格品退回（终止请求）	ch{{N}}	活跃	强调"顺序执行"和"可以中断"两个特性。不要延伸到"工人之间可以交流"——中间件之间通过req/res通信，不是直接通信
closure	背包：函数离开了定义它的教室（作用域），但带走了一个背包（闭包），里面装着教室里的课本（变量）	ch{{N}}	活跃	强调"带走"和"仍然可以访问"。不要说"背包里的东西会变"——虽然技术上闭包可以修改外部变量，但这个延伸容易让初学者困惑
{{技术概念}}	{{绑定比喻}}	ch{{N}}	{{活跃/废弃}}	{{注意事项}}

废弃比喻记录

技术概念	原比喻	废弃原因	替代比喻	废弃日期
{{概念}}	{{原来的比喻}}	{{为什么废弃，如"读者反馈容易产生误解"}}	{{新比喻，应已在上面的注册表中注册}}	{{YYYY-MM-DD}}

冲突检测规则

规则1: 一概念一比喻

同一个技术概念在全书范围内只能使用 一个主比喻。

• ❌ 违规示例: 第3章把 event loop 比作"交通警察"，第7章比作"传送带"
• ✅ 正确做法: 全书统一使用"餐厅服务员"，在不同章节中可以延伸该比喻的不同方面

规则2: 不同概念不共享比喻

两个不同的技术概念不能使用相同的比喻，否则读者会混淆。

• ❌ 违规示例: middleware 用"流水线"，pipeline 也用"流水线"
• ✅ 正确做法: 为相关但不同的概念设计有区分度的比喻

规则3: 比喻延伸需一致

如果在第3章说"middleware像流水线工人"，后续章节可以延伸（如"给流水线加了质检站"），但不能矛盾（如"流水线工人可以同时处理多个产品"——这和middleware的串行特性矛盾）。

规则4: 新比喻先注册

任何新比喻 必须先在本文件注册，然后才能在正文中使用。注册时需检查：

• [ ] 该概念是否已有绑定比喻？
• [ ] 新比喻是否与已有比喻冲突？
• [ ] 新比喻是否满足上面的"比喻质量标准"？

规则5: 简单概念不强制比喻

并非所有概念都需要比喻。如果概念本身足够直观（如"变量赋值"），强行使用比喻反而会增加认知负担。

按章节索引

第{{N}}章: {{章标题}}

• {{技术概念A}} → {{比喻A}}
• {{技术概念B}} → {{比喻B}}