必须显式设置连接超时，推荐用net.DialContext配合context.WithTimeout；Write需循环处理返回字节数；Read读到n==0且err==nil表示对端关闭；broken pipe等错误主因是连接生命周期管理混乱。
connect() 失败但没报错？检查 net.Dial 的返回值和超时设置
Go 的 net.Dial 默认不带超时，一旦目标地址不可达（比如端口未监听、防火墙拦截、DNS 解析卡住），会卡在 SYN 等待阶段，可能阻塞几秒甚至更久。这不是 bug，是 TCP 协议栈行为。
必须显式传入带超时的 context.Context，否则线上服务容易因单个连接拖垮整个 goroutine 池：
conn, err := net.DialTimeout("tcp", "127.0.0.1:8080", 3*time.Second)
或者更推荐用 net.DialContext 配合自定义 context：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)<br>defer cancel()<br>conn, err := net.DialContext(ctx, "tcp", "127.0.0.1:8080")
- 别依赖
err == nil就认为连接已就绪——conn非 nil 且 err 为 nil 才真正可用 - 如果用
DialTimeout，注意它底层仍调用DialContext，但无法细粒度控制 DNS 超时；高可靠场景建议自己控制 DNS 解析 - Windows 下某些网络环境会把 ICMP 不可达误判为“连接成功”，实际发数据时才暴露问题，务必在
Dial后立刻做一次小包Write测试
发送数据时 Write 返回 n < len(buf)，不是 bug 是常态
TCP 是流协议，conn.Write() 不保证一次性发出全部字节。尤其在网络拥塞、接收方读取慢、或发送缓冲区满时，会只写入部分数据并返回实际字节数 n。
立即学习“go语言免费学习笔记（深入）”；
直接忽略 n 或假设它等于 len(buf)，会导致数据静默截断：
// ❌ 错误：以为全写出去了<br>conn.Write([]byte("HELLO"))<br><br>// ✅ 正确：循环写完<br>buf := []byte("HELLO")<br>for len(buf) > 0 {<br> n, err := conn.Write(buf)<br> if err != nil {<br> return err<br> }<br> buf = buf[n:]<br>}
- 标准库
io.WriteString和bufio.Writer内部也做类似处理，但它们不解决底层粘包问题，只是帮你省去循环逻辑 - 如果用
bufio.Writer，记得在关闭前调用Flush()，否则最后一段可能滞留在缓冲区 - 不要在
Write后立刻Read，除非服务端明确支持半双工交互；多数 TCP 服务要求先发请求再等响应，顺序错乱会导致协议解析失败
接收数据时 Read 返回 n == 0 且 err == nil 怎么办
这是 TCP 连接被对方正常关闭（FIN）的信号，不是错误。很多新手看到 n == 0 就 panic，其实该干净关闭本地连接：
n, err := conn.Read(buf)<br>if n == 0 && err == nil {<br> // 对端 close() 或 shutdown(SHUT_WR)，连接已半关<br> conn.Close()<br> return<br>}
-
Read返回n > 0且err == nil：正常读到数据 -
n == 0且err == io.EOF：也是对端关闭，等价于上一种情况（不同 Go 版本表现略有差异） -
err != nil且不是io.EOF：网络异常，如连接重置（connection reset by peer）、超时、中断等，需按错误类型决策是否重连 - 别用
ReadString('\n')或ReadBytes处理无结构裸 TCP 流——它们会一直阻塞直到找到分隔符，而对方可能根本没发换行符
为什么本地测试通，上线后频繁出现 broken pipe 或 use of closed network connection
这两个错误本质都是：你试图往一个已关闭的 net.Conn 写数据。常见原因不是代码写错，而是连接生命周期管理混乱：
- 多个 goroutine 并发读写同一个
conn，且没有同步机制；Close()被某处提前调用，其他 goroutine 还在Write - 使用
http.Transport或第三方库封装的连接池，误以为conn可复用，实则底层已被回收 - 心跳检测逻辑缺陷：比如只检测读超时，却允许写操作持续发包，最终触发对端 RST
- Linux 系统级限制：
net.ipv4.tcp_fin_timeout过短，或TIME_WAIT连接占满本地端口，新连接被迫复用旧 socket 导致状态错乱
最稳妥的做法是：每个连接绑定单一 goroutine 负责读+写+关闭，用 channel 或 sync.Once 保证 Close() 只执行一次；所有写操作都通过该 goroutine 的 channel 投递，避免竞态。
