net.Conn不能直接复用，因其绑定唯一文件描述符和缓冲区，且不保证并发安全；并发读写会导致数据错乱或连接重置，须用“一连接一goroutine”模型并分离读写协程。
为什么 net.Conn 不能直接复用？
每个 net.Conn 是一个独立的、有状态的连接实例，底层绑定着唯一的文件描述符和读写缓冲区。试图在多个 goroutine 中并发调用 conn.Read() 或 conn.Write() 会导致数据错乱、read: connection reset by peer 或 write: broken pipe —— 因为 TCP 流本身无消息边界，且 Go 的 net.Conn 接口不保证并发安全。
常见错误是写成这样：
go func() { conn.Read(buf) }()
go func() { conn.Write(data) }()
这会引发竞态，Go 的 race detector 通常能捕获到 sync/atomic 相关警告。
- 必须为每个连接启动独立 goroutine 处理读或写（推荐「一读一写」分离）
- 若需多路写入（如广播、异步通知），应通过 channel 向单个 writer goroutine 投递数据
- 不要在 handler 中直接
defer conn.Close()，除非你确定所有 goroutine 已退出并停止使用该conn
如何安全地实现「一连接一goroutine」模型？
标准做法是在 accept 后立即启一个 goroutine 处理该连接，内部再拆分为 reader/writer 协程（或仅一个协程做同步读写），避免阻塞主线 accept 循环。
立即学习“go语言免费学习笔记（深入）”；
典型结构如下：
for {
conn, err := listener.Accept()
if err != nil { continue }
go handleConnection(conn) // 每连接一个 goroutine
}
handleConnection 内部建议：
本文档主要讲述的是android rtsp流媒体播放介绍；实时流协议（RTSP）是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
- 用
bufio.NewReader(conn)包装读取，提升小包效率 - 用
io.Copy()做透传时注意它会关闭目标io.Writer，慎用于长连接 - 设置
conn.SetReadDeadline()防止空闲连接长期占用资源 - 用
sync.WaitGroup或errgroup.Group等待 reader/writer 协程退出后再关闭conn
怎样避免 goroutine 泄漏？
泄漏常发生在：reader 协程因网络中断未退出、writer 协程卡在阻塞写、或 panic 后未 recover 导致协程静默死亡但资源未释放。
关键控制点：
- 所有
conn.Read()调用前必须设SetReadDeadline，超时后主动 break 退出 reader - 写操作建议用带超时的
conn.SetWriteDeadline()，尤其在发送大块数据或响应慢时 - 在
handleConnection入口加defer func(){if r := recover(); r != nil { log.Println(r) } }() - 用
context.WithTimeout控制整个连接生命周期，例如 5 分钟无活动则强制断开
漏掉 deadline 设置，是线上服务 goroutine 数持续上涨的最常见原因。
需要支持百万连接时，还能用 goroutine per connection 吗？
可以，但要注意：Go runtime 对 goroutine 的调度开销极低（初始栈仅 2KB），实测单机 100w+ 连接 + goroutine 在合理优化下可行。真正瓶颈往往不在 goroutine 数量，而在：
- 系统级限制：
ulimit -n是否足够（需 ≥ 连接数 × 2） - 内存：每个
net.Conn+ goroutine + buffer 约占用 10–20KB，100w 连接 ≈ 10–20GB RAM - 频繁小包：未合并读写导致 syscall 过多，应启用
TCP_NODELAY(false)并用bufio批量处理 - GC 压力：大量短生命周期 byte slice 容易触发高频 GC，考虑使用
sync.Pool复用buf
别过早切换到 epoll/kqueue 手动轮询模型 —— Go 的 netpoller 已帮你做了这事；先压测、看 profile、再决定是否要上连接池或协议分帧优化。
