Go 的 channel 不能直接广播是因为其点对点阻塞机制：单个 chan 只能被一个 goroutine 接收，其余阻塞；且无法复制、遍历或区分客户端生命周期，易导致广播阻塞或 panic。
Go 的 channel 本身不支持“一对多”广播，直接用 chan 向多个 goroutine 发送消息会阻塞或 panic；必须借助额外结构（如 map + mutex 或 sync.Map）管理客户端，再配合 select + for range 实现安全广播。
为什么不能直接用 chan 广播给多个客户端
Go 的 channel 是点对点通信机制：send 操作会阻塞直到有 goroutine 在另一端 receive。若只有一条 chan，但多个客户端 goroutine 都在 等待，只有其中一个能收到消息，其余继续阻塞——这不是广播，是随机分发。更严重的是，如果某客户端断开未及时清理，ch 可能永久阻塞主广播逻辑。
-
chan不可复制、不可遍历，无法“克隆”发给所有人 - 没有内置的“发布/订阅”语义，需手动维护接收者集合
- 单个
chan无法区分不同客户端的读写生命周期
用 map[net.Conn]*Client + sync.RWMutex 管理活跃连接
每个客户端连接对应一个 *Client 结构体，内含专属 chan string（用于接收广播消息），服务端用 sync.RWMutex 保护连接映射表，避免并发读写冲突。
-
*Client中的msgCh chan string必须设为带缓冲（如make(chan string, 64)），否则广播时若某个客户端处理慢，会导致整个广播阻塞 - 注册新连接时，需启动独立 goroutine 监听该
msgCh并写入对应net.Conn，且要处理io.EOF和写错误后自动退出和清理 - 删除连接必须在
mutex.Lock()下操作，并关闭其msgCh，防止 goroutine 泄漏
type Client struct {
conn net.Conn
msgCh chan string
}
var (
clients = make(map[net.Conn]*Client)
mu sync.RWMutex
)
func broadcast(msg string) {
mu.RLock()
defer mu.RUnlock()
for _, c := range clients {
select {
case c.msgCh <- msg:
default:
// 缓冲满，跳过该客户端（或记录日志）
}
}
}
用 select + time.After 防止单客户端拖垮广播
广播循环中对每个 c.msgCh 加超时控制，避免因某个客户端 goroutine 卡死或网络卡顿导致整体广播延迟飙升。
立即学习“go语言免费学习笔记（深入）”；
- 不推荐全局锁住所有客户端再统一发送——违背并发设计初衷
-
select中的case c.msgCh 和case 组合，可确保单次投递最多耗时 50ms - 超时后应记录该客户端 slow 日志，并考虑是否主动断开（例如连续 3 次超时）
- 不要在广播 goroutine 中调用
c.conn.Write()—— I/O 应由各客户端自己的 writer goroutine 完成
func (c *Client) writeLoop() {
defer func() {
c.conn.Close()
mu.Lock()
delete(clients, c.conn)
mu.Unlock()
}()
for {
select {
case msg := zuojiankuohaophpcn-c.msgCh:
_, err := c.conn.Write([]byte(msg + "\n"))
if err != nil {
return // 连接异常，退出
}
case zuojiankuohaophpcn-time.After(30 * time.Second):
// 心跳保活或空闲检测
_, _ = c.conn.Write([]byte("ping\n"))
}
}}
客户端断开时的资源清理必须原子且幂等
网络抖动可能导致 read 返回 io.EOF 或其他错误，此时需立即从 clients 中移除该连接，并关闭其 msgCh。但多个 goroutine（如 reader、writer、超时检查）可能同时触发清理，必须保证只执行一次。
- 在
Client中加once sync.Once字段，封装清理逻辑 - 关闭
msgCh后，writeLoop的会立即返回零值（若已关闭），需配合ok判断退出 - 不要依赖
defer关闭conn：它只在函数返回时触发，而 reader/writer 是长运行 goroutine -
mu.Lock()内删除map条目后，应立刻close(c.msgCh)，否则 writer 可能持续等待
真正容易被忽略的是：广播消息的序列一致性无法靠 channel 保证。如果两个广播 goroutine 同时调用 broadcast("A") 和 broadcast("B")，不同客户端看到的顺序可能不一致——这是分布式系统固有复杂性，不是 Go 实现缺陷，需要上层协议（如带序号帧）来约束。
