perf

name	perf
description	当用户觉得页面慢、接口响应慢、打包慢、想优化性能时使用 — 分析瓶颈并给出具体改进方案

性能优化

帮用户找到性能瓶颈并给出具体的改进方案。核心原则：先测量，再优化，再验证。

步骤

1. 确定优化目标

你想优化什么？

• 网页加载速度（首屏渲染慢、页面太大）
• 后端响应时间（API 慢、数据库查询慢）
• 构建速度（打包太慢）
• 内存或 CPU 占用

2. 测量当前基线（必做，优化前必须有数字）

在做任何改动之前，用合适的工具记录当前性能数据作为基线：

前端性能测量：

• Chrome DevTools Performance 面板 — 录制页面加载，查看瀑布图和主线程阻塞
• Lighthouse CLI (npx lighthouse URL --output=json) — 获取 FCP、LCP、TBT、CLS 评分
• WebPageTest (webpagetest.org) — 真实网络条件下的加载瀑布图

Python 后端：

• cProfile — 内置分析器，快速定位耗时函数：python -m cProfile -s cumtime app.py
• py-spy — 采样式分析器，可附加到运行中的进程，无需改代码：py-spy top --pid PID
• line_profiler — 逐行分析特定函数耗时，适合定位热点代码

Node.js 后端：

• --inspect 标志 + Chrome DevTools — node --inspect app.js，然后在 Chrome 打开 chrome://inspect
• clinic.js — 自动诊断工具：npx clinic doctor -- node app.js

数据库：

• EXPLAIN ANALYZE — 在慢查询前加上，查看执行计划和实际耗时。重点关注全表扫描（Seq Scan）和嵌套循环

记录基线数据：具体的数字（如"首页 LCP 3.2s"、"API 响应 P95 800ms"、"查询耗时 1.4s"）。

3. 分析瓶颈

根据测量结果，检查常见问题：

网页加载：

• 图片是否压缩、是否使用现代格式（WebP/AVIF）
• CSS/JS 是否合并压缩，是否有未使用的代码（Coverage 面板检查）
• 是否有阻塞渲染的第三方脚本（加 async/defer）
• 是否使用了懒加载（图片、路由、组件）

后端响应：

• 数据库查询是否有 N+1 问题（ORM 日志看查询次数）
• 是否缺少索引（EXPLAIN ANALYZE 显示 Seq Scan）
• 是否有不必要的重复计算（可加缓存）
• 序列化是否是瓶颈（大 JSON 响应考虑分页或字段筛选）

构建速度：

• 是否有不必要的依赖拖慢构建
• 是否可以用 esbuild/swc 替代 babel/terser

4. 输出优化方案

按投入产出比排序，给出具体建议：

性能分析报告
基线数据：[填入步骤 2 的测量结果]

高影响（优先做）：
- [问题] 具体描述 -> [方案] 怎么改 -> [预期提升] 具体数字

中影响：
- ...

低影响（可选）：
- ...

5. 执行优化并验证

用户选择后，逐个执行优化。每个优化完成后，用步骤 2 相同的工具和条件重新测量，对比基线数据：

• 记录优化前后的具体数字变化
• 如果某项优化效果不明显（提升不到 5%），考虑是否值得保留（增加了代码复杂度但收益小）
• 如果某项优化导致性能下降，立即回滚

优化完成。主要改动：xxx。性能对比：[优化前数字] -> [优化后数字]。

遇到问题

• 优化后反而更慢了 — 最常见的原因：缓存策略不当（缓存了不该缓存的动态数据）、过度拆分导致请求数增加、压缩算法的 CPU 开销超过了节省的传输时间。回滚改动，重新分析基线数据
• 测量结果不稳定，每次跑差异很大 — 排除干扰因素：关闭其他占用资源的程序，多次测量取中位数（至少 3 次），前端测试用无痕窗口避免插件影响，后端测试先预热（丢弃前几次请求的结果）
• 数据库加了索引但查询没变快 — 用 EXPLAIN ANALYZE 确认索引是否真的被使用。常见原因：查询条件中对列做了函数运算导致索引失效、数据量太小优化器选择全表扫描、索引已创建但统计信息未更新（运行 ANALYZE 命令）
• Lighthouse 分数提升了但用户体感没改善 — Lighthouse 是模拟环境，可能与真实用户条件不同。用 Chrome DevTools 的 Network throttling 模拟慢网络（Slow 3G），或查看 Web Vitals 的真实用户数据（RUM）