不能用 net/http.handler 做多协议切换，因其强制解析 http 头、消费 r.body 并缓冲请求流，导致 grpc、websocket、mqtt 等协议无法获取原始帧头而报错；必须通过自定义 net.listener 在 accept 后仅读前 16 字节探测协议，并零消耗分发至对应服务。
为什么不能用 net/http.Handler 做多协议切换
因为 net/http.Handler 的契约强制消费 r.Body、校验 HTTP 头、缓冲请求流，而 gRPC、WebSocket、MQTT 等协议依赖原始字节流或连接生命周期。一旦调用 r.ParseForm() 或 io.ReadAll(r.Body)，下游协议解析器就收不到帧头，直接报错：rpc error: code = Internal desc = transport: received the unexpected content-type "text/plain" 或 WebSocket 连接瞬间 400。
- HTTP/2 流量（如 gRPC）必须由
grpc.Server.ServeConn()直接接管底层net.Conn，不能走http.HandlerFunc - WebSocket 升级请求必须在
http.ResponseWriter上调用Hijack()拿到原始连接，否则Upgrade头会被丢弃 - MQTT/CoAP 根本不在 HTTP 协议栈里，
http.Server连解析机会都不给
如何用 net.Listener 实现协议识别与分流
核心是自己包装 net.Listener，在 Accept() 后只读前 16 字节做协议探测，再把连接“塞回”对应协议服务实例中处理——这个过程必须快、轻、零消费 Body。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 读取后立即调用
conn.SetReadDeadline()，防止 TLS 握手卡住整个 accept 循环 - 用
switch判断特征字节：buf[0] == 0x16（TLS record）、bytes.HasPrefix(buf, []byte("GET "))（HTTP）、buf[0]&0xf0 == 0x10（MQTT CONNECT） - HTTP 流量交给改造过的
http.Server（禁用自动 body 解析）；gRPC 流量交给grpc.Server.Serve(&oneConnListener{conn})；MQTT 交给hmq或mochi-mqtt/server - 切忌在识别逻辑里调用
io.ReadAll(conn)——这会破坏所有后续协议的帧边界
如何让 gRPC 和 WebSocket 在单端口共存不互相劫持
HTTP/2 帧和 WebSocket Upgrade 请求在 TLS 握手后共享同一连接，ALPN 无法可靠区分 gRPC（本质是 h2）和 WebSocket（本质是 h1 + upgrade）。物理隔离仍是首选，但若必须单端口，靠路径前缀硬隔离最稳妥。
- 对路径以
/grpc/开头的请求，交由 gRPC codec 处理；对/ws/开头的，立即Hijack()并用websocket.Upgrader.Upgrade()接管 - 所有非标准路径（如
/mqtt/、/coap/）不注册进http.ServeMux，改用独立http.HandlerFunc拦截并启动专用协程监听 - 禁止在任何中间件里调用
r.Body.Read()或修改r.Header，否则Connection: upgrade可能被篡改 - gRPC-Web 请求要缓存前 1024 字节供
grpc.ServeConn()重放，不能直接读空r.Body
协议适配器层怎么写才不耦合业务逻辑
关键不是“支持多少协议”，而是让业务逻辑完全不感知传输层。所有协议最终都调用同一套 service 接口，参数和返回值用纯 Go struct，不含 HTTP header、gRPC metadata 等协议字段。
- HTTP adapter：从
*http.Request提取 body/query/header → 构造 domain struct → 调用UserService.CreateUser(ctx, req)→ 把 resp 写成 JSON - gRPC adapter：实现 .proto 生成的 server interface，把 pb struct 转成 domain struct；错误统一用
status.Errorf()包装 - WebSocket adapter：用
gorilla/websocket读消息后根据type字段路由到 service 方法，结果以 JSON 消息推回 client - adapter 层不做业务判断，只做“翻译”，且可单独启停（比如临时关闭 gRPC 端点）
r.Body 的逻辑之前——哪怕是一行日志中间件、一个 JWT 解析器，只要提前读了 body，后续 gRPC 或 WebSocket 就必然失败。这不是配置问题，是数据流顺序问题。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
