真正的零阻塞必须靠职责分离+带缓冲channel+超时控制三者协同：读写goroutine分离避免竞争，带缓冲channel防止发送阻塞，read/write deadline防止无限等待，缺一不可。
Go 高并发读写 socket 时，无法靠“设大缓冲区”或“开更多 goroutine”实现零阻塞；真正的零阻塞必须靠职责分离 + 带缓冲 channel + 超时控制三者协同，缺一不可。
为什么 SetReadBuffer/SetWriteBuffer 不能解决阻塞
调用 conn.SetReadBuffer 或 conn.SetWriteBuffer 只是调整内核 socket 缓冲区大小，它不改变 Go 应用层的 I/O 行为。即使你设了 1MB 缓冲区，只要 conn.Read() 还在用 make([]byte, 1024) 小 buffer 循环读，就仍会频繁 syscall、触发调度、卡住 goroutine。
- Linux 下超限设置会被静默截断（如普通用户设 2MB，实际只生效 212992 字节）
- macOS 对
SO_RCVBUF有倍增行为，设 64KB 实际分配 ≈ 128KB，但最小强制为 4096 -
err == nil不代表设置成功，必须用ss -i或netstat -nb确认rcv_space/snd_space是否真变 - HTTP Server / gRPC 等框架已内部调优，手动设置反而干扰其流控逻辑
每个连接必须拆成独立读/写 goroutine
多个 goroutine 同时对同一个 conn 调用 Read() 或 Write() 是危险的：底层状态竞争会导致数据错乱、io.ErrClosedPipe、甚至 panic。标准解法是让一个 goroutine 专读、一个专写，用 channel 中转。
- 读 goroutine 持续调用
conn.Read()，解析完整消息后发到writeChan（如按 \n 或固定头长） - 写 goroutine 从
writeChan接收数据，调用conn.Write()；若需顺序保证，仅对Write调用加sync.Mutex，而非锁整个流程 -
conn.Close()应由读 goroutine 在 EOF 或错误后触发，并关闭writeChan，通知写 goroutine 退出 - channel 必须带缓冲（如
make(chan []byte, 128)），否则远端接收慢时写 goroutine 会永久阻塞在 send 上
必须设 Read/Write Deadline，且每次调用前重置
不设 deadline 的 conn.Read() 会在内核缓冲区为空时无限等待，导致 goroutine 泄漏；不设 WriteDeadline 则大包卡死写 goroutine，拖垮整个连接。
- 在读 goroutine 循环中，每次
conn.Read()前调用conn.SetReadDeadline(time.Now().Add(30 * time.Second))，实现空闲超时 - 在写 goroutine 中，每次
conn.Write()前调用conn.SetWriteDeadline(time.Now().Add(5 * time.Second)) - 整个连接处理流程外层套
context.WithTimeout，超时后主动conn.Close()并清理状态（如从map[net.Conn]*ClientConn中删除） - 注意：deadline 是绝对时间，不是相对 duration，必须每次重置
替代内核缓冲的更可控方案：应用层 ring buffer + bufio
依赖 SO_RCVBUF 扩容治标不治本。高吞吐场景下，更稳的做法是把缓冲逻辑收归应用层，解耦内核队列与业务消费速度。
- 对写操作：用
bufio.Writer包装conn，设BufferSize = 64 * 1024，并配合sync.Pool复用实例，避免每次 malloc - 对读操作：启动 goroutine 持续
Read()到预分配的大 buffer（如make([]byte, 1），再用原子索引管理的 ring buffer（容量为 2 的幂，如 4096）暂存未处理消息 - ring buffer 的
head和tail必须用atomic.LoadUint64/atomic.StoreUint64管理，避免sync.RWMutex在高并发写时造成延迟激增 - 不要在 CAS 循环里做内存分配或系统调用，重试最多 3 次，超过说明真满或严重竞争
真正难的不是写 goroutine，而是让读 goroutine 在数据来得快、业务处理慢时，既不丢包也不堆积——这要求你清楚 ring buffer 的满判定逻辑（(nextTail+1)&(cap-1) == head）、deadline 的重置时机、以及 channel 缓冲大小和业务吞吐的匹配关系。这些细节一旦错位，零阻塞就变成假象。
