不能用 http.Server 做设备长连接接入层，因其请求-响应模型不支持服务端主动推送、心跳保活和低开销通信，硬套会导致TCP频繁建连断连、handler同步阻塞排队、JSON解析触发高频GC。
直接用 net/http 跑私有长连接网关，延迟会不可控，连接数上 500 就开始抖；真要低延迟、高设备密度，必须绕开 HTTP 栈，裸用 net.Conn + 自定义二进制协议头 + 严格 Deadline 控制。
为什么不能用 http.Server 做设备长连接接入层
HTTP 是请求-响应模型，而物联网设备需要服务端主动推送、心跳保活、低开销上下行。硬套 http.Server 会踩三个坑：
- 每个设备短连接轮询，触发频繁 TCP 建连/断连，内核态开销陡增
-
http.Serverhandler 同步执行，一个设备查数据库卡住，其他设备请求全排队 - JSON 解析 + struct 分配反复触发 GC，500 QPS 下
runtime.mallocgc占用超 70% CPU 时间
实操建议：设备侧用裸 net.Conn 连接网关，协议头固定 5 字节（4 字节 payload length + 1 字节 type），服务端用 io.ReadFull 定长读取，跳过所有 HTTP 解析逻辑。
net.Conn 必须设置 ReadDeadline 和 WriteDeadline
没设 deadline 的 net.Conn 在设备静默掉线（比如 NB-IoT 模组休眠）时，Read 会永久阻塞，goroutine 泄漏，file descriptor 被吃光。
立即学习“go语言免费学习笔记（深入）”；
-
SetReadDeadline推荐值 = 设备心跳周期 × 2，常见设为30 * time.Second -
Write前必须检查连接是否活跃，可用conn.RemoteAddr()配合SetWriteDeadline(5 * time.Second) - 别依赖
io.EOF判断断连——设备突然断电时可能返回nil, nil或 panic，要用errors.Is(err, os.ErrDeadlineExceeded)显式捕获
自定义协议比 WebSocket 更适合嵌入式设备
gorilla/websocket 看似省事，但它基于 HTTP Upgrade，带握手、掩码、ping/pong 逻辑，对资源受限设备（如只跑 Lua 的 4G 模组）是负担。
-
websocket.WriteMessage内部加锁 + 拷贝 + 编码，单次平均多花 0.3ms；裸conn.Write()直接写 socket buffer，压到 0.05ms 以内 - 设备端实现简单：只需按协议头长度字段读取 payload，无需理解帧格式或掩码算法
- 保活交给内核：
conn.SetKeepAlive(true)+conn.SetKeepAlivePeriod(60 * time.Second)，比手动起 goroutine ping 更可靠
连接生命周期管理不严会导致 P99 延迟秒级飙升
设备频繁上下线时，旧连接的 goroutine 若没退出信号，会在空闲连接上持续 Read，既浪费内存又拖慢新连接处理。
- 每个连接启动独立 goroutine 处理，但必须用
context.WithTimeout包裹整个读写循环 - 连接关闭前，显式调用
conn.Close()并清空关联的 session map / device_id 缓存 - 别在
handleConn里直接log.Printf原始字节——MQTT CONNECT 包含 token，日志泄露风险高
最易被忽略的一点：协议解析错误（比如长度字段超限）必须立即关闭连接并回收 goroutine，否则异常设备会持续消耗资源，且不会触发 deadline 超时。
