go语言推流模块高性能核心在于合理使用channel、goroutine和连接生命周期管理，而非盲目堆并发或换库；应采用websocket长连接模型，配合per-room分发器、独立write goroutine、动态超时控制及显式连接清理，避免内存泄漏与锁竞争。
Go 语言开发高性能消息推流模块，核心在于用对 channel、goroutine 和连接生命周期管理，而不是堆并发数或换库。盲目增加 goroutine 数量反而导致调度开销暴涨、内存泄漏、连接堆积——这是生产环境最常踩的坑。
推流模块该用什么通信模型：不要用 HTTP 长轮询
HTTP 长轮询（Long Polling）在推流场景下本质是“伪实时”：每个客户端独占一个 HTTP 连接，服务端需维持大量 idle 连接，且无法主动推送。真正适合推流的是基于 TCP 的长连接 + 自定义协议，或 WebSocket（更推荐）。Go 标准库 net/http 原生支持 WebSocket，无需引入第三方框架。
- 用
gorilla/websocket是目前最稳的选择（注意不是gobwas/ws，后者不维护且存在竞态 bug） - 避免在 handler 中直接
ws.WriteMessage，应把写操作交给独立的 write goroutine，防止阻塞读循环 - 每个连接必须配对使用
donechannel 或context.WithCancel控制生命周期，否则超时/断连后 goroutine 泄漏不可避免
如何设计消息分发器：别让 broadcast 锁住整个 map
常见错误是用一个全局 sync.RWMutex 保护所有 client map，然后在 broadcast 时遍历并写入每个连接。一旦 client 数量过百，锁竞争会迅速成为瓶颈。
- 改用 per-room 分发器：按业务维度（如 room ID）分片，每个分片独立 lock，降低争用
- 写入 client 连接前先检查
conn.IsClosed()（gorilla/websocket提供），避免 panic - 广播消息建议走无缓冲
channel+ 单个 dispatcher goroutine，避免多个 goroutine 同时调用conn.WriteMessage - 若消息体较大（>4KB），考虑提前序列化为
[]byte，避免每次广播都重复 JSON marshal
连接管理最容易被忽略的三个细节
推流服务崩溃往往不是因为并发高，而是连接没管好。90% 的线上问题出在这三处：
-
SetReadDeadline和SetWriteDeadline必须设，且要随心跳周期动态更新；只设一次等于没设 - client 断连时，必须显式调用
conn.Close()并清空对应结构体引用，否则 GC 不回收底层 net.Conn - 不要依赖
defer conn.Close()在 handler 结束时关闭——handler 可能永远不退出（比如长连接 keep-alive 场景）
真正难的不是启动 10 万个 goroutine，而是让它们在 7×24 小时运行中不出 memory leak、不堆积 dead connection、不因一个 client 异常拖垮全服。推流模块的“高性能”，80% 来自连接状态机设计，20% 才是吞吐优化。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
