必须自己实现net.Listener才能实现连接控制，因http.Server不暴露连接池、不提供连接列表、也不支持主动关闭单条连接，仅无条件接受conn并启goroutine处理，需通过包装Listener拦截Accept()和Close()来接管全生命周期。
必须自己实现 net.Listener，不能靠 http.Server 内部机制做连接控制。 Go 的 http.Server 不暴露连接池、不提供连接列表、也不支持主动关闭某条连接——它只管把 net.Conn 接过来，起 goroutine 处理完就丢。网关要限流、要踢异常设备、要查活跃连接数，就得从 net.Listener 这一层切入。
为什么不能直接用 http.Server.Serve(listener)
默认行为下，http.Server.Serve 会无条件接受所有 net.Conn，每个连接启动一个 goroutine，且没有退出信号。设备频繁上下线时，旧连接的 goroutine 仍在 Read 阻塞，又没设 SetReadDeadline，结果就是 goroutine 泄漏 + 连接堆积 + P99 延迟跳变。
- 无法获取当前活跃连接数，也就没法做并发限制
- 无法在连接空闲超时后主动
Close()，TCP 对端静默断连（比如 NB-IoT 模组休眠）会导致连接长期滞留 - 无法按设备 ID 或 IP 主动下线某条连接，运维和故障隔离能力归零
自定义 Listener 必须拦截 Accept() 和 Conn.Close()
核心是包装原生 net.Listener，在 Accept() 返回前记录连接，在 net.Conn.Close() 被调用时清理状态。不是“监听器加个钩子”，而是整个生命周期都要接管。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
sync.Map存net.Conn到元数据（如 remote addr、建立时间、协议类型），读写无需锁 - 在
Accept()中调用conn.SetReadDeadline，值建议设为设备心跳周期的 2–3 倍（比如心跳 30s，这里设 90s） - 给每个
net.Conn包一层，重写Close()方法：先从sync.Map删除自身，再调用底层Close() - 别依赖
defer conn.Close()—— 异常路径（如 panic、context cancel）可能跳过它，必须在所有出口显式 Close
多协议分发必须 Peek 前 N 字节
HTTP、gRPC、MQTT、私有二进制协议共存时，不能靠 http.Server 或 grpc.Server 自己识别——它们都假设连接已确定协议类型。得在 Accept() 后立刻 Read() 前 16 字节做协议探测，再决定交给谁。
立即学习“go语言免费学习笔记（深入）”；
- 用
io.ReadFull(conn, buf)替代conn.Read(buf)，避免只读到部分数据导致误判 - 探测完要把 buf 数据“塞回去”：构造
&peekConn{Conn: conn, buf: buf}，让后续 handler 能读到完整 payload - HTTP 和 WebSocket 必须走同一个
http.Server实例（因为 Upgrade 流程耦合），但 gRPC 必须绕过 http.Server，用grpc.Server.Serve(&oneConnListener{conn})直接喂连接 - 不要在
Accept()里做耗时解析（比如 TLS 握手检测），会卡住整个 listener；协议探测必须轻量、无阻塞
真正难的不是写一个 net.Listener 实现，而是让每条 net.Conn 的 Read/Write/Close 行为都可预测、可终止、可审计。Deadline 设多少、goroutine 怎么收、连接元数据存多久——这些细节堆起来，才是网关稳定性的分水岭。
