net/http.Hijacker是Go标准库中用于劫持HTTP连接的接口，必须在需绕过HTTP协议栈直接操作底层TCP连接时使用，如WebSocket升级、HTTPS代理隧道、自定义二进制协议等；调用前响应未写出，且HTTP/2环境下不可用。
net/http.Hijacker 是什么，什么时候必须用它
net/http.Hijacker 是 Go 标准库中一个接口，允许你从 http.Server 的正常 HTTP 处理流程中“抢走”底层的 net.Conn。它不是用来做普通 REST API 的——一旦调用 Hijack()，你就不能再写入 http.ResponseWriter，也不能依赖标准的 header、状态码、chunked encoding 等机制。
典型使用场景包括：实现 WebSocket 升级（虽然更推荐用 gorilla/websocket）、自定义二进制协议桥接、长连接隧道、或需要直接读写 TCP 流的代理逻辑。
注意：Hijack() 要求响应尚未写出（即还没调用过 WriteHeader() 或 Write()），否则会返回 http.ErrHijacked 错误。
如何安全调用 Hijack() 并避免 panic
直接对任意 http.ResponseWriter 类型断言 http.Hijacker 可能失败——比如在某些中间件（如 httputil.NewSingleHostReverseProxy）或测试用的 httptest.ResponseRecorder 中，该接口未被实现。
正确做法是先判断再调用：
hj, ok := w.(http.Hijacker)
if !ok {
http.Error(w, "webserver doesn't support hijacking", http.StatusInternalServerError)
return
}
conn, bufrw, err := hj.Hijack()
if err != nil {
log.Printf("Hijack failed: %v", err)
return
}
// 此时 conn 是裸 net.Conn，bufrw 是 *bufio.ReadWriter
// 你必须自己管理读写，且不能复用 w
常见错误：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 忘记检查
ok就直接断言，导致 panic - 调用
Hijack()前已向w写入数据（哪怕只是w.WriteHeader(200)） - 调用后仍尝试用
w.Write()，会触发http.ErrHijacked
接管后怎么读写，为什么必须用 bufrw 而非 conn
Hijack() 返回的 bufrw *bufio.ReadWriter 已预填充了请求 body 中尚未被 http.Request.Body 消费的字节（比如你调用了 r.ParseForm() 但没读完原始流）。如果直接用 conn.Read()，会跳过这部分残留数据，造成协议错位。
实操建议：
- 用
bufrw.Reader继续读取剩余请求数据（例如 WebSocket Upgrade 请求头之后的 payload） - 用
bufrw.Writer发送响应（如101 Switching Protocols）和后续二进制帧 - 务必在完成交互后显式调用
conn.Close()——bufrw不会自动关连接 - 若需并发读写，注意
bufio.ReadWriter非线程安全，应加锁或改用conn自带的SetReadDeadline/SetWriteDeadline
HTTP/2 下 Hijack() 为什么一定失败
Go 的 http.Server 在启用 HTTP/2 时（默认开启，只要配置了 TLS），底层不再使用明文 TCP 连接模型。Hijack() 接口会被直接禁用，调用始终返回 http.ErrNotSupported。
这意味着：
- 本地开发用
http.ListenAndServe(":8080", handler)可以 Hijack - 生产部署若用了 HTTPS + HTTP/2（如 Nginx 反代或 Let's Encrypt），
Hijack()会静默失败 - 没有绕过办法——HTTP/2 的帧复用机制与裸连接接管本质冲突
如果你的应用强依赖 Hijack（比如自研协议网关），上线前必须确认服务端是否禁用 HTTP/2，或改用明确支持裸连接的监听方式（如单独起 net.Listen("tcp", ...) 并手动处理 TLS 握手）。
真正难处理的不是语法，而是连接生命周期的移交时机和 HTTP/2 的隐式限制——这两点容易在压测或上线后才暴露。
