综合实战

本章定位：把前八章串成一个完整闭环——从「定义目标」到「设立门禁」，产出一份可对外汇报的性能报告。

前置知识：第 0–8 章全部 预计总时长：约 3–5 天（这不是一次性读完的章节，是一个实施指南） 配套代码：docs/code/09-capstone/

一、这一章与前八章的关系

前八章是方法，这一章是把这些方法用在一个真实项目上：

注意：每一步都依赖前一步——跳过第 3 步（基线）就无法做第 6 步（优化验证），因为你没有 before。

二、项目设定：短链服务

为什么选短链服务：

技术栈：Ktor + Kotlin 协程 + PostgreSQL + Redis（与全书一致）

三、小节地图

四、本章的最终交付物

八份文件，它们本身就是一份完整的性能工程成果：

关键：第 8 份（最终报告）的价值不在于数字漂亮，而在于「别人能按你的方法复现出同样的数字」。

五、评分标准

评分的核心是「可复现」与「可决策」，不是「数字有多好」。

六、怎么用这一章

三种用法：

推荐第一种——因为性能工程的很多细节，只有亲手做过才知道（比如「噪声底线到底有多大」「幂律分布怎么造」「火焰图上什么样叫宽而平」）。

七、一个提醒：不要追求「完美」

真实的性能工程不是「把所有指标都做到极致」，而是：

✅ 在有限时间里，把最关键的问题解决到「可验证、可维持」的程度

❌ 花两周把 P99 从 95ms 优化到 92ms（在噪声范围内，无法证实）

本章的验收标准是：

• 你的证据链完整（能复现）
• 你的结论有边界（写了未覆盖的场景）
• 你的机制能持续（门禁零误报）

而不是：P99 有多低。