直接并发调用 conn.writemessage() 会 panic，因为 gorilla/websocket 连接非并发安全：底层写缓冲区、状态机及 writemutex 仅保障单次写原子性，无法防止多 goroutine 同时写入导致的“concurrent write”或“use of closed network connection”错误；官方唯一稳妥方案是使用单写 goroutine + channel 模式，并每次写前调用 setwritedeadline()。
为什么直接并发调用 conn.WriteMessage() 会 panic
因为 gorilla/websocket 的连接对象不是并发安全的——它的底层写缓冲区、状态机（比如是否正在写控制帧）、以及 writeMutex 都只保护「单次写操作」的原子性，不保证多个 goroutine 同时调用 WriteMessage() 或 WriteJSON() 时互斥。一旦两个 goroutine 同时进入写逻辑，大概率触发 panic: write tcp: use of closed network connection 或更隐蔽的 concurrent write to websocket connection（取决于版本和时机）。
常见错误场景包括：一个 handler 启了多个 goroutine 推送消息（如广播、心跳、业务事件通知），或者用 select 在多个 channel 上收消息后直接往 conn 写。
- 不是所有写失败都会立刻 panic；有些会静默丢帧或阻塞，导致客户端收不到消息但服务端无报错
-
net.Conn层面的并发写本身就不被 Go 标准库允许，WebSocket 库只是继承并放大了这个限制 - 即使加了
sync.Mutex包裹整个WriteMessage()调用，也解决不了「写一半被另一个 goroutine 插入」的问题（比如控制帧被数据帧打断）
必须用 conn.SetWriteDeadline() 配合单写 goroutine 模式
官方推荐且唯一稳妥的做法是：把所有要写的数据发到一个 channel，由**单独一个 goroutine** 从 channel 读、序列化、调用 WriteMessage()。这个写 goroutine 必须自己管理超时和错误退出，否则 channel 堵塞会导致整个连接卡死。
关键点不在 channel 多快，而在「写动作必须串行 + 可中断」：
- 写 goroutine 开始前务必调用
conn.SetWriteDeadline()，否则一次慢写（如网络抖动）会让后续所有消息无限等待 - channel 缓冲区大小建议设为 1~8，太大容易掩盖背压问题；0 缓冲则要求发送方必须配合超时 select
- 不要在写 goroutine 里 recover panic——它通常意味着连接已断，应关闭 channel 并退出
示例核心结构：
go func() {
for msg := range c.sendChan {
if err := conn.SetWriteDeadline(time.Now().Add(5 * time.Second)); err != nil {
break
}
if err := conn.WriteMessage(msg.Type, msg.Data); err != nil {
break
}
}
conn.Close()
}()
conn.WriteMessage() 和 conn.NextWriter() 的选择陷阱
多数人只用 WriteMessage()，但它每次调用都隐式执行一次完整写流程（获取 writer、序列化、flush）。而 NextWriter() 允许你分段写大数据（比如大文件切片），但它的 writer 对象**不能跨 goroutine 使用，也不能复用**——一旦你用完一个 writer，必须立即调用 Flush()，否则下一次 NextWriter() 会阻塞或 panic。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
所以除非你在做流式推送（如视频帧、日志 tail），否则别碰 NextWriter()。它的并发风险比 WriteMessage() 更隐蔽：
- 误以为拿到 writer 就能多 goroutine 写 —— 实际上 writer 内部仍共享 conn 的写锁和缓冲区
- 忘记调用
Flush()，导致后续所有写操作 hang 住，且无错误提示 - 在 writer 还没 flush 完就启动下一个
NextWriter()，触发panic: concurrent write to websocket connection
广播场景下别让每个连接自己写，改用中心队列 + 连接级 channel
当你要向 1000 个连接广播同一条消息时，如果每个连接都开自己的写 goroutine 并从公共 channel 读，会引发大量 goroutine 竞争同一 channel，还可能因某个慢连接拖垮整体吞吐。正确做法是：用一个中心 goroutine 读广播消息，再分发到每个连接专属的 sendChan（带缓冲）。
这本质是「扇出（fan-out）」而非「共享通道」：
- 每个连接维护独立
chan []byte，避免写 goroutine 间竞争 - 中心广播 goroutine 发送前检查该连接的 channel 是否已满（用 select + default），满则跳过（或走降级逻辑）
- 连接断开时，记得 close 对应的
sendChan，否则写 goroutine 会永远阻塞在 recv
这种结构下，连接数增长不会线性增加 goroutine 数量（写 goroutine = 连接数），但 channel 分发逻辑本身需要轻量控制，别在里面做 JSON 序列化等耗时操作。
写 WebSocket 并发安全，核心就一条：写动作必须收敛到一个 goroutine，且这个 goroutine 必须对超时、关闭、错误有明确响应路径。其它所有技巧——channel 缓冲、deadline 设置、扇出分发——都是围绕它展开的容错设计。最容易被忽略的是：SetWriteDeadline() 必须在每次 WriteMessage() 前调用，而不是只在连接建立时设一次。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
