Go ResponseController 启用全双工后怎么同时读请求和写响应

如果 Go 的 HTTP 处理器需要一边接收较大的请求体，一边把已经处理的结果持续写回客户端，关键不是简单地先调用 Write，而是先让服务器知道这个处理器要采用全双工读写。对 HTTP/1 请求，调用 http.NewResponseController(w).EnableFullDuplex() 后，处理器才可以在读取 Request.Body 的同时继续写入 ResponseWriter；HTTP/2 本身允许并发读取和响应。

官方地址：https://pkg.go.dev/net/http#ResponseController.EnableFullDuplex

实用顺序是：进入 Handler 后先创建 ResponseController 并处理错误，再按块读取请求体、处理当前块、写出当前结果；需要尽快送达客户端时再调用 Flush。这个能力只解决 HTTP 请求体与响应体的读写关系，不等于 WebSocket 协议升级。

为什么 HTTP/1 要显式开启全双工

Go 的 HTTP/1 服务器默认会在开始写响应前消费请求体中尚未读取的部分。这样做适合普通“读完请求再返回结果”的接口，却不适合上传流、边接收边转换或增量反馈场景。EnableFullDuplex 会关闭这段默认行为，让处理器继续读取请求体，同时向响应写入已经准备好的内容。

HTTP/2 的服务器行为不同：官方文档说明 HTTP/2 始终允许并发读取请求和写响应。不过业务代码仍要考虑客户端兼容性、响应头发送时机和错误收口，不能因为协议允许就忽略处理器的资源边界。

先在原始 ResponseWriter 上处理能力开关

NewResponseController 最好接收传给 ServeHTTP 的原始 ResponseWriter，或者接收一个能通过 Unwrap 返回原始 writer 的包装器。创建控制器后，先检查 EnableFullDuplex 的错误，再设置响应头或写响应正文。若底层 writer 不支持该方法，返回的错误会匹配 http.ErrNotSupported，此时应走明确的降级或错误响应。

package main

import (
    "errors"
    "io"
    "net/http"
)

func streamHandler(w http.ResponseWriter, r *http.Request) {
    controller := http.NewResponseController(w)
    if err := controller.EnableFullDuplex(); err != nil {
        // 不支持全双工时先返回错误，避免继续写出不符合预期的流式响应。
        if errors.Is(err, http.ErrNotSupported) {
            http.Error(w, "full duplex is not supported", http.StatusHTTPVersionNotSupported)
            return
        }
        // 其他控制器错误也要停止当前处理器，避免响应状态继续变化。
        http.Error(w, "cannot enable full duplex", http.StatusInternalServerError)
        return
    }

    // 请求体由当前处理器负责关闭，避免连接资源长期占用。
    defer r.Body.Close()
    w.Header().Set("Content-Type", "text/plain; charset=utf-8")

    buf := make([]byte, 32*1024)
    for {
        n, readErr := r.Body.Read(buf)
        if n > 0 {
            // 先处理当前块，再把结果写回；同一处理器可以继续读取后续块。
            if _, writeErr := w.Write(buf[:n]); writeErr != nil {
                return
            }
            // Flush 只负责尽快推出已写数据，不替代错误处理或协议升级。
            if flushErr := controller.Flush(); flushErr != nil {
                return
            }
        }
        if readErr != nil {
            // EOF 是正常收尾，其他读取错误需要结束本次响应。
            if readErr != io.EOF {
                return
            }
            break
        }
    }
}

示例采用“读取一块、处理一块、写出一块”的交错方式，内存占用由固定缓冲区控制。它不是把整个请求体读入内存，也没有把 WebSocket 的升级语义混进普通 HTTP Handler。

按块读取并把结果写回响应

代码中的关键关系有三层：Handler 持有 ResponseController 和 Request.Body；固定缓冲区承接当前数据块；处理结果再交给 ResponseWriter，必要时用 Flush 推出。图示是静态结构说明，不是本机运行截图。

如果业务处理比读取慢，可以把“处理当前块”的逻辑放到受控的生产者消费者结构中，但要设置取消和背压边界：客户端断开后，写响应通常会返回错误，处理 goroutine 也应随之退出。不要无限制地把读取块塞进无界 channel，否则全双工只会把内存问题转移到队列。

刷新、错误和响应头的门禁

第一，响应头一旦写出，状态码和大部分 Header 就不能再按普通响应修改，因此需要在第一次 Write 或 Flush 前完成必要的 Header 设置。第二，Flush 是尽快发送缓冲数据的能力调用，不代表客户端一定立即渲染，也不代表网络已经成功抵达。第三，读取错误、写入错误和刷新错误都要让当前处理器收口，不能只记录日志后继续使用已经可能失效的 writer。

还要注意控制器和 ResponseWriter 不能在 ServeHTTP 返回后继续使用。请求体关闭、客户端断开和服务端超时是同一条资源链上的不同出口，建议让处理逻辑监听 r.Context().Done()，并为长请求配置合理的读写期限。

上线前用四项检查确认实现

1. 协议检查：确认目标请求是 HTTP/1 还是 HTTP/2，明确是否真的需要显式调用 EnableFullDuplex。
2. 调用检查：控制器在首次写响应前创建，并处理 ErrNotSupported，没有把错误吞掉。
3. 资源检查：请求体会关闭，缓冲区有上限，写入或刷新失败时不会继续生产数据。
4. 客户端检查：流式响应的媒体类型、缓存策略、断开行为和超时设置与客户端实际能力匹配。

归纳起来，EnableFullDuplex 解决的是 HTTP/1 服务器默认“先读完再写”的限制；真正稳定的实现还需要固定块大小、正确的错误出口、明确的响应头时机和可控的取消路径。

相关问题

调用 EnableFullDuplex 后还需要 Flush 吗？需要尽快把已写数据推出时仍可调用 Flush；全双工开关和刷新是两件不同的事。

HTTP/2 下可以不调用这个方法吗？官方文档说明 HTTP/2 服务器始终允许并发读取与响应，但保留统一的错误处理仍有助于确认底层 writer 能力。

这能替代 WebSocket 吗？不能。它只改变 HTTP Handler 对请求体和响应体的读写关系，不提供消息帧、升级握手或长连接协议语义。