性能调试（Performance Debugging）
概述
性能调试是一套系统化的方法论，用于定位和解决前端、后端及数据库层面的性能瓶颈。核心原则：先测量，再优化；修复根因，而非症状。
何时启动性能调试
- 页面加载时间超过 3 秒
- CPU 使用率持续偏高（>80%）
- 内存持续增长，疑似内存泄漏（Memory Leak）
- 数据库查询响应缓慢（>500ms）
- 用户反馈卡顿或超时
四步工作流
- 测量（Measure） -- 用客观数据确认问题存在，建立基线指标
- 分析（Profile） -- 使用专业工具定位热点代码路径
- 假设（Hypothesize） -- 根据分析数据提出瓶颈假说
- 修复（Fix） -- 针对根因实施修复，回归验证指标改善
前端性能分析
| 工具 | 用途 | 关键指标 |
|---|---|---|
| Chrome DevTools Performance | 运行时分析、火焰图 | 主线程阻塞时间 |
| Lighthouse | 综合评分、优化建议 | Performance Score |
| Web Vitals | 核心用户体验指标 | LCP、FID、CLS |
核心 Web 指标（Core Web Vitals）阈值：
- LCP（最大内容绘制）：< 2.5s 为优
- FID（首次输入延迟）：< 100ms 为优
- CLS（累积布局偏移）：< 0.1 为优
后端性能分析
| 语言/运行时 | 工具 | 命令示例 |
|---|---|---|
| Python | cProfile / py-spy | py-spy top --pid <PID> |
| Node.js | 内置 profiler | node --prof app.js |
| Go | pprof | go tool pprof http://localhost:6060/debug/pprof/profile |
数据库性能分析
- EXPLAIN ANALYZE：查看查询执行计划，识别全表扫描
- 慢查询日志（Slow Query Log）：设置阈值（如 200ms），捕获慢查询
- N+1 检测：ORM 场景下逐条查询关联数据的常见问题，使用
eager loading解决
内存泄漏排查
- 使用堆快照（Heap Snapshot）对比不同时间点的对象分配
- 检查 GC 日志，观察垃圾回收频率和回收量
- 关注闭包（Closure）持有的外部引用、未清理的定时器和事件监听器
常见问题速查表
| 症状 | 可能原因 | 修复方向 |
|---|---|---|
| 首屏加载慢 | 打包体积过大 | 代码分割（Code Splitting）、懒加载 |
| API 响应慢 | 缺少索引或 N+1 查询 | 添加数据库索引、优化查询 |
| 页面卡顿 | 主线程长任务阻塞 | Web Worker、任务拆分 |
| 内存持续增长 | 事件监听器未清理 | 组件卸载时移除监听 |
| 高 CPU 占用 | 死循环或低效算法 | 算法优化、缓存计算结果 |
禁止事项
- 禁止：未测量就优化 -- 凭直觉优化往往事倍功半
- 禁止：只修症状不查根因 -- 治标不治本的优化会反复出现
- 禁止：一次改多处 -- 无法判断哪个修改生效，应逐一验证