forge-perflisted

# forge-perf — 性能基准与压测优化 ## Goal 测量系统性能基准，识别 QPS/p95/p99 延迟瓶颈与内存泄漏，并通过测量驱动的迭代循环优化核心路径。 ## 触发条件 - **何时触发**： - 有明确的性能指标需求（用户给定目标：延迟 / 吞吐 / 打包体积）。 - 线上卡顿、请求超时、CPU/内存飙高，需要定位瓶颈并压测。 - 容量规划：评估当前系统上限，为扩容或限流提供依据。 - 依赖升级前后对比：框架 / 中间件 / 关键库版本变更后的回归压测。 - **何时不该触发**： - **没有基线的「凭感觉优化」**：无法量化测量就禁止开工，先补压测工具与基线。 - **随手优化**：非性能任务的开发中顺手改一段循环、顺手加个缓存 → 不启动本 skill，按原任务走，收益顺手记录即可。 - 用户只有「想要更快的代码」的模糊诉求、给不出具体指标 → 先向用户要可测目标，否则回到上一条。 ## Workflow ### 1. 建立性能基准 (Baseline Measurement) 1. 在未修改代码前，运行基准测试并记录初始指标： - 吞吐量 (QPS / RPS) - 延迟分布 (p50 / p95 / p99) - CPU 与 内存 峰值占用 - 前端打包体积 / 首屏加载 (LCP / FID) 2. Baseline 采集后，立即与用户确认**完成标准（目标设定）**： - 必须写成可测数字（如 `p95 < 100ms`、`QPS ≥ 1000`、`LCP < 2.5s`），禁止「尽量快一点」这类空话。 - 未确认目标之前**不进入优化循环**（对齐 R5.5：性能判断必须基于可量化指标）。 - 记录目标、Baseline 采集时间与代码版本，作为后续对比与「退出条件」的依据。 ### 2. 瓶颈分析与诊断 (Profiling) 1. 定位性能瓶颈的根因： - **数据库层**：全表扫描、未建索引、N+1 查询。 - **计算与 IO**：大循环、同步阻塞 IO、未使用的过大依赖。 - **前端层**：重复渲染、大图未压缩、阻塞主线程的长任务。 ### 3. 递归优化与对比 (Benchmark Iteration Loop) 1. 提出 2~3 种优化方案（如增加缓存、异步并行化、批量处理、索引优化）。 2. 逐一应用方案并重复运行基准测试。 3. **保留条件**：仅保留产生显著性能提升且 100% 跑通全量单元测试的方案。 4. 单轮收益低于退出阈值 → 停止迭代，走「退出条件」。 ### 4. 输出性能对比报告 输出 Benchmark 对比表： | 指标 | 优化前 (Baseline) | 优化后 (Optimized) | 提升幅度 | |---|---|---|---| | p95 延迟 | 450ms | 45ms | ⚡ 90% | | QPS | 120 req/s | 1100 req/s | ⚡ 9.1x | ## 退出条件 - 单轮优化收益 **< 5%**（或与���户约定的阈值）→ **停止迭代**，输出报告说明收益与放弃的方案，禁止无休止微调。 - 收益显著但全量测试不过 → **丢弃该方案**，回滚到上一版本，禁止携带不过测的优化。 - 完成标准已达成 → 输出报告并收尾。 - 达到退出条件后仍想继续 → 必须回到「目标设定」重新与用户确认新目标，不得自动