net.conn 不支持跨 goroutine 并发写，需用 channel + 单 writer goroutine 串行化：定义 writereq 结构体，带缓冲 channel 提交写请求，由专属 goroutine 执行 conn.write 并返回结果。
net.Conn 不支持跨 goroutine 并发写，直接在多个 goroutine 中调用 conn.Write() 会导致数据错乱、截断，甚至 panic（比如 write: broken pipe 或 use of closed network connection 在非预期时机出现）。这不是 bug，是设计使然：接口不承诺线程安全，底层实现也未加锁。
为什么不能对 conn.Write() 加 sync.Mutex 就完事
加锁看似简单，但掩盖了更危险的竞态本质：
-
Close()和Write()可能并发——锁住Write()调用本身，并不能阻止另一个 goroutine 同时调用conn.Close()，而Close()会中断阻塞中的Write()，返回use of closed network connection - 锁粒度难平衡：锁整个
Write()调用，高并发下吞吐骤降；只锁 buffer 拼接，仍无法解决底层 socket 写竞争（尤其 TLS 连接或bufio.Writer场景） - 无法防止读写混用导致的协议层错序（如自定义帧头、登录态校验等场景中，A goroutine 写请求、B goroutine 写响应，顺序完全不可控）
必须用 channel + 单 writer goroutine 串行化写
这是生产系统最可靠、零锁开销、语义清晰的方案。核心是把所有写请求统一交由一个专属 goroutine 处理：
- 定义
type writeReq struct { data []byte; resp chan error }，支持带反馈的写操作 - channel 建议带缓冲（如
make(chan writeReq, 128)），避免发送方因网络卡顿被阻塞 - writer goroutine 中只做
conn.Write(req.data)和req.resp ，禁止任何耗时逻辑（JSON 编码、日志、DB 查询等必须提前完成） - 连接关闭前，必须
close(ch)并waitwriter 退出，否则 goroutine 泄漏
读写必须分离，且 reader 也要设 deadline
即使写已串行，reader 仍需独立 goroutine，且不能忽略超时控制：
- reader goroutine 负责循环
conn.Read()，解析完整消息（推荐bufio.Scanner或定长/变长帧头解析器），防止粘包 - 每次
Read()前必须调用conn.SetReadDeadline(time.Now().Add(30 * time.Second))，否则空闲连接会永久阻塞 goroutine -
conn.Close()应由 reader 在 EOF 或错误时触发，并同步关闭 write channel，通知 writer 退出 - 绝对不要在
handleConnection入口defer conn.Close()——此时 writer 可能还在发包，会引发 panic
客户端复用连接时的写安全要点
服务端坚持“一连接一 goroutine”，客户端则常需单连接发多请求（如 RPC、数据库驱动），这时要额外注意：
- 若协议简单（如 Redis RESP），可用
*sync.Mutex包裹conn.Write()和conn.Read()，但必须确保Close()不与它们并发 - 若需异步响应（如带 request ID 的 RPC），必须用
writeCh chan []byte+ 独立 writer，读侧靠 ID 关联回调，不能依赖写入顺序 - 禁止把
net.Conn存为全局变量，或在多个 handler 间共享未加防护的连接实例
真正容易被忽略的是：writer goroutine 退出前，必须确认最后一次 Write() 已完成并收到 error，否则最后几条消息可能静默丢失；而 reader 的 deadline 设置必须每次 Read() 前重置，不是只设一次。
