07 · 性能优化通用思路：测量、定位、优化、回归
性能优化的第一原则：先测量，再优化。 凭感觉优化十有八九是白费——你优化的那个环节可能根本不是瓶颈。本篇给一套跨前端、后端、AI 通用的闭环：测量 → 定位 → 优化 → 回归。
速览卡
| 项 | 内容 |
|---|---|
| 一句话定位 | 用"测量 → 定位 → 优化 → 回归"四步闭环，让性能优化从"凭感觉"变成"可量化、可验证、可防回退" |
| 核心内容 | 为什么先测量、性能指标怎么定、定位瓶颈的方法、优化策略分类、回归防线、跨端对照 |
| 读完能回答 | 拿到"页面很慢"先做什么？怎么找到真正的瓶颈？优化完怎么证明有效且没回退？ |
| 相关板块 | A25 · 前端性能度量与诊断 ｜ C07 · 服务端性能与容量 ｜ DB02 · 索引原理与优化 |
一、为什么"先测量"是铁律
性能问题最隐蔽的地方是瓶颈往往不在你以为的地方：
text
"页面慢"可能来自：DNS → 连接 → 请求 → 后端处理 → 数据库查询 → 渲染
凭感觉可能直接去优化渲染，但瓶颈其实在数据库慢查询。测量让"慢"从感觉变成数字：谁慢、慢多少、占多少比例。没有测量，优化就是赌博。
二、先定指标：没有指标就没有目标
优化前先定"要优化哪个指标"，并且选对指标：
| 场景 | 常用指标 | 要点 |
|---|---|---|
| 首屏 | P50 / P95 耗时、LCP、FCP | 看分布，别看平均值 |
| 后端接口 | 响应时间、吞吐（QPS）、错误率 | 慢请求和错误比平均值更重要 |
| 数据库 | 慢查询数、索引命中、锁等待 | 定位到底慢在查询还是锁 |
| AI 应用 | TTFT（首 token）、总耗时、token/秒 | 延迟 vs 成本要分开看 |
一个提醒：平均值会掩盖问题。P95 慢而 P50 正常，说明是"少数请求特别慢"，优化方向完全不同。
三、定位瓶颈：沿着调用链分层
定位 = 找到"耗时/资源消耗最大的一环"。通用做法是分层打点：
text
用户操作 → 前端渲染 → 网络传输 → 网关/负载 → 应用处理 → 数据库/外部服务
每层测耗时，占比最大的那层就是瓶颈| 层 | 定位工具 | 相关文章 |
|---|---|---|
| 前端渲染 | Performance 面板、DevTools | A25 |
| 网络传输 | 网络面板、抓包 | N11 |
| 后端处理 | 日志、APM、profiler | C08、C07 |
| 数据库 | 慢查询日志、EXPLAIN | DB02 |
二分法在这里同样适用：在调用链中间测一层，看耗时偏向哪边，再往那边深入。
四、优化策略：按"投入产出"排序
定位到瓶颈后，按性价比从高到低选：
| 策略 | 例子 | 代价 |
|---|---|---|
| 去掉不必要的工作 | 砍掉无用请求、减少重复渲染 | 低 |
| 缓存 | HTTP 缓存、Redis、内存缓存 | 中 |
| 并发/并行 | 请求并行、异步化、多线程 | 中 |
| 算法/结构优化 | 索引、更优数据结构、分页 | 中高 |
| 资源升级 | 加机器、扩容 | 高（且治标） |
顺序经验：先做"去掉不必要的工作"，再做"缓存"，最后才考虑"加资源"。加资源只是把问题藏起来。
五、回归防线：优化完怎么证明"没白做、没回退"
优化完成不等于结束，要有回归防线：
- 优化前记录基线（同样的指标、同样的环境、同样的数据）
- 优化后用同一基线复测，量化提升
- 防回退：把关键指标接进 CI/监控，指标退化自动告警
| 误区 | 对策 |
|---|---|
| 优化完看一次"感觉快了" | 用同一基线量化对比 |
| 只优化不设监控 | 关键指标接告警，防止下次改坏 |
| 为性能牺牲正确性 | 先保正确性，性能是可验证的增量 |
六、跨端性能优化对照
| 场景 | 前端 | 后端 | AI |
|---|---|---|---|
| 慢 | 渲染/资源加载 | 查询/连接池/线程 | 模型推理/网络/TTFB |
| 量级增长 | 包体积、列表长度 | QPS、连接数 | token 数、并发请求 |
| 典型误判 | "动画卡"其实是主线程被占 | "接口慢"其实是慢查询 | "AI 慢"其实是排队或重试 |
AI 性能多一层成本维度：同样的准确率，用更小模型、更少 token、带缓存，可能是最大且最划算的"优化"。
自检清单
- [ ] 优化前先测量，且有明确的指标（含 P95，不只平均值）
- [ ] 能沿调用链分层定位，找到耗时占比最大的瓶颈
- [ ] 优化策略按"去冗余 → 缓存 → 并发 → 算法 → 资源"排序
- [ ] 优化前后用同一基线量化对比，能说清提升多少
- [ ] 关键指标已接进监控/CI，能防回退
- [ ] 不为性能牺牲正确性
常见误区
| 误区 | 事实 |
|---|---|
| "先优化再说" | 不测量就优化，多半在优化非瓶颈 |
| "平均值不慢就没事" | P95 慢说明少数请求有大问题 |
| "加机器万能" | 加资源治标不治本，先做减法与缓存 |
| "优化完就完了" | 没有回归防线，下次改一行就白费 |
动手练习
练习 A：做一次完整闭环
挑一个"觉得慢"的页面/接口，走完"定指标 → 测量 → 定位 → 优化 → 回归"，输出一份含基线数字的记录。
练习 B：拆一次假优化
找一段"凭感觉优化"的代码（网上很多），用本文框架分析：它没有测量什么？可能的真正瓶颈是什么？
练习 C：设回归告警
把练习 A 的关键指标配进 CI/监控，验证"指标退化能告警"，并写下阈值和触发条件。
相关文档
本区
- 05 · 调试方法论 —— 性能定位的通用排障技巧
- 01 · 工程方法论全景 —— 闭环定位
其他域
- A25 · 前端性能度量与诊断 —— 前端指标与诊断
- C07 · 服务端性能与容量 —— 后端性能与容量
- DB02 · 索引原理与优化 —— 数据库层优化
- G13 · 成本与模型路由 —— AI 成本与性能的平衡