# Perf

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

- Skill: `lightpointventures/perf` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lightpointventures/perf`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lightpointventures/perf/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: lightpointventures (https://skillmd.com/u/lightpointventures)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lightpointventures/perf

---


# 性能优化

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

## 步骤

### 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）