ttfb是衡量服务器响应能力的核心指标，理想值200–250ms，超过500ms需干预；其延迟源于服务端处理逻辑、数据库慢查询、资源瓶颈或调用链路阻塞，须按“确认存在→定位环节→聚焦组件”顺序排查。
Web 响应延迟不是单一环节的问题，而是请求从浏览器发出后，在整个链路上逐层累积耗时的结果。要真正解决问题，必须按顺序排查：先确认延迟是否真实存在、再锁定慢在哪个环节、最后聚焦到具体组件。重点不在“测得快”，而在“判得准”。
看 TTFB 定性：服务器响应是否真慢
TTFB（Time to First Byte）是衡量 Web 服务器处理能力的核心指标——它指浏览器发出请求到收到第一个字节的时间，完全排除了网络传输和前端渲染的影响。
- 理想值：200–250ms；超过 500ms 就需干预
- TTFB 高 ≠ 网络差：如果本地 ping 服务器延迟低（如
- 验证方式：用 curl -w "@format.txt" -o /dev/null -s "https://yoursite.com/api/test"，其中 format.txt 包含 %{time_starttransfer}，直接提取 TTFB 值
查服务端资源：CPU、内存、I/O 是否已告急
服务器是请求处理的“第一现场”，资源瓶颈会直接拖慢所有请求。
- CPU 使用率持续 >80%：说明计算密集型任务（如未优化的算法、频繁 GC、线程争抢）已饱和
- 空闲内存
- 磁盘 I/O wait % 高（top 中 wa 列 >30%）：常见于日志刷盘频繁、数据库写入压力大、临时表大量生成
- 建议搭配监控工具（如 Prometheus + Node Exporter）持续采集，避免只看瞬时快照
盯数据库层：慢查询、连接池、索引缺一不可
多数 Web 延迟最终都归结到数据库——哪怕接口逻辑简单，一次没走索引的查询就可能让响应从 50ms 拉长到 2s。
- 开启慢查询日志（MySQL 设置 long_query_time=0.5），定期扫描执行超 500ms 的 SQL
- 对慢 SQL 执行 EXPLAIN，重点关注 type（是否全表扫描）、key（是否命中索引）、rows（扫描行数）、Extra（是否有 Using filesort / Using temporary）
- 检查连接池状态：若活跃连接数长期接近最大值（如 HikariCP 中 active == maximum），说明数据库处理不过来，要么优化 SQL，要么扩容连接池或数据库实例
- 警惕“隐性慢操作”：如事务中嵌套循环查库、N+1 查询、未加 limit 的分页偏移量过大（OFFSET 100000 LIMIT 20）
验调用链路：用追踪工具看清每一毫秒花在哪
光看平均值会掩盖问题。一个接口平均响应 800ms，可能是 90% 请求 200ms，10% 请求卡在数据库锁上长达 5s——这只能靠分布式链路追踪发现。
- 接入 SkyWalking 或 Zipkin，查看单次请求的完整调用栈，定位耗时最高的 span（比如某个 DAO 方法耗时 4.2s）
- 关注跨服务调用：上游服务响应慢、下游服务超时重试、HTTP 客户端未设合理 timeout，都会层层放大延迟
- 对比不同环境：开发/测试环境响应快，生产慢？大概率是数据量、索引、连接池配置或 JVM 参数不一致
