JavaScript接口性能监控应优先使用Performance API自动采集网络阶段，辅以User Timing打语义化标记，并通过sendBeacon健壮上报；需过滤无效请求、延迟上报、采样控制及异常兜底。
JavaScript 对接口请求耗时的性能监控，核心是**准确捕获真实网络阶段、排除干扰、适配异步生命周期，并可持续上报**。不推荐手动用 Date.now() 埋点，而应优先依赖浏览器原生能力，再辅以语义化打点和健壮上报策略。
用 Performance API 自动采集完整网络阶段
现代浏览器对每个 fetch / XHR 请求都会自动记录资源性能条目（需同源或服务端返回 Timing-Allow-Origin 头）。这是最准、最轻、无需改业务代码的方式：
-
获取全部 fetch 请求耗时：调用
performance.getEntriesByType('resource')，筛选initiatorType === 'fetch'且name为 URL 的条目 -
关键阶段拆解（单位毫秒）：
-
duration：总耗时（发起 → 响应体接收完毕） -
responseStart - requestStart：TTFB（含网络传输 + 服务端处理） -
connectEnd - connectStart：TCP+TLS 建连时间 -
responseEnd - responseStart：响应体下载时间
-
-
监听新增资源：用
PerformanceObserver实时捕获，避免轮询
用 mark / measure 打业务语义化节点
当需要衡量“从用户点击到数据渲染完成”这类跨异步环节的端到端耗时，仅靠 resource timing 不够——它不包含 JS 解析、模板渲染等阶段。此时应结合 User Timing API：
- 在业务起点打标记：
performance.mark('api-start-cart-submit') - 在最终 DOM 更新后打终点：
performance.mark('api-end-cart-submit') - 关联测量：
performance.measure('cart-submit-total', 'api-start-cart-submit', 'api-end-cart-submit') - 确保唯一性：避免重复名覆盖，建议加 traceId 或时间戳后缀，如
'api-start-cart-submit-1744632985201' - 异常兜底：用
try/finally包裹异步链，保证终点标记必执行
手动埋点需注意的边界与兼容性
若需兼容 IE 或拦截所有请求（包括被缓存、重定向、CORS 受限的），可封装 fetch / axios 拦截器，但必须规避常见陷阱：
立即学习“Java免费学习笔记（深入）”；
-
过滤无效请求：跳过
status === 0（取消、跨域无 timing）、redirectCount > 0（重定向干扰 TTFB）、duration === 0 && responseEnd === 0（缓存命中） -
延迟上报：用
requestIdleCallback或setTimeout(..., 0)避免阻塞主线程 - 采样控制：高频接口只上报 P95+ 耗时或错误请求，降低性能开销
- 失败兜底：Promise reject 时也记录耗时（从 start 到 reject 时间），体现“不可用”也是一种性能指标
日志结构与上报要点
单条请求监控数据至少包含以下字段，便于聚合分析与链路对齐：
-
url：标准化后的请求地址（去参、脱敏） -
traceId：透传至后端，用于全链路追踪 -
duration、ttfb、download等分段耗时（单位 ms，保留 1 位小数） -
status：HTTP 状态码；success：布尔值（区分网络失败、超时、业务错误） -
timestamp：用performance.timeOrigin + performance.now()得到绝对毫秒时间戳 - 上报使用
navigator.sendBeacon()，确保页面卸载前也能发出
