当一个 API 从 80ms 涨到 600ms，第一反应通常是“代码变慢了”。
但真实原因可能是数据库、线程池、GC、外部依赖中的任意一个。
我常用的排查顺序
- 先确认是全部接口慢，还是少数接口慢
- 看调用链路，判断慢在应用内部还是下游依赖
- 再看 CPU、内存、GC、线程池是否异常
- 最后回到具体 SQL 或具体代码段做优化
这个顺序能避免“上来就改代码”的无效操作。
三个高价值指标
在 .NET 服务里，这三个指标非常实用：
- P95/P99 延迟
- ThreadPool Queue Length
- Gen2 GC 次数与停顿时间
它们能快速告诉你是排队问题、CPU 问题还是内存回收压力。
优化时的常见误区
误区一：只看平均延迟，不看尾延迟。
误区二：只压测应用，不压测数据库。
误区三：优化前后没有可对比基线。
性能优化一定要“测量 -> 假设 -> 验证 -> 回归”，否则很难复现和复盘。
小结
后端性能并不是“某个神奇参数”的问题，而是系统行为在高负载下的结果。
有一条稳定排查路径，比记一堆优化技巧更重要。