性能优化助手

它解决什么问题

线上服务变慢时，最常见的错误是凭直觉加缓存、拆服务或换数据库。没有测量，这些改动通常只带来心理安慰，也可能引入新的复杂度。性能问题还经常出现在“看起来没问题”的位置：一次渲染阻塞、一个 N+1 查询、连接池配置偏小，或是锁竞争让 CPU 看起来并不忙。

性能优化助手 不替代监控和 profiling 工具，它提供一套可重复的排查路径：先明确优化目标和场景边界，再用 profiling 数据定位 CPU、IO 或锁竞争，随后按前端、后端两条线逐项检查，最后通过压测建立基线并量化收益。

它如何工作

核心能力围绕一个朴素流程展开：

• 先测量，再优化：从 profiling、trace、日志或压测结果中寻找真正的瓶颈，而不是从代码注释里猜测。
• 按层级拆解：区分 CPU 密集、IO 等待、锁竞争和资源竞争，避免把所有问题归因于“接口慢”。
• 前端与后端分别处理：前端关注渲染、打包拆分和缓存策略；后端关注慢查询、N+1、连接池和异步化。

推荐的工作步骤如下：

1. 明确目标：是缩短 P99、降低资源占用，还是提高吞吐；同时确认可接受的回归范围和停机窗口。
2. 复现并采集数据：在测试环境或灰度阶段使用 profiling 工具，记录 CPU、内存、IO、锁等待和请求耗时。
3. 逐项定位：先判断瓶颈是 CPU、IO 还是锁竞争；前端检查渲染与资源加载，后端检查查询、连接和并发模型。
4. 小步改动并对比：每次只调整一个变量，通过压测结果确认收益，而不是把多个猜测混在一起上线。
5. 输出结构化结论：整理成检查清单、问题分级和后续建议，同时保留不确定项。

关键步骤示例

• 前端：用浏览器 trace 找长任务，检查阻塞渲染的脚本，评估代码分割与缓存失效策略。
• 后端：从慢日志和 trace 中定位高频查询，识别 N+1 调用，确认连接池是否成为排队点。
• 对比：为关键接口建立基线，记录优化前后的 P50、P99、吞吐和错误率。

适用边界与注意点

适合在需要结构化方法论和检查清单时使用：性能优化、profiling、前端优化、后端调优、压测和瓶颈定位都在此范围内。

不适合以下场景：

• 需要实时数据、自动连接外部系统或持续在线巡检的任务。
• 必须由持牌专业人士出具确定性结论的领域，例如法律、医疗或财税。

核心红线只有一条：优化必须以测量为准。任何无法通过 profiling、日志或压测验证的改动，都应被视为高风险变更。对工具输出中不确定的指标和结论，需要工程师在真实环境中复核后再落地。