binary.write阻塞主因是未设写超时：tcp默认无超时，接收端读慢、断连或nagle攒包均致write卡在内核缓冲区满状态；必须每次写前调用conn.setwritedeadline(time.now().add(3*time.second))，且需检查err、管理goroutine生命周期并禁用nagle应对高频小包。
binary.Write 阻塞不是“网络慢”，是没设写超时
Go 的 binary.Write 底层调用 conn.Write()，而 TCP socket 默认无写超时。一旦接收端读得慢、断连未及时通知、或 Nagle 算法攒包，Write 就会卡在内核发送缓冲区满的状态，直到系统强制中断——表现为 "write timeout" 错误，但实际是超时未设导致的永久等待（或极长等待）。
SetWriteDeadline 必须每次写前重设
很多人只在连接建立后调一次 conn.SetWriteDeadline()，这是错的。TCP 连接可能空闲很久才发下一条消息，而 deadline 是绝对时间点，过期即失效。下次 Write 会直接返回 "i/o timeout"，哪怕网络完全正常。
- 每次调用
binary.Write前，都必须执行conn.SetWriteDeadline(time.Now().Add(3 * time.Second)) - 不能写成
conn.SetWriteDeadline(time.Now())——这会让 deadline 立刻过期，所有写操作秒报错 - 如果使用
context控制超时，需配合net.Conn.SetWriteDeadline手动转换：用ctx.Deadline()获取时间点，再传给SetWriteDeadline
Write 返回 nil 不代表数据已送达对端
Go 的 Write 只保证把数据拷贝进内核发送缓冲区，不保证对方收到、不保证 ACK 到达、也不触发 RST 检测。所以你看到 binary.Write 成功返回，不代表服务端 binary.Read 一定能读到——尤其当客户端已发 FIN、服务端处于 CLOSE_WAIT 时，第一次 Write 常成功，第二次才报 "broken pipe"。
- 必须检查每次
binary.Write的err，不能忽略 - 遇到
io.EOF或net.ErrClosed：对端已关闭写端，应主动conn.Close() - 遇到
net.OpError且Timeout()为 true：写超时，按策略重试或丢弃 - 遇到
"connection reset by peer"或"broken pipe"：连接已不可用，立即关闭并重建
别让 goroutine 在 Write 上“假死”而主程序失控
常见错误模式是：启动一个 listener goroutine 负责持续写，但 main 函数既不等待它，也不监听退出信号，反而陷入空循环。一旦 binary.Write 阻塞，该 goroutine 卡住，main 却还在跑，整个进程看似“活着”，实则无法响应、无法清理、无法重连。
- 用
chan struct{}或sync.WaitGroup显式等待工作 goroutine 结束 - 写逻辑中加入
select+ctx.Done()，支持外部中断 - 避免在无限循环里反复
net.Dial()而不 close：旧连接泄漏会快速耗尽文件描述符，加剧超时 - 高频小包场景下，可显式禁用 Nagle：
conn.(*net.TCPConn).SetNoDelay(true)，减少延迟但增加包数
真正难处理的从来不是超时本身，而是超时之后要不要重试、重连间隔怎么定、失败消息如何持久化——这些逻辑一旦和 binary.Write 的阻塞行为耦合，就很容易在 Wi-Fi、树莓派、MacBook 等混合链路上暴露出来。deadline 只是开关，背后的状态管理才是关键。
