浏览器AbortController中止的HTTP请求能否被Go后端Context识别？

核心差异：浏览器与终端工具的请求取消行为 #

当你用axios调用abort()时，浏览器的处理逻辑和curl/Postman完全不同：

• curl/Postman取消：按下Ctrl+C或手动终止时，客户端会主动发送TCP FIN/RST包直接断开与后端的连接。Go的HTTP服务器会立刻检测到连接中断，自动取消该请求对应的context.Context，触发ctx.Done()，所以日志会输出error: timeout: context canceled。
• 浏览器axios abort：浏览器的AbortController终止请求时，只是本地终止请求的处理流程，不会主动发送TCP断开信号。它可能会发送Connection: close头，但更多时候是直接丢弃后续响应，后端的TCP连接仍处于空闲状态。Go的HTTP服务器只有在连接超时（默认的IdleTimeout）后才会回收上下文，这时候请求大概率已经执行完成了，自然不会触发ctx.Done()。

为什么Go后端用ctx.Done()捕获不到浏览器的abort？ #

Go的net/http服务器中，请求的context取消触发条件只有几种：

1. 客户端主动断开TCP连接（如curl Ctrl+C）
2. 后端设置的ReadTimeout/WriteTimeout触发
3. 后端代码手动调用cancel()函数
4. HTTP/2协议下客户端发送RST_STREAM帧

浏览器的axios abort不属于上述任何一种（除非用HTTP/2），所以后端的ctx.Done()不会被触发。

可行的解决方案 #

1. 引入请求ID+主动取消机制 #

• 前端每次发起请求时生成唯一request-id，放在请求头或参数中
• 后端维护一个全局映射（比如sync.Map），存储request-id到context.CancelFunc的关联
• 前端调用abort()时，额外发送一个POST /api/cancel/{request-id}请求
• 后端收到取消请求后，从映射中取出对应的CancelFunc并调用，主动触发ctx.Done()

2. 启用HTTP/2协议 #

HTTP/2原生支持流的主动取消，浏览器调用abort()时会发送RST_STREAM帧，Go的HTTP/2服务器能识别该帧并自动取消请求上下文。你只需要给Go服务配置HTTPS证书（HTTP/2默认基于HTTPS），即可启用该特性。

3. 缩短后端连接超时时间 #

在Go的http.Server中设置较短的ReadTimeout和WriteTimeout，比如：

srv := &http.Server{
    Addr:         ":8080",
    ReadTimeout:  5 * time.Second,
    WriteTimeout: 10 * time.Second,
    IdleTimeout:  15 * time.Second,
}

这样当浏览器终止请求后，后端连接会很快因超时被回收，ctx.Done()会被触发（不过这只能在请求未执行完时生效，如果请求已经执行到业务逻辑阶段，还是需要主动检查ctx.Done()）。

4. 业务逻辑中定期检查ctx.Done() #

在后端的耗时业务逻辑中，主动插入ctx.Done()的检查，比如：

func handleRequest(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    for i := 0; i < 10; i++ {
        select {
        case <-ctx.Done():
            log.Println("request canceled:", ctx.Err())
            return
        default:
            // 执行单次业务步骤
            time.Sleep(1 * time.Second)
        }
    }
    w.Write([]byte("success"))
}

结合前面的超时设置，能尽可能早地终止已被前端取消的请求。

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