技能介绍

要解决的问题

性能问题很少以「指标超标」的形式出现，通常是一句模糊的「页面很慢」或「接口超时」。没有测量就开始优化，本质上是在猜测——改了一堆代码，却无法证明用户体感真的变好了；更糟的是过早优化引入的复杂度，可能比它带来的性能收益更贵。这个技能面向的场景很明确：规格里写了加载预算或响应时间 SLA、监控报告了慢行为、Core Web Vitals 低于阈值，或者怀疑某个改动引入了回归。它把「优化」从直觉变成流程：先拿到数据，再定位真正的瓶颈，最后用数据验证修复有效。

核心工作方式

技能围绕一个三步工作流展开：

第 1 步：测量 — 实验室数据与真实用户数据要同时采集。合成监控（Lighthouse、DevTools Performance 面板）条件可控、结果可复现，适合在 CI 中检测回归；真实用户监控（web-vitals 库、CrUX 报告）则回答另一个问题：修复之后，用户的实际体验是否改善。
第 2 步：定位瓶颈 — 按症状反推原因。前端方面，LCP 慢通常指向大图或阻塞渲染的资源，CLS 高常因图片缺尺寸，INP 差则看主线程长任务；后端方面，API 慢先查数据库日志里的 N+1 查询，内存增长用 heap snapshot，CPU 飙升做 profiler 定位。
第 3 步：修复反模式 — 覆盖实践中最常见的坑：N+1 查询、无限制的数据抓取、未优化的图片、不必要的 React 重渲染、包体积失控、缺失缓存。
性能预算：为关键指标设定预算并在 CI 中强制执行，让劣化在合并前被拦住。

适用边界

没有测量证据时不要动手。性能债会复利累积——明显的反模式应该现在就改，微优化可以延后，但都要以数据为依据。「我机器上很快」不成立，要在代表性的硬件和网络下测量。「框架会处理性能」也不成立，框架挡得住部分问题，挡不住 N+1 查询和超大包。任何改动之后，验证清单要求前后数据对比、瓶颈确认已修复、包体积未显著增加、既有测试仍然通过。