性能剖析与优化套装

这个 pack 包含什么

这是给那个被 @ 的工程师用的：「/search 接口要 8 秒，能看一下吗？」或者「这个 dashboard 一打开卡两秒。」10 件套，每件在五步闭环里有明确角色：baseline → 剖析 → 诊断 → 修一处 → 回归压测。

每个工具都是开源或有覆盖整个闭环的免费档。零「请联系销售」、零 SaaS-only 遥测。AI agent（Performance Profiler / GraphQL Performance Optimizer / Postgres MCP Pro）读的是真正的 profile 输出 — 不是看你代码瞎猜「这里加个索引吧」。

推荐安装顺序

1. Claude Code Agent: Performance Profiler — 编排者。第一个装，因为后面你会把火焰图和 trace 都喂给它。它分得清 CPU profile / off-CPU profile / wall-clock profile 的区别，不会在 GC pause 是瓶颈时给你建议「加个缓存」。
2. Lighthouse — 前端 baseline。动手前先跑 lighthouse https://your.url --output html，存下报告。后面每次改动都重跑做 diff。这是你的前端「之前的样子」。
3. Size Limit — JS 包体性能预算。第一天就接 CI。配好 size-limit: [{ path: 'dist/*.js', limit: '200 KB' }]，后面每个让 bundle 膨胀的 PR 在合并前被卡。整套里最便宜的性能收益。
4. FlameGraph — Brendan Gregg 的 perl/SVG 火焰图生成器。生态里其他工具说的就是这个文件格式。装一次，pack 里其他 profiler 都能往里灌：perf script | stackcollapse-perf.pl | flamegraph.pl > out.svg。
5. async-profiler — JVM 低开销采样剖析器。给 Java/Kotlin/Scala 服务用。生产环境 ~1% 开销，输出的 collapsed-stack 格式直接进 FlameGraph。CPU / 内存分配 / 锁竞争 / wall-clock 一个工具全包。
6. BCC (BPF Compiler Collection) — Linux eBPF tracing。瓶颈在你 runtime 之下时用这个 — syscall / 磁盘 I/O / 网络 / 缺页。biolatency / tcpretrans / funccount 是你最先用的三条命令。
7. Grafana Pyroscope — 持续 profiling 后端。修完一个慢接口后装它，让下一次回归是 dashboard 上的火焰图 diff，不是凌晨 11 点的 Slack 消息。原生兼容 FlameGraph 格式。
8. Postgres MCP Pro — 索引调优 + 安全 SQL MCP。「查询慢」就用它 — 把这个 MCP 挂到 Postgres 上，让 agent 解释执行计划，它会跑真实 EXPLAIN ANALYZE + 给索引建议，并且自己再跑一次 EXPLAIN 验证过。不是幻觉。
9. Claude Code Agent: GraphQL Performance Optimizer — 给每个 GraphQL gateway 早晚都会撞上的 N+1 问题准备的。读你的 resolver，找未 batch 的 DB 调用，按你的 schema 给具体的 DataLoader 修复方案。
10. k6 — JavaScript 脚本驱动的压测工具。回归保护网。每次修完，对 staging 跑同一份 k6 脚本，比 p50/p95/p99。如果你用 k6 脚本复现不了那个慢路径，就证明不了你修好了。

它们怎么协同

┌─ BASELINE ─────────────────────────┐
│ Lighthouse（前端）                  │
│ k6（后端 p50/p95/p99）              │
│ Size Limit（CI 里的包体预算）        │
└─────────────┬──────────────────────┘
              │ 「确实慢 — 但慢在哪？」
              ▼
┌─ PROFILE ──────────────────────────┐
│ async-profiler（JVM）               │
│ BCC / eBPF（syscall、I/O）          │
│ Pyroscope（生产持续采集）           │
│ → 都输出 FlameGraph 格式           │
└─────────────┬──────────────────────┘
              │ flamegraph.svg
              ▼
┌─ DIAGNOSE（agent 读 profile）──────┐
│ Performance Profiler agent          │
│ Postgres MCP Pro（查询计划）        │
│ GraphQL Performance Optimizer       │
└─────────────┬──────────────────────┘
              │ 「热路径是 X，修法是 Y」
              ▼
        修一条热路径
              │
              ▼
┌─ REGRESSION TEST ──────────────────┐
│ k6（重跑同一脚本，比 p95）          │
│ Lighthouse（重跑，比分数）          │
│ Pyroscope（火焰图 diff）            │
└────────────────────────────────────┘

闭环不可妥协。**跳过 baseline 就证明不了修好了。**跳过火焰图就是瞎猜 — 而且 LLM 会猜得更狠。跳过回归，下次发布静默地把它改回去你都不知道。

你会遇到的取舍

• Pyroscope vs 一次性 async-profiler 抓 — Pyroscope 是持续的（常开、低开销、吃存储）。async-profiler 是按需的（怀疑时跑 60 秒，空闲零开销）。先用 async-profiler；修过两次回归、想让第三次从 dashboard 一眼看到，再装 Pyroscope。
• BCC vs perf — BCC 更高层，用 Python 写脚本（可读）。perf 是内核自带的剖析器，更底层、略更通用。BCC 是更友好的入口；需要 BCC 没暴露的特定事件源时再上裸 perf。
• Lighthouse 本地跑 vs LH-CI — 本地 Lighthouse 是一次性的。Lighthouse-CI 在每个 PR 上跑并存趋势。修完第一个之后装 LH-CI；否则本地够用。
• Size Limit vs Bundlephobia/Webpack Bundle Analyzer — Size Limit 在回归时卡 CI（主动）。分析器只展示你的 bundle（被动）。两个都有用；Size Limit 是阻止下一波 50 KB 意外膨胀的那个。
• k6 vs Artillery vs Locust — k6 赢在脚本人体工程学（真 JavaScript，不是 YAML）、内置 p95/p99 报告、Grafana 集成。团队 YAML 派选 Artillery；团队 Python 派选 Locust。

常见踩坑

• 在 dev 剖析，给 prod 修 — 你笔记本 CPU 更快、数据集更小、JVM 还在解释模式。永远在贴近 prod 负载的环境里剖析。 Pyroscope 在 prod 抓胜过 async-profiler 在笔记本抓，每次都赢。
• 把火焰图当调用树读 — 火焰图是采样的栈。宽度 = CPU 时间，不是调用次数。一块很宽不代表「被调了很多」，代表「在那里花了很多 CPU」。
• 不给 LLM 看 profile 就让它优化 — 每个不带实测数据的「优化这段代码」prompt 返回的都是通用建议（「加 memoization」「改用 Set」）。把火焰图或 EXPLAIN ANALYZE 直接喂给 agent。这就是 Performance Profiler agent 和 Postgres MCP Pro 存在的理由。
• 修了冷路径 — 80% 的「优化」改的是只占 0.1% 运行时间的代码。改之前先确认那个函数真的在火焰图 top 5 里。
• 修完没回归测 — 如果你用 k6 脚本（或 SQL 复现）回放不了那个慢路径，下次重构就会把它静默改回去，两周后才有人发现。