核心用法
该技能采用「Measure → Identify → Fix → Verify → Guard」五步工作流，强制要求先测量再优化。支持 Core Web Vitals（LCP/INP/CLS）目标管理，提供 Synthetic（Lighthouse）与 RUM（真实用户监控）双轨测量方案。内置前后端常见瓶颈诊断树，从症状快速定位根因：前端覆盖大包体积、渲染阻塞、主线程长任务、React 重渲染等问题；后端聚焦 N+1 查询、缺失索引、内存泄漏、缓存策略等场景。
技能提供标准化修复模板，包括数据库查询优化（join/include 替代循环查询）、分页限流、图片响应式优化（avif 格式 + 分辨率切换 + fetchpriority）、React.memo/useMemo 精准使用、路由级代码分割、多级缓存策略等。配套性能预算示例（JS < 200KB、API p95 < 200ms）及 CI 集成方案（bundlesize + Lighthouse CI）。
显著优点
1. 方法论权威性：源自 Anthropic 工程实践，「先测量后优化」原则直击行业过早优化通病
2. 全栈覆盖：统一处理前后端性能，打破前端只管 LCP、后端只管查询的割裂现状
3. 可操作性强：每个步骤有明确完成标准（如「指标改善 ≥10%」），避免模糊优化
4. 指标体系完整：对齐 Google Core Web Vitals 标准，直接关联 SEO 与用户体验
5. 防回归机制：强调添加监控/测试形成闭环，而非一次性修复
潜在缺点与局限性
1. 学习成本：需理解 Synthetic 与 RUM 的区别、profiling 工具使用，对新手有一定门槛
2. 工具依赖：部分方案依赖特定技术栈（React、Prisma 风格 ORM），非通用伪代码
3. 测量开销：RUM 数据采集与 APM 工具引入会增加系统复杂度与成本
4. 优化悖论：「不测量不优化」原则在紧急故障场景下可能显得僵化
5. 预算维护：性能预算需要团队持续投入 CI 配置与阈值调整
适合的目标群体
- 中大型产品团队的技术负责人与性能专员
- 需要系统性提升 Core Web Vitals 评分的前端工程师
- 面临数据库查询性能瓶颈的后端开发者
- 希望建立性能工程文化的工程经理
- 不适合：个人快速原型开发、无真实用户数据的小项目
常规风险
- 性能测量本身影响性能：DevTools Profiler 或 APM agent 可能引入观测开销
- 工具版本漂移：Lighthouse 评分算法更新可能导致预算阈值失效
- 过度优化陷阱：严格遵循预算可能导致过度拆分代码，反而损害可维护性
- 假阳性瓶颈：Synthetic 测试环境与真实用户网络条件差异可能误导优化方向
- 缓存失效风险：后端缓存策略引入需处理一致性与失效逻辑，增加复杂度