通过AbortController中止fetch请求后会发生什么？

以下结论基于Chrome、Firefox、Safari三大主流浏览器的默认实现逻辑，DOM标准仅定义上层API的公开行为，底层实现属于浏览器自主优化范畴。

1. HTTP请求的终止逻辑 #

调用abort()后，上层fetch返回的Promise会立刻抛出AbortError，JS层不会再收到该请求的任何后续数据。
底层收发逻辑分场景处理：

• 若请求尚未发出，会直接丢弃请求，无任何网络收发动作
• 若请求体/响应体尚未传输完成：
  • 上层内容传递会立刻终止，剩余数据不会传递到JS上下文
  • 底层是否继续完成收发取决于浏览器的连接复用策略：如果判断保留当前TCP连接收益更高，会静默接收完剩余响应数据并丢弃，不会让不完整的响应影响后续请求；如果判断无复用价值，会直接终止收发。

2. TCP连接的处理逻辑 & 使用建议 #

正常情况下，中止单个fetch请求不会直接终止底层TCP连接，仅在响应体过大、浏览器判断接收剩余内容的成本高于新建连接时，才会主动关闭连接：

• 若主动关闭连接，默认走标准TCP四次挥手流程，仅在连接异常等极端场景下才会发送RESET包强制中断。
• 搜索框自动补全等高频取消请求的场景仍然鼓励使用AbortController：
  上层可以直接过滤无效响应，避免无用的JS逻辑执行和内存占用，同时减少后续请求的排队阻塞；即使HTTP/1.1场景下有极少量的底层冗余收发，带来的用户体验提升远大于额外开销，HTTP/2/QUIC场景下几乎无额外性能损耗。

3. 连接复用的恢复机制 #

不同HTTP协议有对应的处理逻辑：

• HTTP/1.1：如果要保留连接复用，浏览器会静默读取完当前请求的所有剩余响应数据，清空连接缓冲区后将连接放回连接池，后续请求可以正常复用；如果剩余数据量过大，浏览器会主动关闭连接，下次请求重新建立TCP连接即可。
• HTTP/2：原生支持多路复用，单个请求对应独立的流，中止请求时只需发送RST_STREAM帧重置对应流即可，双方直接释放该流的资源，不会影响同连接上的其他流，也不需要清空连接缓冲区，连接可直接复用。
• QUIC：逻辑和HTTP/2类似，通过RESET_STREAM帧重置对应独立流，流的创建和销毁成本远低于TCP连接，中止开销极低。

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