为什么Chrome DevTools网络面板中预检请求有时会显示在主请求之后？

嘿，这个问题挺常见的，我来给你拆解下为啥会出现这种看起来“颠倒”的情况：

1. DevTools默认按「请求完成时间」排序，而非发起时间 #

这是最核心的原因。预检请求（OPTIONS）本身非常轻量——它只需要服务器返回CORS相关的头信息，不需要传输实际业务数据，所以发起早、完成快。而主请求要等预检通过后才会继续处理，再加上可能要传输请求体、等待业务逻辑处理，完成时间会比预检晚很多。

Chrome DevTools的网络面板默认是按「请求完成的时间」来排序的，所以完成得早的预检请求就排在了完成得晚的主请求后面。你可以试试点击网络面板顶部的「开始时间（Start Time）」列，切换成按发起时间排序，这时候预检请求就会乖乖出现在主请求前面了。

2. 请求分组可能让你产生“顺序颠倒”的错觉 #

如果你开启了DevTools的「分组相似请求」功能（在网络面板的设置菜单里），Chrome会把相关的请求归为一组——比如同一个XHR/fetch对应的预检和主请求会被放在同一个组里。这时候主请求可能作为组的标题显示在列表前面，预检请求被折叠在组内，你需要展开主请求的分组才能看到它。这种情况下看起来像是预检在主请求后面，但实际上它是组内的子请求，发起顺序依然是预检在前。

3. 极端罕见的延迟情况 #

极少数情况下，可能因为浏览器的网络队列调度优先级、或者服务器端对OPTIONS请求的处理意外延迟，导致预检请求的响应返回比主请求还晚——不过这种情况非常少见，大部分时候还是前两个原因导致的。

总结一下，99%的场景都是排序逻辑的问题，调整下排序方式就能看到真实的请求发起顺序啦。

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