上周帮朋友排查一个订单超时问题，后端接口在测试环境跑得飞快，一上生产就卡顿明显。最后发现是某个第三方支付回调接口平均响应从 80ms 涨到了 1.2s，但没人日常盯着——这事提醒我：光靠日志和肉眼观察，真不够。
为什么光看日志不行？
日志里可能只记了「请求完成」，却没精确到毫秒级耗时；有些框架默认不打耗时字段，或者只在 error 级别才记录慢请求。更麻烦的是，真实用户网络、并发量、参数组合，测试环境根本模拟不来。
几个顺手的响应时间测试工具
curl + time（命令行党最爱）
不用装新工具，Linux/macOS 自带，适合快速验证单次请求：
time curl -s -o /dev/null -w "%{http_code}\n%{time_total}\n" https://api.tiantianshun.com/v1/order/status?id=12345输出类似：
200
0.427
说明 HTTP 状态正常，总耗时 427ms。
Postman 的 Runner + 延迟监控
选中一组接口，点「Runner」批量运行，勾选「Show response latency in summary」，跑完直接看到每个请求的平均响应时间、P95、最大值。还能导出 CSV 对比不同环境数据。
Apache Bench（ab）压测小能手 想看看接口扛不扛得住 50 并发？试试这个： 它会返回「Time per request（mean）」，也就是平均响应时间，还附带失败率、吞吐量，特别适合上线前摸底。 浏览器开发者工具（别小看它） 单次结果容易受网络抖动、服务器瞬时负载影响。我们团队现在固定每天早 9 点、晚 6 点，用脚本自动调用核心接口 10 次，取中位数存进内部监控表。连续三天 TTFB 超过 300ms，自动钉钉告警——比等用户投诉强多了。 工具只是手段，关键是把响应时间当成接口的“血压值”来盯。今天多花两分钟测一测，明天少熬三小时查问题。ab -n 100 -c 50 "https://api.tiantianshun.com/v1/user/profile?uid=67890"
F12 → Network → 刷新页面 → 找到对应 XHR 请求，看「Timing」标签页里的「Waiting (TTFB)」和「Content Download」。很多前端同学就是靠这招揪出后端慢接口的。小建议：别只测一次