Go高并发Socket读写无法真正零阻塞中断，但可通过SetReadDeadline+带缓冲channel+select default实现可控超时与退避；Read默认阻塞属正常设计，需每次调用前重设Deadline，Write须经缓冲channel由单goroutine串行执行。
Go 高并发 Socket 读写无法“零阻塞中断”，但可通过 deadline + channel 缓冲 + select default 实现可控、可退、不卡死的近似效果。
conn.Read() 不设 SetReadDeadline 就是永久挂起
Go 的 conn.Read() 默认阻塞，不是 bug，是设计——它会一直等数据、EOF 或错误。高并发下若客户端静默（比如 keep-alive 连接空闲），成百上千 goroutine 就停在 net.(*conn).Read，pprof 看似“卡死”，实则是健康等待；但没超时机制，就真成资源泄漏。
- 每次调用
conn.Read()前必须重置：conn.SetReadDeadline(time.Now().Add(30 * time.Second)) - 不能复用旧时间值，否则 deadline 越来越早，连接被误杀
- 错误类型是
*net.OpError，用os.IsTimeout(err)判断，别字符串匹配"i/o timeout" - HTTP/1.1 keep-alive 场景下可只设一次，但得确保首次设置成功且未被后续逻辑覆盖
写操作不能直连 conn.Write()，必须走带缓冲 channel
多个 goroutine 同时调用 conn.Write() 会竞争 socket 底层状态，轻则 panic，重则数据错乱。标准解法是读写分离：一个 goroutine 专读，一个专写，中间用 chan []byte 传数据。
- channel 必须带缓冲，容量建议 ≥ 16（根据消息平均大小和突发流量调）
- 读 goroutine 发送前用
select { case writeChan 非阻塞发送，失败直接丢弃或记录，避免阻塞自身 - 写 goroutine 取出数据后立刻调
conn.Write()，并配conn.SetWriteDeadline(time.Now().Add(5 * time.Second)) - 检查
n != len(data)，未写全需重试或标记错误，不能静默忽略
select default 是防止 channel 积压的最后防线
即使用了带缓冲 channel，当远端接收慢、网络抖动或客户端断连未及时清理时，writeChan 仍可能填满。此时朴素的 writeChan 会阻塞读 goroutine，引发级联延迟。
- 所有向
writeChan发送的地方，都应包裹select { case writeChan -
default分支不是丢消息的借口，而是触发清理动作的信号：比如关闭该连接的writeChan、从连接池中移除、记录告警 - 不要依赖“缓冲够大就永不触发 default”——突发流量或长尾连接会让缓冲迅速失效
- 若业务要求强可靠，default 分支应把消息转入持久化队列（如 Redis Stream），而非直接丢弃
SO_SNDBUF 和 SO_RCVBUF 不解决 goroutine 阻塞问题
调大内核 socket 缓冲区（SO_SNDBUF/SO_RCVBUF）能缓解丢包、减少重传，但它只影响内核收发队列长度，对 Go 层 goroutine 是否阻塞毫无影响。goroutine 卡在 Read() 或 Write() 上，根源永远是超时缺失或 channel 设计失当，而不是缓冲区太小。
-
SetWriteBuffer()设置的是内核发送缓冲上限，不是 Go 层 channel 容量 - 盲目调大
SO_SNDBUF可能导致内存浪费，且在容器或低配设备上受/proc/sys/net/core/wmem_max限制 - 真正要调的不是内核缓冲，而是 Go 层的
writeChan容量 + deadline + select default 组合策略 - 非阻塞 socket 模式（
SOCK_NONBLOCK）在 Go 中基本不用——net.Conn抽象已封装 epoll/kqueue，手动设非阻塞反而破坏 runtime 网络轮询机制
最易被忽略的一点：deadline 时间计算必须每次调用前重新生成，不能缓存 time.Now().Add(...) 结果复用；而 channel 缓冲大小不是越大越好，要结合 GC 压力与消息平均体积做取舍——16 是起点，不是终点。
