必须用gorilla/websocket而非net/http，因其自动处理帧解析、ping/pong心跳、closemessage及超时控制；需立即设readlimit防攻击，用channel+goroutine安全广播，优化序列化性能并严格管理连接生命周期。
实时数据大屏后端接口的核心不是“返回一次数据”，而是“持续推送”——用 gorilla/websocket 建立长连接，而非用 net/http 写个 JSON API 就完事。硬套 REST 接口做轮询，延迟高、连接多、服务端压力翻倍，大屏卡顿或掉帧基本都源于此。
为什么必须用 gorilla/websocket 而不是 net/http
net/http 只能完成 HTTP 升级握手，后续的帧解析、Ping/Pong 心跳、连接存活检测、CloseMessage 处理全得自己补。现实中，Nginx 日志出现 upstream prematurely closed connection，或客户端收到 websocket: close sent 后收不到新消息，90% 是因为没设 conn.SetPingHandler 或漏了 SetReadDeadline。
-
gorilla/websocket自动响应 Ping 帧、内置WriteJSON、支持读写超时，省掉手动解析 WebSocket 帧的坑 - 必须在
Upgrader.Upgrade()返回*websocket.Conn后立刻调用conn.SetReadLimit(512 * 1024)，防恶意大 payload - 别复用
http.ResponseWriter，它只参与握手；真正通信只靠*websocket.Conn
如何安全广播而不阻塞主线程
直接在 handler 里遍历所有连接并 conn.WriteMessage()，只要一个客户端网络慢，整个广播就卡住。正确做法是把每个连接抽象为带缓冲的 channel，用独立 goroutine 消费。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个
*websocket.Conn绑定一个chan []byte，缓冲大小设为 64（太大易爆内存，太小易丢） - 用
sync.RWMutex保护全局 map：map[*websocket.Conn]chan []byte - 广播时遍历 map，向每个 channel 发送序列化后的
[]byte；若 select default 触发，说明 channel 满，直接delete并conn.Close() - 每个连接配专属 goroutine：
for msg := range ch { conn.WriteMessage(websocket.TextMessage, msg) }，异常退出时清理 map
json.Marshal 性能不够时怎么优化
大屏每秒推 50+ 条结构化数据（如车辆坐标、设备状态），json.Marshal 频繁分配小对象，pprof 显示 runtime.mallocgc 占比超 35%，这不是逻辑问题，是序列化层瓶颈。
- 预分配
bytes.Buffer，避免每次 new + grow - 用
easyjson生成静态序列化代码，比标准库快 3–5 倍，且不触发 GC - 如果数据结构固定，可提前 Marshal 一次缓存
[]byte，广播时直接 copy，仅对动态字段做 patch
真正容易被忽略的是连接生命周期管理：没有心跳保活，代理或 NAT 网关会在 60 秒左右静默断连；没有读写 deadline，一个卡死的连接会拖垮整个广播 goroutine；channel 缓冲满时不主动剔除，内存会缓慢上涨。这些细节不处理，大屏上线三天后就开始掉连接、数据延迟飙升。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
