必须用gorilla/websocket而非标准库net/http，因其完整封装rfc 6455握手、帧解析、ping/pong心跳及连接管理；标准库仅支持http升级，手动实现易出错且不兼容主流客户端。
Go 语言做 WebSocket 消息推送，不需要引入庞大框架也能稳定跑起来；关键在于用对 gorilla/websocket 的连接管理方式，而不是自己手写握手或帧解析。
为什么不用标准库 net/http 直接升级 WebSocket
Go 标准库没有原生 WebSocket 支持，net/http 只能处理 HTTP 升级请求，但不负责后续的帧读写、ping/pong 心跳、连接状态维护。硬啃 RFC 6455 实现容易出错，比如二进制掩码处理错误、控制帧丢弃逻辑缺失，导致客户端突然断连却无日志可查。
实操建议：
- 直接使用
gorilla/websocket—— 它是事实标准，API 稳定，错误处理清晰 - 别在
http.HandlerFunc里调用conn.UnderlyingConn()去“接管”连接，这是反模式，会绕过库的缓冲和超时控制 - 升级时务必检查
err，常见错误如websocket: not a websocket handshake多因前端没发正确的Upgrade: websocket请求头
如何安全地广播消息给所有在线连接
并发写 WebSocket 连接必须加锁，但锁整个连接池会导致广播性能骤降；更合理的做法是每个连接配一个写协程 + 消息通道，由中心广播逻辑只往各通道塞消息。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
实操建议：
- 为每个
*websocket.Conn启动独立写协程，监听专属chan []byte - 广播时遍历连接 map，向每个通道
select发送（带超时），避免某个卡住的连接拖垮全局 - 连接关闭时记得
close()对应 channel，并从 map 中delete，否则内存泄漏 + panic: send on closed channel - 不要在广播循环里直接调用
conn.WriteMessage()—— 多个 goroutine 并发写同一连接会 panic
怎么判断客户端是否还活着
依赖 TCP keepalive 不够，因为中间代理（如 Nginx）可能截断它；必须靠 WebSocket 协议层的 ping/pong 机制主动探测。
实操建议：
- 设置
conn.SetPingHandler()，收到 ping 自动回 pong，无需手动处理 - 调用
conn.SetPongHandler()记录最后响应时间，配合定时器踢掉超时连接 -
conn.SetReadDeadline()和conn.SetWriteDeadline()必须设，且每次读/写前都更新，否则一次超时后后续操作全失败 - 别忽略
websocket.CloseMessage类型的读取 —— 客户端正常关闭时会先发 close 帧，此时应主动清理资源
最易被忽略的是连接生命周期与 goroutine 的耦合：写协程没退出、channel 没关闭、map 里残留已断开的 conn，三者叠加会让服务跑几天后内存持续上涨、广播延迟飙升。上线前务必用 pprof 抓 goroutine 数和 heap profile 看连接对象是否堆积。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
