用途：找出系统变慢的原因，并确认修复是否真正有帮助，流程为症状、剖析、瓶颈、最小可行修复、重新测量。它负责性能剖析、误诊排查、尾延迟与容量数学，以及改动前后的回归判断；不负责设计负载测试活动、CI 性能门禁或 Core Web Vitals 预算。
主要能力：CPU 热点路径用语言自带剖析器做火焰图优先的分析；对停顿、卡顿、p99 上升，在调 GC 之前先做锁感知与 off-CPU 剖析；用“同一条件下的重新测量”对照基线噪声带判断改动是否有效——落在噪声带内视为未改进。前端回退可用 scripts/check_perf_budget.py 检查 Lighthouse JSON（越界退出码 1，输入无效或缺预算指标退出码 2；缺 INP 时可用显式 TBT 实验室预算）。
使用方式：先定义症状、暴露它的指标（p50/p95/p99、吞吐、堆）、流量形态与验收阈值；在生产-like 的构建、数据集与部署形态下复现；剖析能暴露瓶颈的最小对象（CPU 火焰图、锁/off-CPU 剖析、堆快照差异或链路追踪）；多跳路径要逐段计时，因为端到端数字无法说明延迟归属。只修测量到的约束，同一改动中避免顺手清理无关代码；用相同方法与相同运行次数重测，只有超出噪声带才保留改动。
适用场景：发布后 API p95 回退；p99 翻倍而 p50 持平、CPU 仅 40%（怀疑排队或争用而非 CPU）；长跑服务内存增长；现场数据中 LCP 变慢。
限制与注意：不要为不在关键路径、收益低于测量噪声、或用罕见灾难性故障换平均速度的“优化”投入；常见误诊包括把锁争用归咎 GC、把驱动耗时归咎数据库、把热点路径新增同步调用归咎冷缓存、把排队归咎网络、把低延迟或短队列误读为数据新鲜；尾延迟与容量计算涉及 Little's Law、连接池上限、Amdahl's Law 与扇出联合尾延迟，且不得跨主机或时间窗对百分位数取平均。基准结果必须记录工作负载、数据量、并发、预热、缓存状态、构建模式、硬件、网络路径与运行间方差，一次运行、debug 构建、合成理想路径或瓶颈与生产不同的基准结论应被拒绝。剖析器标志与工具版本行为随时间变化，需对照当前一手来源或对固定版本运行 --help 核验；无法实时验证时应给出方法论并标注工具性结论为暂定。本技能资料未提供价格与具体平台信息。