性能优化

问题：没有数据的优化都是猜测

性能问题往往不是「哪里慢」一目了然，而是藏在多个环节里：首屏加载超预算、响应时间不达标、Core Web Vitals 分数跌破阈值。更麻烦的是，凭直觉优化很容易引入额外复杂度，却没改善真正关键路径。

核心方法：度量先行，瓶颈驱动

这个技能的工作方式可以总结为四个步骤：

• 先建立基线：用 Performance 工具采集真实数据，明确当前各指标的数值与目标差距。
• 定位真实瓶颈：分析 trace、火焰图 等输出，找出耗时最多且影响最大的环节，而不是凭印象猜测。
• 针对性修复：只在被证实的关键路径上做优化，避免在 非热点代码 上浪费重构成本。
• 复测验证：每次改动后重新测量，确认优化确实生效，同时没有引入新的问题。

何时使用

• 需求文档明确定义了 load time budget、响应时间 SLA 等性能指标。
• 用户反馈或监控告警提示行为变慢。
• Core Web Vitals 评分低于可接受阈值。
• 怀疑某次变更引入了性能退化。
• 正在构建处理大数据集或高并发流量的功能。

适用边界

• 没有证据不要动手：过早优化带来的复杂度成本往往高于性能收益。先确认问题存在且值得修。
• 指标要服务于业务：优化应聚焦用户可感知的体验，而不是单纯追求某个 metric 的数字好看。
• 改动要可回滚：性能修复也可能引入回归，保持每次修改可独立验证。