优化与验证

本章定位：前六章找到了根因，这一章讲怎么改——以及更重要的：怎么证明改对了。

前置知识：第 5 章（噪声底线、显著性）、第 6 章（根因定位） 预计总时长：约 4 小时（阅读 2.5 小时 + Lab 7 约 1.5 小时） 配套代码：docs/code/07-optimization-and-validation/

一、本章要回答的七个问题

1. 优化应该从哪开始？为什么「调 JVM 参数」永远排在最后？（第 1 节）
2. 哪一类优化的收益最可靠、副作用最小？（第 2 节）
3. 为什么「加线程/协程」可能让系统更慢？（第 3 节）
4. 缓存为什么可能让 P99 变差？（第 4 节）
5. 限流、熔断、隔板、超时、重试——它们分别防的是什么？（第 5 节）
6. 连接池该设多大？为什么「越大越好」是错的？（第 6 节）
7. 每项优化必须回答哪三个问题？（第 8 节）

二、为什么这一章的核心是「纪律」而不是「技巧」

优化技巧在网上到处都是（加缓存、用连接池、换序列化器）。真正的难点是：

技巧是「怎么做」，纪律是「该不该做」和「做完怎么证明」。

一件真实的事：

❌ 没有纪律：
   改了 5 处，P99 从 400ms 到 220ms，团队庆祝。
   三个月后 P99 又回到 400ms，没人知道为什么。
   （因为其中 2 处改动其实无效，1 处引入了新问题）

✅ 有纪律：
   每次只改一处，测完记录（提升多少 + 代价）；
   无效的改动被回滚（省下维护成本）；
   有效的改动被固化 + 加了回归门禁。

前者看起来快，后者才是真正的快。

三、小节地图

四、本章的产出物

1. 一张优化优先级清单：对你手上的问题，按金字塔排序，并说明为什么这个顺序。
2. 1–3 项已实施的优化：每项含 before/after 数据、代价说明、回归验证结果。
3. 至少一项被主动否决的优化：并写明理由。
4. 一份优化收益报告：结构化、含置信区间与未覆盖场景。

五、学完本章的验收标准

• 能对一个优化任务按优先级金字塔排序，并说出为什么。
• 能识别「减少工作」类的优化机会（批处理、N+1、剪枝）。
• 能解释为什么「并行度越大越好」是错的。
• 能说出缓存的三个收益和三个代价。
• 能区分限流、熔断、隔板、超时、重试各自防的是什么。
• 能用 Little’s Law 推导连接池大小，而不是拍数字。
• 每项优化都能回答三个问题：提升多少、代价是什么、回归验证了吗。
• 至少主动否决过一项优化，并写明理由。

六、一个提醒：本章会让你的改动「变少」

学完第 5 章你知道了「多大的差异才算真实」，学完本章你会知道「哪些改动值得做」。

以前：能优化的都优化（并为此引入 5 个新组件）
现在：只优化那些「收益 > 代价 + 复杂度」的（可能只改 1 处）

改动变少，但每一处都有效、都被验证、都能长期维护。 这是性能工作从「手艺人」走向「工程师」的标志。