Chrome DevTools中请求“started at”时间为负值的含义与原因

嘿，这个问题其实挺常见的，很多人刚接触DevTools网络面板时都会对这两个时间指标的逻辑产生误解，我来给你拆解清楚：

先明确两个时间指标的真实含义 #

• Queued：这个时长代表请求从被浏览器调度到实际启动网络请求之间的等待时间。显示为0的话，说明当DevTools捕捉到这个请求时，它已经没有在队列里等待了——要么是直接被调度执行，要么是已经在执行过程中了。
• Started At：这个时间是相对于DevTools开始捕获网络活动的时间线基准点的偏移量，而不是相对于Queued阶段的起始时间。这里的负数绝对不是说请求在队列前就开始执行，而是DevTools时间线的基准设定导致的。

为什么会出现Started At为负数的情况？ #

Chrome DevTools的网络面板时间线，是以它开始捕获网络事件的那一刻作为0点的。但有些请求可能在你打开DevTools之前就已经被浏览器发起了——比如页面加载初期的关键CSS/JS资源，或者是页面后台悄悄发起的请求。当DevTools后来捕获到这些“已经在跑”的请求时，就会把它们的实际启动时间和DevTools开始记录的时间做对比：如果请求启动得更早，就会用负数来表示这个时间差。

举个例子：假设DevTools在单调时间戳10000ms时开始捕获，而某个请求在9846ms就已经启动了，那DevTools就会把这个请求的Started At标记为9846 - 10000 = -154ms，正好和你遇到的情况一致。

关于单调时间戳的补充 #

你提到的**单调时间戳（monotonic timestamp）**是浏览器内部用来精准记录事件先后顺序的核心指标——它从系统启动时开始计时，只会递增，不会因为系统时间调整（比如手动改时间、时区变化）而波动。DevTools在处理请求时间时，就是靠对比请求的实际单调时间和自身捕获启动时的单调时间，来计算出Started At的偏移量的。这也解释了为什么负数只会出现在那些DevTools启动前就发起的请求上。

总结你的误解点 #

你之前误以为Started At是相对于Queued阶段的开始时间，但实际上它的基准是DevTools的捕获起始点。负数只是说明请求启动在DevTools开始记录之前，而不是跳过了队列阶段；Queued时间为0则是因为当DevTools追踪到这个请求时，它已经脱离队列、进入执行状态了。

内容的提问来源于stack exchange，提问作者Suever