用net.conn而非http.server因需统一处理mqtt、coap等多协议原始字节流，http.server仅适配http流量；实操须用独立goroutine、设读写deadline、避免明文日志敏感信息。
为什么用 net.Conn 而不是 http.Server 做协议接入层
物联网网关要同时处理 MQTT、CoAP、自定义二进制 TCP 协议，HTTP 只是其中一小部分（比如设备管理 API）。硬套 http.Server 会导致非 HTTP 流量无法解析，甚至直接被中间件丢弃。真实场景里，net.Listener + net.Conn 是唯一能统一收口所有原始字节流的入口。
实操建议：
- 每个协议启动独立 goroutine 处理
conn，避免阻塞主 accept 循环 - 务必设置
conn.SetReadDeadline和conn.SetWriteDeadline，否则长连接空闲时会卡死 goroutine - 不要在
conn.Read后直接fmt.Printf原始字节——MQTT CONNECT 包含敏感 token，日志可能泄露密钥
gob 和 protobuf 都不适合做设备通信序列化
设备端资源有限，gob 不跨语言、无 schema 检查；protobuf 虽好但需要预编译 .proto，而网关常需动态加载新设备类型。实际选型中，JSON（带字段裁剪）和 CBOR（RFC 7049）更实用。
实操建议：
- 对低功耗设备（如 NB-IoT 终端），优先用
CBOR：体积比 JSON 小 30%～50%，Go 原生支持encoding/cbor - 禁用
json.Marshal的html.EscapeString行为——设备上报的传感器 ID 可能含下划线或连字符，转义后无法匹配路由规则 - 定义统一消息结构体时，把协议元信息（如
protocol、qos、device_id）放在顶层字段，别嵌套进 payload
MQTT Broker 不能直接复用 github.com/eclipse/paho.mqtt.golang
这个库是 MQTT 客户端 SDK，不是服务端。网关若作为 MQTT broker，需解析 CONNECT/PUBLISH/CONNACK 等报文，并维护 session、topic tree、QoS 2 的重复检测。强行用客户端库反向“模拟 broker”，会在 QoS 1/2 场景下丢消息或重复投递。
实操建议：
- 生产环境直接集成
github.com/fhmq/hmq（轻量、纯 Go、支持集群）或github.com/mochi-mqtt/server（v2+ 支持 TLS 客户端证书校验） - 若必须自研，重点实现
PACKET_TYPE_PUBLISH的 topic filter 匹配逻辑——别用strings.Contains，要用mqtt.MatchTopic这类标准通配符匹配函数 - 禁止在
PUBLISH处理中同步调用外部 HTTP 接口——高并发时易拖垮整个 broker，改用 channel 异步转发到 worker pool
TLS 配置在多协议网关中最容易出错的三个地方
同一端口跑 MQTT over TLS、HTTPS、自定义协议 TLS，看似只差一个 tls.Listen，但证书链、ALPN、SNI 处理稍有偏差，就会导致某类设备连不上。
实操建议：
- 用
tls.Config.GetConfigForClient动态返回不同*tls.Config，根据ClientHello.ServerName区分设备厂商证书（比如华为设备连iot-huawei.example.com，阿里设备连iot-ali.example.com） - 显式设置
NextProtos: []string{"h2", "http/1.1", "mqtt"}，否则 iOS 设备的 MQTT 客户端可能因 ALPN 不匹配静默断连 - 自定义协议若也走 TLS，必须在
GetConfigForClient中检查ClientHello.AlpnProtocols，匹配不到就拒绝握手，别 fallback 到明文协议
协议协商不是“能连上就行”，而是每个字节都要对齐设备固件的 TLS 栈行为。现场调试时，先用 openssl s_client -alpn mqtt -connect 验证 ALPN，再看 Wireshark 里的 ClientHello 是否携带预期 SNI 和 ALPN 字段。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
