在Go语言标准库的net/http包中，普通的HTTP处理器函数通过ResponseWriter和Request完成一次请求响应周期。但当我们需要实现服务端和客户端双向不间断的数据流，例如终端实时日志推送加控制指令回传，就必须绕过默认的写入缓冲与连接回收逻辑。http.Hijacker接口正是为这种场景设计，它允许处理器从HTTP服务中“劫持”底层TCP连接，之后由开发者完全接管读写。
一、http.Hijacker接口与Hijack方法原理
http.Hijacker是net/http中定义的一个极小接口，仅包含一个方法：Hijack() (net.Conn, *bufio.ReadWriter, error)。实现了该接口的ResponseWriter（如*http.response）在调用Hijack后，会将对应的底层net.Conn从服务器的读写循环中摘除，并返回该连接以及配套的bufio.ReadWriter。此后，HTTP服务器不再管理这个连接的生命周期，也不会发送任何额外的HTTP头或结束响应。
从实现角度看，Hijack内部会先上锁确保连接未被其他协程关闭，接着将response的hijacked标志置为true，使后续的WriteHeader或Write调用直接返回错误。它还会将可能的缓冲数据刷入连接，再把原始conn和控制结构交还给调用者。这意味着开发者必须自己构造HTTP响应头（如果还要兼容HTTP语义），或者干脆使用私有协议在TCP上通信。
1.1 为什么普通Handler无法双工
标准HTTP处理器在逻辑上遵循“先读请求、再写响应、最后结束”的模型。即使使用Flush做流式输出，服务端也只能在响应体内追加数据，无法在同一连接上再读取客户端的新请求帧。而Hijack之后，连接变为原始的双向字节流，你可以随时从conn读、向conn写，不受HTTP请求边界限制。
这种设计在编写WebSocket握手前的裸连接、或者HTTP隧道代理时非常关键。不过要注意，一旦劫持，原生的路由中间件、访问日志、超时控制全部失效，需要手动补齐。
二、基于Hijack实现双工流式处理示例
下面演示一个最简的双工回声服务：客户端连接后，服务端先手动写回HTTP 200头，然后进入循环，把客户端发来的每行文本加上前缀再写回去，实现流式双向通信。
package main
import (
"bufio"
"fmt"
"net/http"
"time"
)
func streamHandler(w http.ResponseWriter, r *http.Request) {
// 类型断言获取Hijacker
hj, ok := w.(http.Hijacker)
if !ok {
http.Error(w, "web server does not support hijacking", http.StatusInternalServerError)
return
}
conn, bufrw, err := hj.Hijack()
if err != nil {
fmt.Println("hijack failed:", err)
return
}
defer conn.Close()
// 手动写入HTTP响应头，切换到应用层流
bufrw.WriteString("HTTP/1.1 200 OKrn")
bufrw.WriteString("Content-Type: text/plainrn")
bufrw.WriteString("Connection: keep-alivernrn")
bufrw.Flush()
// 设置读超时，防止空闲连接占用
conn.SetReadDeadline(time.Now().Add(30 * time.Second))
// 双工循环：读客户端数据并写回
reader := bufrw.Reader
writer := bufrw.Writer
for {
line, err := reader.ReadString('n')
if err != nil {
fmt.Println("read error:", err)
return
}
resp := "server got: " + line
_, err = writer.WriteString(resp)
if err != nil {
return
}
writer.Flush()
}
}
func main() {
http.HandleFunc("/stream", streamHandler)
http.ListenAndServe(":8080", nil)
}
2.1 代码关键点解析
在上面代码中，我们首先对ResponseWriter做类型断言，确认其实现了http.Hijacker。若运行在不支持劫持的自定义ResponseWriter上（极少数情况），应返回错误。调用Hijack后拿到的bufio.ReadWriter复用底层缓冲，比直接使用conn.Read更高效。
手动写响应头时必须严格遵循HTTP规范，以rn分隔且头尾空行结束。之后进入的双工循环通过ReadString按行读取，再用WriteString回写。由于已经脱离HTTP栈，任何写入都不会被自动加HTTP头，这要求我们自行设计消息边界，例如用换行符或长度前缀。
三、生产环境中的注意事项
使用连接劫持虽然灵活，但也带来一系列运维和稳定性问题。首先，HTTP服务器原本的连接数限制与超时机制不再生效，若不在应用层设置SetReadDeadline和SetWriteDeadline，恶意客户端可永久占用文件描述符导致资源耗尽。
其次，在劫持后不能再次调用原ResponseWriter的任何方法，否则会触发panic或错误。如果服务前面有反向代理（如Nginx），需确认代理不会在超时后主动断连而造成半开连接。建议在协程中启动读写分离：一个协程负责从conn读并推送到业务channel，另一个协程从channel取数据写conn，这样能更清晰地处理关闭信号。
3.1 与WebSocket的对比
WebSocket在Go中通常通过gorilla/websocket等库实现，其底层同样基于Hijack完成协议升级，但库已经封装了帧格式、掩码、Ping/Pong心跳。若你的需求只是内部服务间的高效双工流，且可自定义协议，直接Hijack能减少依赖与开销；若需浏览器兼容，仍应使用标准WebSocket库。
下表简要对比两种方案：
| 维度 | 直接Hijack | WebSocket库 |
|---|---|---|
| 浏览器支持 | 需自行解析HTTP | 原生支持 |
| 协议复杂度 | 自定义，简单 | RFC6455帧，较复杂 |
| 依赖 | 仅标准库 | 第三方包 |
| 超时控制 | 手动 | 库内置 |
四、常见误区与调试建议
一个典型误区是认为Hijack后还能用原来的http.Request.Body读取后续数据。实际上Hijack返回的conn已经包含了未被读取的剩余请求体字节，但Request对象不会再被更新。正确做法是从bufrw.Reader或conn继续读。
调试时可通过netstat观察ESTABLISHED连接数，或在代码中加入连接创建与关闭的日志。对于TLS连接，Hijack同样有效，但返回的是tls.Conn，需使用其类型断言后调用ConnectionState获取证书信息。只要理清 ownership（连接归属）的转移，http.Hijacker就能成为构建高性能双工服务的利器。
http.HijackerGo语言流式处理修改时间：2026-08-06 23:28:05