用net.dial建立tcp连接需配置超时（推荐net.dialer）、设置读写deadline、避免并发写入；收发需处理粘包（如长度前缀）；异常时依错误类型重连，关闭后仍可能读到残留数据。
如何用 net.Dial 建立基础 TCP 连接
Go 的 TCP 客户端起点非常明确：用 net.Dial，而不是自己写 socket 系统调用。它会自动处理 DNS 解析、IPv4/IPv6 选择、连接超时（默认无超时，这点必须手动控制）。
常见错误是直接写 net.Dial("tcp", "127.0.0.1:8080") 就开始读写，结果卡死在阻塞 I/O 上——服务端没响应或网络中断时，Read 或 Write 可能永远不返回。
- 务必搭配
net.DialTimeout或更推荐的net.Dialer控制超时：d := &net.Dialer{Timeout: 5 * time.Second, KeepAlive: 30 * time.Second} conn, err := d.Dial("tcp", "127.0.0.1:8080") - 连接成功后，立即设置读写超时：
conn.SetReadDeadline和conn.SetWriteDeadline，否则单次 I/O 故障会导致整个连接不可用 - 不要复用
conn跨 goroutine 写入——net.Conn不是线程安全的，并发写需加锁或用 channel 序列化
如何安全地收发字节流（避免粘包/截断）
TCP 是字节流协议，conn.Read 不保证一次读到完整业务包。常见现象：本该一次收到的 JSON 消息，被拆成两次返回；或一次 Read 返回了两个消息拼在一起。
解决思路不是“等数据来”，而是定义边界。最常用的是「长度前缀」方式：
- 发送前先写 4 字节大端整数表示后续 payload 长度，再写 payload
- 接收时先读满 4 字节，解析出长度
n，再循环读满n字节（用io.ReadFull） - 别用
bufio.Scanner默认的换行分隔——除非服务端真按行发，否则容易丢数据或阻塞 - 如果协议固定且简单（如 HTTP），可直接用
http.Client，它内部已处理好帧界
如何处理连接异常与重连逻辑
生产环境不能假设 conn.Write 总是成功。常见错误是忽略 Write 返回的 err，导致“以为发出去了”但实际连接已断。
判断连接是否还活着，不能只靠 conn != nil 或 err == nil，要观察具体错误类型：
-
read: connection reset by peer、write: broken pipe、i/o timeout都意味着连接失效，必须关闭并重建 - 不要在每次请求前都
Dial——建立 TCP 连接开销大；也不要长期持有一个连接不做心跳，NAT 网关或防火墙可能静默回收 - 重连建议用带退避的循环：
time.Sleep(time.Second * 1)→* 2→* 4，上限 30 秒，避免雪崩式重连 - 用
conn.Close()后，记得将 conn 变量置为nil，防止误用已关闭连接
为什么 net.Conn 关闭后还可能收到数据
这是个容易被忽略的底层细节：TCP 允许对端在 FIN 后继续发送少量数据（称为 “half-close”）。Go 的 conn.Read 在连接被对方关闭后，仍可能成功返回剩余缓冲数据，之后才返回 io.EOF。
这意味着你不能把 err == io.EOF 当作“对方彻底下线”的唯一信号：
- 收到
io.EOF后，仍需检查n > 0——即是否还有未处理完的数据 - 如果业务要求严格有序，应在应用层设计确认机制（如 ACK 包），不能依赖 TCP 连接状态推断消息完整性
- 使用
conn.SetDeadline时注意：它会影响所有后续 I/O，包括Read和Write，设置后记得重置或用SetReadDeadline单独控制
真正难的不是连上，而是连上之后怎么知道“此刻数据是否可信”、“下次该不该重试”、“这个错误要不要告警”。这些得结合协议语义和运维上下文来定，标准库只管字节流，不管业务意图。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
