performance-optimization Skill 多维度简评

类别:性能 / 调优 / 可观测性 仓库:anthropics/skills 维护者:Anthropic 官方 引用:Anthropic Skills Blog · 今日头条 Skills 拆解 · 掘金 Top10

一、核心定位与价值

performance-optimization 不是一个独立 Skill,而是Anthropic Skills 体系下的性能方法论——结合 webapp-testing、web-artifacts-builder、mcp-builder 等 Skill,以及 Skills 三层加载机制做性能调优。

关键洞见:Skills 的”渐进式披露” 本身就是性能优化——Agent 启动只加载元数据(~50 tokens),按需加载完整指令(500 tokens),最深的资源层才加载 references 和 scripts。这是 Skills 体系内建的性能最佳实践。

适用场景

• Web 应用加载优化
• API 响应时间优化
• 数据库查询慢
• 内存 / CPU / 网络瓶颈
• 大规模流量应对

不适用场景

• 一次性原型
• 纯功能 bug(用 debugging)
• 安全问题(用 trailofbits)

二、5 大性能方法论

2.1 Measure Before Optimize(先度量后优化)

没有度量,就没有优化。——Robin Sharma

必需度量:
  - P50 / P95 / P99 延迟
  - QPS / TPS
  - 错误率
  - CPU / 内存 / 网络
  - 数据库查询次数
  - 缓存命中率

2.2 80/20 法则

20% 的代码占用 80% 的资源。先优化热点。

# 用 py-spy / async-profiler / 0x / pprof 找热点
# Python
py-spy dump --pid <pid>

# Node.js
clinic doctor

# Go
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30

# Java
java -agentlib:hprof ...

2.3 缓存一切可缓存

缓存层级:
  浏览器:
    - HTTP 缓存(Cache-Control / ETag)
    - Service Worker
    - localStorage / sessionStorage
    - IndexedDB
  CDN:
    - 静态资源(JS / CSS / 图片)
    - 边缘计算(Cloudflare Workers / Vercel Edge)
  应用层:
    - 内存缓存(LRU)
    - Redis / Memcached
    - 进程内缓存(Caffeine / sync.Map)
  数据库:
    - Query Cache
    - Materialized View
    - 结果集缓存(MySQL query cache)

2.4 异步一切可异步

# ❌ 同步串行
def get_dashboard(user_id):
    user = db.get_user(user_id)         # 100ms
    orders = db.get_orders(user_id)     # 200ms
    recommendations = api.get_recs()    # 300ms
    return render(user, orders, recs)   # total: 600ms

# ✅ 并行异步
async def get_dashboard(user_id):
    user, orders, recs = await asyncio.gather(
        db.get_user(user_id),
        db.get_orders(user_id),
        api.get_recs()
    )  # total: 300ms (max of 3)
    return render(user, orders, recs)

2.5 数据库优化优先级

1. 索引(影响最大)
2. 查询改写(避免 SELECT *)
3. JOIN 优化(小表驱动大表)
4. 分区(partition)
5. 读写分离
6. 垂直 / 水平分库分表
7. 缓存层(Redis)
8. 异步队列(削峰)

三、6 类瓶颈排查

3.1 前端加载慢

诊断:
  - Lighthouse / WebPageTest
  - Chrome DevTools Performance
  - Network waterfall

常见原因:
  - JS bundle 太大(> 200KB gzipped)
  - CSS 未压缩
  - 图片未优化(WebP/AVIF)
  - 字体未子集化
  - 第三方脚本阻塞
  - 未启用 HTTP/2 或 HTTP/3
  - 无 CDN

优化:
  - 代码分割(lazy import)
  - Tree-shaking
  - 图片转 WebP/AVIF
  - 字体 preload + font-display: swap
  - 第三方脚本 defer / async
  - 关键 CSS 内联
  - 启用 Brotli

3.2 API 响应慢

诊断:
  - APM(OpenTelemetry / Datadog / New Relic)
  - trace 查询
  - 慢查询日志

常见原因:
  - N+1 查询
  - 缺少索引
  - 同步阻塞调用
  - 大 JSON payload
  - 缺少分页 / 限制
  - 冷启动(无 warmup)

优化:
  - JOIN 替代 N+1
  - 加索引
  - 异步非阻塞
  - 字段过滤(GraphQL)
  - 游标分页
  - 预热池

3.3 数据库瓶颈

诊断:
  - pg_stat_statements(Postgres)
  - 慢查询日志
  - EXPLAIN ANALYZE
  - pg_stat_user_tables(看 seq_scan vs idx_scan)

