技能介绍

要解决的问题

性能优化最容易踩的坑不是「不会优化」，而是「在没有数据的地方优化」。团队凭着感觉改代码，上线后发现瓶颈根本不在那里，复杂度却实打实地增加了。Performance Optimization 把这条方法论固化成可执行的流程：先测量，再定位，最后才动手。

技能如何工作

它内置了一组明确的判断标准和操作步骤：

核心 Web Vitals 阈值：以 LCP（≤ 2.5s）、INP（≤ 200ms）、CLS（≤ 0.1）为「良好」线，低于阈值时触发优化流程。
双轨测量：合成监控（Lighthouse、DevTools Performance 面板）用于可复现地检测 CI 回归；真实用户监控（web-vitals、CrUX）用于验证改动是否真的改善了体验，两者缺一不可。
按症状定位瓶颈：提供前后端对照表，例如 LCP 慢查图片体积与阻塞渲染的资源，API 慢查 N+1 查询与缺失索引，INP 差查主线程长任务。
修复常见反模式：N+1 查询、无上限的数据抓取、未做尺寸/懒加载处理的图片、React 多余重渲染、包体积膨胀、缺少缓存。
预算进 CI：性能预算不达标则构建失败，把性能回归挡在合并之前。

适用边界

它明确列出了不该用的场景：没有证据表明存在性能问题时，不要提前优化。文档里那张「常见自我合理化」对照表值得一读——「以后再优化」「我机器上很快」「框架会帮我处理」基本都站不住脚。同时它也提醒，React.memo 和 useMemo 到处乱加与完全不加一样有害。任何性能改动完成后，都需要有改动前后的数值、瓶颈说明、核心指标达标情况和测试通过记录，否则这次优化就不成立。