为什么"优化"总是做错

绝大多数失败的优化都死于同一个原因：没有测量就动手。先看两种工作模式的差异，再理解为什么本书把"测量"放在第一位。

感觉先行 vs 数据先行

感觉先行的问题不是"不专业"，而是人眼无法分辨几毫秒级别的差异：30Hz 到 45Hz 的卡顿，多数人只能说"感觉不流畅"，说不清是哪里。

一个真实的最小代价循环

正确的优化循环只有四步：

1. 测量：用工具拿到当前帧时间与热点分布；
2. 假设：根据数据提出"最可能的瓶颈"；
3. 验证：只改这一处，再测一次；
4. 记录：把前后对比写进文档（不带数据的优化经验不值得分享）。

关键纪律：第 3 步如果测不出改善，就立刻回滚。改了一堆但帧率没动 = 代码变脏了而问题还在。

性能优化的三个真相

1. 帕累托法则：90% 的时间花在 10% 的代码上。优化的全部工作就是找到那 10%；
2. 过早优化是万恶之源（Knuth）：未测量前的"顺手优化"通常带来复杂度而没有收益；
3. 优化是 trade-off：用可读性 / 维护性换性能，所以每笔交易都要明码标价（记下来"为了 2ms 牺牲了什么"）。

什么时候停止优化

达到预算就停。帧率达标（如 60Hz 稳定）之后继续优化是沉没成本。把"够用"定义为可量化的目标（目标帧率 + 目标内存 + 目标加载时间），而不是"尽可能快"。