（4134期）performance-optimization – 测量驱动的全栈性能优化

测量驱动的全栈性能优化 Anthropic 官方技能，通过科学测量方法定位前后端性能瓶颈，帮助团队建立数据驱动的优化流程，避免过早优化陷阱。 使用说明 核心用法 该技能采用「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）。 显著优点 方法论权威性：源自 Anthropic 工程实践，「先测量后优化」原则直击行业过早优化通病 全栈覆盖：统一处理前后端性能，打破前端只管 LCP、后端只管查询的割裂现状 可操作性强：每个步骤有明确完成标准（如「指标改善 ≥10%」），避免模糊优化 指标体系完整：对齐 Google Core Web Vitals 标准，直接关联 SEO 与用户体验 防回归机制：强调添加监控/测试形成闭环，而非一次性修复 潜在缺点与局限性 学习成本：需理解 Synthetic 与 RUM 的区别、profiling 工具使用，对新手有一定门槛 工具依赖：部分方案依赖特定技术栈（React、Prisma 风格 ORM），非通用伪代码 测量开销：RUM 数据采集与 APM 工具引入会增加系统复杂度与成本 优化悖论：「不测量不优化」原则在紧急故障场景下可能显得僵化 预算维护：性能预算需要团队持续投入 CI 配置与阈值调整 适合的目标群体 中大型产品团队的技术负责人与性能专员 需要系统性提升 Core Web Vitals 评分的前端工程师 面临数据库查询性能瓶颈的后端开发者 希望建立性能工程文化的工程经理 不适合：个人快速原型开发、无真实用户数据的小项目 常规风险 性能测量本身影响性能：DevTools Profiler 或 APM agent 可能引入观测开销 工具版本漂移：Lighthouse 评分算法更新可能导致预算阈值失效 过度优化陷阱：严格遵循预算可能导致过度拆分代码，反而损害可维护性 假阳性瓶颈：Synthetic 测试环境与真实用户网络条件差异可能误导优化方向 缓存失效风险：后端缓存策略引入需处理一致性与失效逻辑，增加复杂度 原始说明 Measure bottlenecks then optimize for performance