直接用 net/http 处理多协议转换会出问题，因其 Handler 接口仅适配 HTTP 流，无法兼容 gRPC、WebSocket 等协议的连接生命周期与帧格式，易致泄漏、粘包、状态错乱；须分层设计，HTTP 层仅识别路由，协议转换交由独立 listener + codec。
为什么直接用 net/http 处理多协议转换会出问题
因为 net/http 的 Handler 接口只约定 HTTP 请求/响应流，而网关要对接 gRPC、WebSocket、MQTT 甚至私有 TCP 协议时，底层连接类型、生命周期、数据帧格式完全不同。强行塞进 http.Handler 会导致连接泄漏、粘包、状态错乱——比如把 WebSocket 的 upgrade 请求当成普通 HTTP 转发，或者把 gRPC 的二进制帧当文本解析。
真正可行的路径是分层：HTTP 层只做协议识别与路由分发，具体协议转换交给独立的 listener + codec 组合。
- HTTP 入口统一走
http.Server，但所有非标准路径（如/grpc/、/ws/）不注册http.HandleFunc，而是用http.ServeMux的Handle拦截后手动分发 - gRPC 后端不能用
grpc.NewServer()直接监听端口，必须复用已有 TCP 连接，用grpc.ServeConn()+ 自定义net.Conn包装器 - WebSocket 必须在 upgrade 完成后立刻接管
conn，不能再走http.ResponseWriter
http.HandlerFunc 怎么安全识别并分流协议请求
关键不是“怎么写 handler”，而是“怎么避免提前读取 body 破坏后续协议解析”。例如 gRPC-Web 请求带 content-type: application/grpc-web+proto，但它的前几个字节仍是 HTTP/2 帧头；WebSocket upgrade 请求的 Connection: upgrade 头必须原样透传，不能被中间件修改。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 只检查
r.Method、r.Header.Get("Content-Type")、r.Header.Get("Upgrade")和路径前缀，**绝不调用r.Body.Read()或r.ParseForm()** - 对疑似 gRPC/gRPC-Web 请求，用
r.Body构造一个可重放的io.ReadCloser（比如用io.MultiReader+bytes.NewReader(cache)缓存前 1024 字节） - 对
Upgrade: websocket请求，立即返回 101 并调用hijack，后续完全脱离 HTTP 生命周期：hj, ok := w.(http.Hijacker) if !ok { http.Error(w, "websockets not supported", http.StatusServiceUnavailable); return } conn, _, err := hj.Hijack() if err != nil { return } // 后续用 conn.NetConn() + websocket.Upgrader.Upgrade() 手动处理
如何让 gRPC Server 复用已建立的 HTTP 连接
标准 grpc.Server 默认绑定到 net.Listener，但网关里连接已由 http.Server 接收。必须绕过 listen-loop，直接喂连接给 gRPC。
核心是两步：
- 实现一个包装
net.Conn的结构体，把原始 TCP 连接转成 gRPC 可识别的 stream（需实现grpc.Stream接口的底层读写逻辑） - 用
grpc.ServeConn(conn, opts...)替代server.Serve(lis)，注意该函数会阻塞，需丢进 goroutine
容易踩的坑：
-
grpc.ServeConn不会自动关闭conn，必须在外层显式defer conn.Close() - 若请求带 TLS，需确保
conn是*tls.Conn类型，否则 gRPC 解帧失败（错误信息类似failed to receive frame: unexpected EOF） - gRPC-Web 需额外加一层解码器，把 base64 或 binary 数据还原为原始 gRPC 帧，不能直接传给
grpc.ServeConn
协议转换中间件的生命周期管理难点
最常被忽略的是连接池和超时传递。HTTP 的 context.WithTimeout 对 gRPC 流无效，WebSocket 的 ping/pong 心跳也不能靠 http.Server.IdleTimeout 控制。
真实项目中必须手动对齐：
- HTTP 请求的
ctx超时值，需通过自定义 metadata 注入到 gRPC client ctx 中（用metadata.Pairs("x-timeout", "30s")） - WebSocket 连接需启动独立 goroutine 做心跳检测，超时时调用
conn.WriteMessage(websocket.CloseMessage, ...)后关闭底层net.Conn - 所有协议转换链路必须共用一个
sync.Pool缓冲区，避免高频小包分配导致 GC 压力（尤其 MQTT/私有协议场景）
没有统一的连接上下文管理，多协议网关跑几天后就会出现大量 TIME_WAIT 连接堆积或 goroutine 泄漏。
