展开知识库目录
性能变慢先测哪里：浏览器、接口、数据库还是外部依赖
用户感到慢可能来自浏览器渲染、网络、应用排队、数据库或外部依赖。
性能问题先量端到端时间
用户感到慢可能来自浏览器渲染、网络、应用排队、数据库或外部依赖。先记录同一请求在各层的时间，再优化占比最大的真实瓶颈。
首屏和交互慢
常见原因：资源体积、主线程长任务、布局、图片或客户端数据处理。
处理方法：用浏览器性能和网络面板测加载、渲染与交互，建立真实设备基线。
把涉及的文件、目录、版本、命令和实际输出写进记录；代码变化同时保留 diff 与测试结果。
只有实际现象和证据与这一分支吻合时才执行处理；不吻合就继续检查下一层。
接口本身慢
常见原因：应用计算、锁、排队、序列化或下游调用占用时间。
处理方法：加入分段耗时和请求关联，比较成功与慢请求，不只看平均值。
确认“接口本身慢”已经有可回查结果，再进入“数据库耗时高”；依据仍然来自猜测时，把缺口单列并停在当前步骤。
只有实际现象和证据与这一分支吻合时才执行处理；不吻合就继续检查下一层。
数据库耗时高
常见原因：慢查询、缺索引、错误基数、N+1、锁或连接池。
处理方法：保存查询计划、扫描行、等待和数据量，在副本或安全环境验证索引与改写。
确认“数据库耗时高”已经有可回查结果，再进入“外部依赖波动”；依据仍然来自猜测时，把缺口单列并停在当前步骤。
只有实际现象和证据与这一分支吻合时才执行处理；不吻合就继续检查下一层。
外部依赖波动
常见原因：上游延迟、限流、DNS、连接复用或超时重试放大。
处理方法：单独统计依赖耗时和状态，设置合理超时、缓存、降级与重试上限。
需要修改时先限定文件和行为范围，无法说明回滚方式或影响面的动作先不执行。 完成后把证据归入“基准数据与瓶颈定位表”。
只有实际现象和证据与这一分支吻合时才执行处理；不吻合就继续检查下一层。
优化前后使用同一基准
固定数据量、环境、请求和并发，比较中位数与高分位、错误率和资源。只改善一次本地运行或平均值，不足以证明用户体验变好。