Go语言中用匿名函数做心跳处理器可行，但必须通过闭包捕获*websocket.Conn和超时状态，配合done channel控制ticker生命周期、sendChan串行化写操作，并在重连前显式关闭旧连接及协程。
Go 语言中用匿名函数做心跳处理器是可行的，但直接裸写匿名函数容易导致状态丢失、超时误判和 goroutine 泄漏——关键不在“能不能”，而在“怎么绑定状态”。
gorilla/websocket 的 SetPongHandler 必须捕获连接状态
gorilla/websocket 的 SetPongHandler 接收一个函数，但它在每次收到 Pong 时被调用，且不带任何上下文参数。如果只写 func(string) error { ... } 这种纯匿名函数，就无法更新连接的最后活跃时间、无法通知心跳 ticker 重置超时、也无法感知连接是否已关闭。
- 常见错误：直接在
SetPongHandler里调用conn.SetReadDeadline，但没检查conn是否已被关闭，导致 panic - 正确做法：把
*websocket.Conn和超时时间封装进闭包，例如：conn.SetPongHandler(func(appData string) error { conn.SetReadDeadline(time.Now().Add(60 * time.Second)) return nil }) - 注意：这个 handler 不会自动重置写超时，写操作仍需单独控制
SetWriteDeadline
心跳发送不能只靠 time.Ticker，必须配合连接生命周期管理
单纯起一个 time.Ticker 每 30 秒发 WriteControl(websocket.PingMessage, ...) 是危险的——如果连接已断开或正在重连，WriteControl 会阻塞或 panic，而 ticker 仍在运行。
- 必须用
select+done chan struct{}控制 ticker 生命周期，连接关闭时立即停止 - 发送前要加锁检查
conn != nil && conn.IsClosed() == false，gorilla 库没有公开IsClosed，可用conn.WriteMessage尝试写空消息判断（更稳妥） - 写失败时不要忽略错误，应触发重连逻辑，而不是继续发 Ping
并发读写必须隔离，匿名函数不能替代状态封装
很多人以为“启动多个 goroutine + 匿名函数”就是高并发，但 WebSocket 连接的读、写、心跳三路 goroutine 共享同一个 *websocket.Conn，而 gorilla 库不是线程安全的——WriteMessage 和 WriteControl 不能并发调用。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
立即学习“go语言免费学习笔记（深入）”；
- 典型现象：
concurrent write to websocket connectionpanic - 解决方式：所有写操作（含 Ping）必须经由一个
sendChan chan []byte或专用写 goroutine 串行化 - 心跳 goroutine 只负责定时发 Ping，不参与业务消息发送；业务消息走独立写通道，避免抢占
- 读 goroutine 中捕获
websocket.IsUnexpectedCloseError后，要通过 channel 通知主控逻辑，而非直接调用reconnect()
重连时旧连接未清理会导致资源泄漏
高频重连场景下，如果每次重连都新建 goroutine 而不显式关闭旧的读/写/心跳协程，goroutine 数量会指数增长，内存持续上涨。
- 必须在
reconnect()前执行conn.Close()，并确保所有依赖该连接的 goroutine 收到done信号后退出 - 推荐结构体字段包含
done chan struct{}和mu sync.RWMutex，每次重连前先close(wsc.done)再wsc.done = make(chan struct{}) - 心跳 goroutine 中的
ticker.C必须与done同时 select，否则 ticker 无法退出
真正决定长连接稳定性的，从来不是“有没有心跳”，而是心跳逻辑是否与连接状态严格耦合、写操作是否被正确串行化、以及重连时旧资源是否被彻底释放——这些细节藏在匿名函数背后，却决定系统能否扛住万级并发。
