前端可纯靠浏览器原生能力实现接口全链路耗时追踪：通过performance api获取dns、tcp、ttfb等阶段耗时，统一请求入口注入traceid并记录时间戳，劫持xhr/fetch全局监听，内存聚合p50/p90等指标并按条件上报。
在前端实现接口请求的全链路耗时追踪，核心是**捕获请求发起、网络传输、服务端处理、响应解析各阶段的时间点，并聚合分析**。不依赖后端埋点或 APM 工具（如 SkyWalking），纯前端也能做到可观测——关键在于利用浏览器原生能力（Performance API、fetch拦截、XMLHttpRequest 重写）和合理的数据采集策略。
用 Performance API 获取真实网络与资源耗时
现代浏览器的 performance.getEntriesByType('resource') 可以拿到每个 fetch/XHR 请求的详细性能数据，包含 DNS 查询、TCP 连接、SSL 协商、请求发送、等待响应、接收响应等细分阶段（符合 W3C Navigation Timing 和 Resource Timing 规范）。
- 只对目标接口 URL 做过滤（例如匹配
/api/或具体路径），避免采集静态资源干扰 - 注意：需服务端响应头包含
Timing-Allow-Origin: *（或指定域名），否则部分字段（如connectStart、responseEnd）会被浏览器屏蔽为 0 - 示例代码：
if (entry) {
console.log('DNS:', entry.domainLookupEnd - entry.domainLookupStart);
console.log('TCP:', entry.connectEnd - entry.connectStart);
console.log('TTFB:', entry.responseStart - entry.requestStart);
console.log('Download:', entry.responseEnd - entry.responseStart);
}
统一请求入口拦截，注入 traceId 与时间戳
所有请求应经过统一封装（如自定义 request() 函数），避免手动调用 fetch 或 XHR 导致漏埋点。
- 生成唯一
traceId（如Date.now() + Math.random().toString(36).substr(2, 9)），通过请求头（如X-Trace-ID）透传给后端，便于前后端日志串联 - 在请求发起前记录
start = performance.now()；在then或catch中记录end = performance.now()，计算总耗时 - 捕获异常、HTTP 状态码、响应大小等上下文，一并上报
增强 XHR 和 fetch 的全局监听（兼容旧项目）
若无法改造全部请求调用点，可采用“猴子补丁”方式劫持原生方法：
-
XMLHttpRequest：重写
open和send方法，在open存储 URL 和起始时间，在load/error回调中计算耗时并上报 -
fetch：用
window.fetch = new Proxy(fetch, { apply })包装，拦截参数与 Promise 结果 - 注意避免重复拦截（如已被其他 SDK 劫持）、防止影响原有逻辑（保留原始
this和参数）
聚合上报与轻量分析（无需后端存储）
前端可做初步统计，降低上报压力：
- 内存中维护一个 Map，按接口路径分组，记录最近 100 次的耗时、状态码、错误率
- 计算 P50/P90/P99、平均值、最大值，并识别慢请求（如 > 2s）自动触发详情快照（包括 request headers、stack trace、performance entry）
- 用户主动触发（如长按页面 3 秒）或满足条件（连续 3 次超时）时，将聚合数据 + 当前 performance.memory + navigator.userAgent 打包上报到日志服务
不复杂但容易忽略的是时间精度与跨域限制——优先用 performance.now() 而非 Date.now()，严格校验 Timing-Allow-Origin 头。只要统一入口 + Performance API + 合理采样，就能低成本构建出有业务意义的前端接口耗时视图。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
