Go http.ResponseController 怎么控制响应：Flush、Hijack 与超时边界

写流式响应或长连接处理器时，直接把 http.ResponseWriter 强转成某个具体接口，代码很快就会被 HTTP/1、HTTP/2 和中间件包装层的差异牵着走。Go 1.20 提供的 http.ResponseController 把这些扩展能力收进一个入口：需要刷新缓冲区时调用 Flush，需要接管连接时调用 Hijack，需要限制请求或响应时间时设置对应 deadline。

ResponseController 解决的是哪一层的不便

ResponseWriter 的基础接口只保证写响应所需的方法。以前要刷新缓冲区，通常要断言 http.Flusher；要接管连接，则要断言 http.Hijacker。这种写法既依赖具体实现，也容易在经过日志、压缩或鉴权中间件后失效。

http.NewResponseController(w) 不会凭空创造底层能力。它会沿着 writer 的支持接口调用对应方法；如果包装器提供了 Unwrap，还可以继续找到原始 writer。这个细节决定了它适合做统一入口，但不代表每个响应都支持所有操作。

先用 Flush 做一个最小流式响应

下面的处理器每隔一小段时间写一行状态，并主动把缓冲内容推给客户端。示例只演示控制点，生产代码还应根据客户端断开情况停止工作。

func stream(w http.ResponseWriter, r *http.Request) {
    controller := http.NewResponseController(w)
    w.Header().Set("Content-Type", "text/plain; charset=utf-8")

    for i := 1; i 

这里的核对点不是“调用了 Flush 就一定实时到达”。代理缓冲、客户端读取方式和传输协议仍会影响可见时间；Flush 只负责把服务端当前可刷新的数据交给底层响应实现。

读写 deadline 的边界要分开理解

SetReadDeadline 约束读取整个请求（包括请求体），SetWriteDeadline 约束写响应。两者都接受一个绝对时间，传入零值表示取消 deadline。deadline 已经过期后再设置一个新的时间，并不等于所有底层状态都能无条件恢复，所以不要用它替代请求级取消和连接生命周期管理。

func bounded(w http.ResponseWriter, r *http.Request) {
    controller := http.NewResponseController(w)
    deadline := time.Now().Add(2 * time.Second)

    if err := controller.SetReadDeadline(deadline); err != nil {
        if errors.Is(err, http.ErrNotSupported) {
            http.Error(w, "read deadline is unavailable", http.StatusNotImplemented)
            return
        }
    }
    if err := controller.SetWriteDeadline(deadline); err != nil {
        if errors.Is(err, http.ErrNotSupported) {
            http.Error(w, "write deadline is unavailable", http.StatusNotImplemented)
            return
        }
    }
    _, _ = io.Copy(io.Discard, r.Body)
    _, _ = io.WriteString(w, "checked\n")
}

不要把读超时和写超时混成一个“请求超时”。上传慢通常先触发读边界；下游客户端不消费响应时，写 deadline 才更相关。真正需要统一取消时，仍应配合 r.Context()。

Hijack 成功后，责任会转移给谁

controller.Hijack() 返回 net.Conn 和一个带缓冲的读写器。成功后，HTTP server 不会继续替 handler 管理这条连接；原始 Request.Body 也不能再继续使用。这个调用更像一次明确的所有权转移，而不是“拿到一个更底层的 writer”。

因此，接管后至少要有三个动作：处理已经缓冲的数据，设置或清理连接 deadline，最终关闭连接。缺一个都可能留下半开的连接或让后续协议解析读到旧缓冲。

func raw(w http.ResponseWriter, r *http.Request) {
    controller := http.NewResponseController(w)
    conn, rw, err := controller.Hijack()
    if err != nil {
        if errors.Is(err, http.ErrNotSupported) {
            http.Error(w, "hijack is not supported", http.StatusNotImplemented)
        }
        return
    }
    defer conn.Close()

    _ = conn.SetDeadline(time.Now().Add(5 * time.Second))
    _, _ = rw.WriteString("HTTP/1.1 200 OK\r\nContent-Length: 6\r\n\r\nhello\n")
    _ = rw.Flush()
}

这段代码只适合说明连接责任。它不应被直接扩展成自定义协议服务：正式协议还需要处理并发读写、半关闭、客户端提前断开和完整的错误回收。

中间件包装和 HTTP/2 是两个兼容检查点

如果中间件把 writer 包成了自定义类型，优先让它实现返回原始 writer 的 Unwrap 方法，再把包装后的 writer 交给 NewResponseController。不要在业务 handler 里假设某个框架私有类型一定实现了 Flusher 或 Hijacker。

另一个边界是协议。Hijack 依赖底层实现，不能把“HTTP/2 请求上的任意响应都可以接管”当成前提；不支持时应按能力协商失败处理。对流式输出来说，先验证目标服务器、反向代理和客户端是否保留分块/流式行为，再决定是否把 Flush 纳入产品协议。

常见问题：ResponseController 的复查方法

为什么 Flush 返回 ErrNotSupported？

底层 writer 没有提供刷新能力，或者包装层没有正确暴露原始 writer。用 errors.Is 判断 http.ErrNotSupported，记录实际响应链，而不是重复调用。

Hijack 后还能写 ResponseWriter 吗？

不应继续使用原来的 HTTP 响应流程。连接已经交给 handler，后续读写应使用返回的 net.Conn 或 bufio.ReadWriter，并由 handler 负责关闭。

设置 write deadline 能取消 handler 吗？

不能。它限制写入行为，不会自动终止所有业务计算。耗时工作仍应监听请求 context，并在客户端断开或 deadline 错误时及时退出。

小结

ResponseController 的价值是把响应扩展能力放在一个标准入口里，但它不改变底层能力和协议边界。先用 Flush 解决明确的流式需求，再分别配置读写 deadline；只有确实需要接管连接时才使用 Hijack，并把连接的完整生命周期写进代码和测试。