性能优化工程师

性能优化不是猜出来的

性能工作最大的陷阱是凭感觉动手。加了一堆缓存、拆了几个包、把组件包进 React.memo，上线后才发现真正卡住首屏的是一个没设尺寸的图片。没有测量的优化只是在给复杂度充值——改得越多，回归风险越高，真正的瓶颈却纹丝不动。

这个技能的工作方式只有一条原则：先测量，再优化。用数据定位真实瓶颈，修复，再测量确认，最后把结果固化成监控和测试，防止下一次回归。

它如何工作

1. 测量，双管齐下

合成指标（Lighthouse、DevTools Performance 面板）受控可复现，适合挂进 CI 做回归检测；真实用户监控（web-vitals 库、CrUX）来自真实条件，验证修复是否真的改善了体验。前端采集 onLCP/onINP/onCLS，后端采集响应时间日志、APM 和数据库查询计时。

2. 按症状定位，不凭直觉

• 首屏慢 → 查包体 / TTFB / 阻塞资源
• 交互卡 → 查主线程长任务（>50ms）/ 重复渲染
• 翻页后慢 → 查 API 瀑布 / N+1
• 后端慢 → 查索引 / 连接池 / CPU / GC

用症状决定从哪入手，而不是打开 DevTools 漫无目的地看。

3. 修复常见反模式

N+1 查询改成单条带 join/include 的查询；无界拉取改成分页（take/skip + orderBy）；图片用 srcset 做艺术指导和分辨率切换，首屏图加 fetchpriority="high",折叠下的图加 loading="lazy" 和 decoding="async"；多余重渲染靠稳定引用和 useMemo 解决；重而少用的特性用动态 import() 拆出去，路由级代码分割包在 Suspense 里；高频只读数据加 TTL 缓存，静态资源用 Cache-Control: max-age 加内容哈希文件名。

4. 设预算，固化到 CI

把性能预算写进 CI：JS 体积、API p95 响应时间、Lighthouse 分数，超预算直接阻断合并。

适用边界

• 规格里有性能要求（加载预算、SLA）、用户或监控报慢、Core Web Vitals 低于阈值、怀疑某次变更引入回归时使用。
• 不适用：没有任何问题证据就提前优化——过早优化增加的复杂度通常高于收益。
• 本技能产出诊断与方案，代码改动由你或下游技能执行。