net.Conn 不保证应用层并发安全，需通过“一连接一goroutine+读写分离”模型控制：reader专读、writer串行写，避免并发读写导致粘包、错序或协议解析失败。
net.Conn 本身不保证应用层并发安全，必须靠模型设计来控制——不是加锁就能解决，而是要避免多个 goroutine 同时读或写同一连接。
为什么不能直接在多个 goroutine 里调用 conn.Read() 和 conn.Write()
虽然 net.Conn 接口文档说 “Multiple goroutines may invoke methods on a Conn simultaneously”，但这仅指底层系统调用不会 panic 或崩溃；它不保证数据顺序、不防止粘包、也不阻止语义错乱。比如两个 goroutine 并发 conn.Write([]byte("A")) 和 conn.Write([]byte("B"))，对端很可能收到 "BA" 或 "AB" 交错片段，因为 TCP 是字节流，Write() 调用本身不是原子消息边界。
- 常见错误现象：
read: connection reset by peer、write: broken pipe、响应内容错位、协议解析失败 - 真实风险点：不是“会不会崩”，而是“逻辑是否可预期”——尤其在带状态的协议（如自定义帧头、登录后才能发业务包）中，竞态会直接导致会话异常
- UDP 场景下更隐蔽：
ReadFromUDP()并发调用可能让不同 goroutine 拿到不同源地址的数据包，完全打乱请求-响应匹配逻辑
推荐做法：一连接一 goroutine + 读写分离
这是 Go 官方示例和生产系统最广泛采用的模型，核心是把连接生命周期与 goroutine 绑定，再在内部拆解职责。
- Accept 后立即启动一个
handleConnection(conn)goroutine，该 goroutine 内部再起两个子 goroutine：reader专责Read()，writer专责Write() -
writer必须串行化输出：所有写请求通过chan []byte投递，由 writer 协程按序取出并conn.Write()，避免并发写 -
reader建议用bufio.Scanner或带长度头的解析器，防止粘包；每次Read()前必须设conn.SetReadDeadline()，超时即退出，防止 goroutine 泄漏 - 不要在
handleConnection入口defer conn.Close()—— reader/writer 可能还在运行，应等两者都退出后再关连接
如何安全复用连接（客户端场景）
服务端“一连接一 goroutine”是铁律，但客户端常需复用单个连接发多个请求（如 RPC、数据库驱动），这时必须引入同步机制。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 共享连接 + 互斥锁：用
*sync.Mutex包裹conn.Write()和conn.Read()调用，适合低频、请求-响应明确的协议（如 Redis RESP） - 共享连接 + channel 控制：所有写请求走
writeCh chan，由独立 writer goroutine 处理；读响应则靠请求 ID 关联，适合异步通信 - 绝对禁止：把
net.Conn存成全局变量、或在多个 handler 之间传递后并发使用——连接一旦出错（如EOF或connection refused），状态不可恢复，必须重建 - 注意
io.Copy()的副作用：它会在完成时关闭目标io.Writer，若用于长连接透传，需包装一层io.Writer避免误关conn
并发数限制必须放在 Accept() 之后
想防资源耗尽？别碰 net.ListenConfig.Backlog，也别信 http.Server.MaxIdleConns——它们都不管新建连接数。
- 唯一可靠位置：在
listener.Accept()成功返回conn后、交给handleConnection前做准入控制 - Go 1.21+ 推荐用
golang.org/x/sync/semaphore：sem := semaphore.NewWeighted(int64(maxConns))，然后if !sem.TryAcquire(1) { conn.Close(); continue } - 切忌用
sem.Acquire(ctx, 1)阻塞等待——连接已建好，FD 已分配，阻塞等于占用系统资源，可能触发ulimit -n限制 - 释放必须在 goroutine 内部
defer sem.Release(1)，且确保 panic 时也能执行，否则许可永久丢失
真正容易被忽略的是：连接关闭时机和错误传播路径。很多泄漏不是因为没设 deadline，而是 reader 因网络抖动收到临时错误（如 syscall.EAGAIN）后没重试就退出，而 writer 还卡在 channel 发送上——结果连接没关、goroutine 没退、资源持续占用。处理这类边界，比写主逻辑更花时间。