常见原因:
  - 缺索引
  - 索引失效(类型不匹配 / 函数包装)
  - 大表全表扫描
  - 锁等待
  - 连接池耗尽
  - I/O 瓶颈(磁盘慢 / 缓存小)

优化:
  - 加 B-tree / GIN / partial 索引
  - 改写 SQL
  - VACUUM FULL
  - 连接池(PgBouncer)
  - SSD 替代 HDD
  - shared_buffers 调大

3.4 内存泄漏

诊断:
  - heap dump
  - 内存 profile
  - GC 监控

常见原因:
  - 闭包持有大对象
  - 监听器未移除
  - 缓存无限增长
  - 事件订阅未取消
  - 循环引用

优化:
  - 弱引用
  - 定期清理
  - LRU 限制大小
  - 显式 removeListener
  - WeakRef / SoftRef

3.5 CPU 100%

诊断:
  - pprof / py-spy
  - top / htop
  - 火焰图

常见原因:
  - 死循环
  - O(n²) 算法
  - JSON 解析巨大
  - 正则回溯
  - 同步阻塞
  - 锁竞争

优化:
  - 改算法
  - 加缓存
  - 流式处理
  - 预编译正则
  - 异步
  - 减少锁粒度

3.6 网络瓶颈

诊断:
  - Wireshark / tcpdump
  - CDN 监控
  - 带宽监控

常见原因:
  - 跨大洲请求
  - 大文件未压缩
  - 无 keep-alive
  - TLS 握手频繁
  - DNS 慢

优化:
  - CDN 就近访问
  - Brotli 压缩
  - HTTP/2 multiplexing
  - TLS 1.3 + session resumption
  - DNS 预解析

四、4 大优化模式

4.1 Bulkhead(舱壁模式)

# 不同服务用不同资源池
# 一个服务挂了,不影响其他
thread_pool_a = ThreadPoolExecutor(max_workers=10)  # 关键路径
thread_pool_b = ThreadPoolExecutor(max_workers=5)   # 非关键路径

4.2 Circuit Breaker(熔断)

# 用 pybreaker / resilience4j
@circuit_breaker(failure_threshold=5, recovery_timeout=30)
def call_external_api():
    return requests.get("https://api.example.com")

4.3 Rate Limiter(限流)

# 用令牌桶 / 滑动窗口
from redis_rate_limit import RateLimiter
limiter = RateLimiter(client=redis, limit=100, window=60)

if not limiter.allow(user_id):
    raise HTTPException(429, "Too Many Requests")

4.4 Backpressure(背压)

# 当下游处理不过来,上游放慢
async def producer():
    for item in items:
        await channel.send(item)  # channel 满时自动阻塞

async def consumer():
    while True:
        item = await channel.recv()
        process(item)

五、性能预算(Performance Budget)

5.1 设定标准

5.2 用 Lighthouse CI 守门

# .lighthouserc.json
{
  "ci": {
    "collect": {
      "url": ["https://example.com/"],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "first-contentful-paint": ["error", { "maxNumericValue": 1500 }],
        "interactive": ["error", { "maxNumericValue": 3500 }]
      }
    }
  }
}

5.3 用 bundlewatch 守门

// package.json
"bundlewatch": {
  "files": [
    { "path": "dist/*.js", "maxSize": "200KB" }
  ]
}

六、与其他 Skill 配合

完整工作流:

[1] Measure: APM + 慢查询日志
  ↓
[2] Identify hotspot: profile + trace
  ↓
[3] Optimize: cache / async / 索引
  ↓
[4] Verify: A/B test + 性能预算
  ↓
[5] Monitor: 持续 APM

七、5 条反合理化

八、5 条实战技巧

1. 先 Profile,后优化——永远找热点
2. 缓存是双刃剑——加 TTL + 失效策略
3. CDN 加速 50% 流量——静态资源必上 CDN
4. 数据库连接池——不用 PgBouncer 等于自杀
5. RUM 监控——真实用户数据 > 合成测试

九、Q&A

Q: 跟 web-design-guidelines 区别? A: web-design-guidelines 关注 UX 一致性;performance-optimization 关注速度。

Q: 跟 webapp-testing 区别? A: webapp-testing 是功能测试;性能测试用 Lighthouse CI / k6 / autocannon。

Q: 必须用 Claude Opus 吗? A: 工具本身不需要。Skill 引导 Claude 输出优化建议。

