真实接口响应时间需用performance.now()在请求前和响应体完全接收后计时，禁用连接复用，并通过至少100次连续请求计算p95，避免vscode调试干扰。
不能只靠 console.time() 看接口响应时间——它测的是 JS 执行耗时，不是真实网络请求往返（RTT）或服务端处理时间。 真实接口响应时间必须从请求发起前开始计时、到响应体完全接收后结束，且需排除 Node.js 启动开销、连接复用、DNS 缓存等干扰。
用 performance.now() 替代 console.time() 获取亚毫秒级精度
在 Node.js 环境中，console.time() 受控制台 I/O 和事件循环调度影响，实际误差常达 0.5–2ms；而 performance.now() 基于高精度单调时钟，返回 number 类型（单位：毫秒，小数点后 3 位），适合测量短时操作：
- 必须在
http.request()或fetch()调用前立即调用，不能放在回调/async 函数外层 - 结束时间点应取
res.on('end', ...)或await res.text()之后，确保响应体完整读取 - 避免在
setTimeout或setImmediate中启动计时，会引入调度延迟
示例（使用原生 fetch）：
const start = performance.now();
const res = await fetch('http://localhost:3000/api/users');
const body = await res.text(); // 确保响应流消费完毕
const end = performance.now();
console.log(`接口耗时: ${(end - start).toFixed(3)}ms`);
绕过连接池复用，隔离单次请求的网络开销
默认 fetch 或 http 模块会复用 TCP 连接（keep-alive），导致第二次请求跳过 TCP 握手+TLS 协商，测出的时间严重偏低。要获得单次请求的真实 RTT，需强制禁用复用：
- 对
fetch：传入{ headers: { 'Connection': 'close' } } - 对
http.request()：设置agent: new http.Agent({ keepAlive: false }) - 若服务端不支持
Connection: close，可在本地 hosts 绑定一个唯一子域（如test123.local），每次请求换域名，绕过 socket 复用
注意：禁用复用后，平均耗时会上升 3–15ms（取决于网络环境），但这才是你要的真实基线值。
在 VSCode 调试会话中稳定捕获时间，避开 DevTools 注入干扰
VSCode 的调试器会在 Node.js 进程中注入额外逻辑（如断点监听、变量快照），可能拖慢 I/O 操作。若你在 F5 启动的调试模式下测出异常高延迟，先确认是否启用了以下配置：
-
"skipFiles": ["<node_internals>/**"]</node_internals>必须存在，否则 V8 内部函数调用会被计入耗时 - 禁用所有非必要扩展（尤其“REST Client”、“Thunder Client”类插件），它们可能劫持 HTTP 请求
- 不要在
launch.json中启用"trace": true或"outputCapture": "std"，这些会显著增加日志写入开销
更稳妥的做法：在终端中用 node --inspect-brk script.js 启动，再用 Chrome DevTools 连接测量，VSCode 仅作代码编辑器使用。
为什么你测的“P95 响应时间”总比压测工具低？
因为你在 VSCode 里单次手动运行，没模拟并发。真实 P95 是指 95% 的请求响应 ≤ X ms，而单次测量只是 P100 的一个样本。Node.js 接口响应时间受事件循环阻塞、GC 暂停、磁盘 I/O 竞争等瞬时因素影响极大。要得到可信分位数：
- 至少连续执行 100 次请求（用
for循环 +await，避免 Promise.all 并发干扰） - 剔除首 5 次（预热期）和末 5 次（GC 高峰期）数据
- 用
Array.sort()+ 索引取 P95，不要依赖平均值
最易被忽略的一点：Node.js 的 process.hrtime.bigint() 虽然精度达纳秒级，但在 VSCode 调试模式下，其返回值可能被调试器截断或延迟刷新——除非你明确需要 sub-millisecond 级别分析，否则 performance.now() 已足够，且更稳定。
