Go http.NewResponseController 怎么控制响应刷新：Flusher、Hijacker 与接口探测边界

做流式响应或连接接管时，旧写法经常先对 http.ResponseWriter 做类型断言，再分别处理包装器、HTTP/2 和错误返回。Go 1.20 引入的 http.NewResponseController 把这些能力收到了一个控制器里：需要刷新就调用 Flush，需要接管连接就调用 Hijack，不支持时统一得到可判断的错误。

把 ResponseController 当成能力探测器使用：它能减少断言分支，但不会让 HTTP/2 获得本来就不支持的 Hijack，也不能在处理函数返回后继续操作。

先看一次完整的响应控制路径

下面的示例只保留一个 handler，方便把能力判断和错误分支放在同一处观察。先写入一小段内容，再调用 Flush；如果请求带有 ?raw=1，才尝试调用 Hijack。这两个动作都必须发生在 ServeHTTP 返回之前。

package main

import (
    "bufio"
    "fmt"
    "net"
    "net/http"
    "time"
)

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

    if err := controller.Flush(); err != nil {
        if err == http.ErrNotSupported {
            http.Error(w, "Flush is not supported", http.StatusNotImplemented)
            return
        }
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }

    if r.URL.Query().Get("raw") != "1" {
        return
    }
    conn, bufrw, err := controller.Hijack()
    if err != nil {
        if err == http.ErrNotSupported {
            http.Error(w, "Hijack is not supported", http.StatusNotImplemented)
            return
        }
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
    defer conn.Close()
    writeRaw(conn, bufrw)
}

func writeRaw(conn net.Conn, bufrw *bufio.ReadWriter) {
    _ = conn.SetWriteDeadline(time.Now().Add(2 * time.Second))
    _, _ = bufrw.WriteString("raw connection\n")
    _ = bufrw.Flush()
}

这段代码的关键不是把所有响应都变成流式传输，而是先验证 Flush 的能力，再决定是否继续。即使实现支持 Flush，代理层也可能缓冲响应，所以客户端看到首段文本仍应作为验收信号，而不是性能保证。

用 Flush 验证首段响应是否已经推出

启动服务后，请求不带 raw=1 的地址。服务端在写完 header is ready 后调用 Flush，随后 handler 直接返回。用 curl 观察时，首段文本应先于连接结束出现；如果代码走到 http.ErrNotSupported 分支，则会得到 501，而不是静默假装刷新成功。

go run .
curl -N http://127.0.0.1:8080/

实际接入 gzip、反向代理或自定义 ResponseWriter 时，先确认包装器是否保留 Unwrap。NewResponseController 会沿着可用的原始 writer 寻找 Flush、FlushError 等方法；底层若实现 http.Flusher，控制器才能完成对应调用，找不到时返回 http.ErrNotSupported。

用 Hijack 处理连接接管边界

只有请求明确带 raw=1 时，示例才从 HTTP 响应切换到原始连接。controller.Hijack() 成功后，HTTP server 不再替你管理这条连接，代码必须负责关闭 net.Conn，并通过返回的 *bufio.ReadWriter 完成剩余读写。

curl --http1.1 -N 'http://127.0.0.1:8080/?raw=1'

这里不要把“能调用方法”和“当前连接能接管”混为一谈。Go 官方文档明确说明，默认 HTTP/1.x server writer 通常实现 Hijacker，HTTP/2 则刻意不提供；包装器也可能不支持。因此线上应把 ErrNotSupported 当作正常能力缺失处理，改走普通响应或关闭升级入口。

三个容易踩到的边界

不要在 handler 返回后使用控制器

ResponseController 的生命周期跟随 Handler.ServeHTTP。把它塞进 goroutine，等 handler 返回后再 Flush 或 Hijack，属于生命周期错误；需要异步生产数据时，应让 handler 保持在请求生命周期内，并明确退出和取消策略。

不要为 HTTP/2 强行寻找 Hijacker

HTTP/2 没有 HTTP/1.x 那种连接接管语义。若业务只是发送增量结果，优先保留普通响应和 Flush 路径；若确实需要原始连接，必须在入口约束协议并提供不支持时的替代结果。

不要用一次 Flush 推断端到端实时性

Flush 只表达 server writer 尝试推出缓冲数据。客户端、代理和压缩层仍可能继续聚合。验收时至少分别检查直连、经过代理和启用压缩三种链路。

常见问题：ResponseController 到底替代了什么

它会自动让任何 ResponseWriter 支持 Flush 吗？

不会。它只是统一探测并调用实现提供的能力；不支持时仍返回 http.ErrNotSupported。

Hijack 成功后还能继续用 ResponseWriter 写吗？

不应继续把它当作普通 HTTP writer 使用。接管后应使用返回的 net.Conn 和 *bufio.ReadWriter，并自行处理关闭和超时。

为什么包装器会让能力消失？

包装器如果没有实现对应方法，也没有通过 Unwrap 暴露原始 writer，控制器就无法找到底层能力。把包装器实现和实际协议一起做集成测试，比只测类型断言更可靠。

总结

http.NewResponseController 的价值在于把响应能力判断集中起来：Flush 负责尽早推出已写数据，Hijack 负责在明确支持时移交连接，而 http.ErrNotSupported 让降级路径可测试。真正上线前，重点核对 writer 包装链、HTTP/1.x 与 HTTP/2 的协议差异，以及 handler 的生命周期。