Q: 跟 superpowers 关系? A: superpowers 提供方法论(brainstorming / TDD / verification);性能调优是其中一环。

Q: 跟 ECC 关系? A: ECC 的 verification-loop 可自动跑性能测试。

Q: 中文支持? A: 完美。

Q: 学习曲线? A: 中等。需懂性能基础。

十、Prompt 模板

模板 1:定位瓶颈

请用 performance-optimization 帮我定位瓶颈:
- 应用: Node.js + Express + PostgreSQL
- 现象: P99 延迟 2s
- 已有: APM (Datadog)
请:
1. 看 Datadog trace 找最慢的 span
2. 看 pg_stat_statements 找最慢查询
3. 看 node profiler 找热点函数
4. 输出根因 + 优化建议

模板 2:优化前端

请用 webapp-testing + Lighthouse 优化我的网站:
- URL: https://example.com
- 当前 Lighthouse: 65
- 目标: 95+
请:
1. 跑 Lighthouse CI 拿报告
2. 标出 Top 5 问题
3. 给出具体修复方案
4. 提供修改后预期分数

模板 3:数据库优化

请用 clickhouse-io / postgres-patterns 优化我的慢查询:
- 查询: [粘贴]
- 当前耗时: 5s
- 表大小: 1 亿行
请:
1. EXPLAIN ANALYZE 看执行计划
2. 检查索引
3. 提供改写版本
4. 给出预期提升

十一、真实踩坑案例

案例 1:加机器没用

现象:CPU 100%,加 4 台机器还是 100%。 根因:有死循环 + 全局锁。 解决:找到死循环 + 改用 concurrent map。

案例 2:缓存雪崩

现象:Redis 挂的瞬间,DB 被打挂。 根因:所有 key 同 TTL 过期。 解决:TTL 加随机 jitter + 多级缓存。

案例 3:N+1 查询

现象:列表页 100 个 item = 100 次查询。 解决:include 一次性 join。

案例 4:Lighthouse 100 但 RUM 慢

现象:本地 Lighthouse 95,用户反馈”打开慢”。 根因:4G 网络 + 老手机。 解决:真机测试 + RUM 监控(PerformanceObserver API)。

案例 5:连接池耗尽

现象:API 报 “connection timeout”。 根因:N+1 查询占住连接 10s。 解决:加连接池 + 减少慢查询。

案例 6:内存爆炸

现象:服务跑 6 小时 OOM。 根因:LRU cache 没限制大小。 解决:加 maxSize + LRU eviction。

案例 7:首字节慢(TTFB)

现象:TTFB 3s。 根因:服务端渲染 + 同步 DB 查询。 解决:改 streaming + 加 Redis 缓存。

案例 8:大 JSON 传输

现象:API 返回 5MB JSON。 根因:包含冗余字段。 解决:字段过滤(GraphQL / JSON:API) + 压缩(gzip / brotli)。

案例 9:第三方脚本拖慢

现象:analytics.js 阻塞 1s。 根因:同步加载。 解决:async / defer + next/script strategy=lazyOnload。

案例 10:循环里 await

现象:100 次 DB 查询串行 5s。 根因:for x of items: await db.query(x)。 解决:Promise.all(items.map(x => db.query(x)))。

十二、真实战绩

十三、相关工具速查

十四、安装

# Claude Code
/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills

# 配合工具
npm install -g lighthouse
npm install -g autocannon
brew install wrk

# 通用
npx skills add anthropics/skills --skill webapp-testing

十五、总结

核心价值:

• 5 大方法论:Measure / 80-20 / Cache / Async / DB
• 6 类瓶颈排查模板
• 性能预算守门
• 4 大优化模式(Bulkhead / Circuit / Rate / Backpressure)
• 完整工具链

适用人群:

• 后端工程师
• 前端工程师
• SRE / DevOps
• Tech Lead

投入产出比:⭐⭐⭐⭐(4/5)—— 高频性能问题必装。

何时不要用:

• 一次性脚本
• 不在乎性能(如内部工具)
• 没有监控数据

参考链接:

• Anthropic 官方 Skills 仓库
• Anthropic Skills + MCP 协同 Blog
• 掘金:GitHub 高星 Agent Skills Top 10
• 配套:webapp-testing | postgres-patterns | clickhouse-io | verification-before-completion

参考资料

1. Lighthouse 性能审计
2. Core Web Vitals 官方标准
3. Google Web Performance 最佳实践
4. OpenTelemetry 可观测性
5. k6 负载测试