必须用net.Conn而非http.Server，因其能统一收口MQTT、CoAP等多协议原始字节流，而http.Server仅适配HTTP流量，非HTTP报文会在解析前被拒绝或阻塞。
Go 语言是当前搭建高并发物联网硬件网关最务实的选择——它不靠语法糖堆砌，而是用 net.Conn 统一收口原始字节流、用 goroutine 天然支撑海量设备长连接、用 sync.Pool 和无锁队列压低 GC 压力。但直接上手容易在协议适配、TLS 配置和资源泄漏点栽跟头。
为什么必须用 net.Conn 而不是 http.Server
物联网设备协议五花八门：MQTT CONNECT 报文是二进制固定头+可变头+payload，CoAP 是 UDP 上的精简二进制格式，NB-IoT 终端甚至发自定义 TCP 私有帧。一旦套用 http.Server，非 HTTP 流量会在 TLS 握手后、HTTP 解析前就被 http.ReadRequest 拒绝或阻塞，根本进不到业务逻辑。
实操要点：
- 监听统一
net.Listener，对每个accept()到的net.Conn启动独立goroutine处理 - 必须调用
conn.SetReadDeadline和conn.SetWriteDeadline，否则空闲 MQTT 连接会卡死协程（Go runtime 不会自动回收） - 禁止在
conn.Read后直接fmt.Printf原始字节——MQTTCONNECT包含password字段，日志泄露即失密
goroutine 泄漏和连接池失控的三个高发场景
每秒接入 1000 台设备时，若未设防，goroutine 数可能在几分钟内突破 5 万，触发调度器雪崩。真实泄漏点往往藏在协议握手异常分支里。
立即学习“go语言免费学习笔记（深入）”；
典型问题与对策：
- MQTT
CONNECT超时未响应，但协程仍在等conn.Read→ 必须用time.AfterFunc或context.WithTimeout包裹握手流程 - CoAP 重传机制导致同一连接被重复
accept→ 在Listener.Accept后立即检查conn.RemoteAddr()是否已在连接池登记 - 自定义协议心跳超时后未关闭
conn→ 在心跳检测goroutine结束前显式调用conn.Close()，并用defer确保执行
TLS 配置在多协议共端口时的 ALPN 陷阱
想让 MQTT over TLS、HTTPS、私有协议 TLS 共用 443 端口？光靠 tls.Listen 不够。ALPN（Application-Layer Protocol Negotiation）协商失败会导致某类设备握手卡在 ChangeCipherSpec 阶段，现象是设备反复重连但网关无日志。
关键配置项：
- MQTT 客户端必须声明 ALPN 协议为
"mqtt"（不是"h2"或空字符串） - HTTPS 请求需支持
"http/1.1"和"h2"，否则 Chrome 会降级到 HTTP/1.0 导致连接复用失效 - 私有协议建议注册唯一 ALPN ID（如
"iot-v3"），避免与标准协议冲突 - 务必在
tls.Config中设置NextProtos，且顺序影响协商优先级
设备消息序列化选型：别碰 gob，慎用 protobuf
设备端资源紧张，序列化方案直接影响功耗和传输时延。实测 NB-IoT 终端上报一次温湿度，CBOR 编码比 JSON 小 42%，而 gob 因无跨语言规范、无 schema 校验，在固件升级后极易出现静默解析失败。
推荐组合：
- 低功耗终端（NB-IoT、LoRaWAN）→
encoding/cbor：Go 原生支持，无需预编译，体积最小 - 中等性能网关（ARM64 边缘盒子）→ JSON（禁用
json.Marshal的html.EscapeString）：设备 ID 含下划线时，转义会导致路由匹配失败 - 需要强 schema 约束的场景 →
protobuf+ 动态加载.proto文件：用protoregistry.GlobalFiles.FindDescriptorByName实现运行时注册，避免重启网关
真正难的不是写通第一个 MQTT 连接，而是让十万设备在线时，CPU 不飙高、内存不持续增长、证书轮换不中断服务——这些细节藏在 conn.SetReadDeadline 的时间精度、sync.Pool 的对象大小对齐、以及 ALPN 协商失败后的降级路径里。
