Go TCP客户端需重点管理连接稳定性：用net.DialContext设超时，写后检查err，Read不保证读全，关闭前刷新并读残留数据。
Go 的 net 包实现 TCP 客户端非常轻量，但容易在连接管理、错误处理和读写同步上出问题——关键不是“能不能连上”，而是“连上后怎么稳住”。
用 net.Dial 建立基础连接并设置超时
net.Dial 是最常用的入口，但它默认不带超时，遇到防火墙拦截或服务未启动时会卡死（比如阻塞在 SYN 重传阶段）。必须显式控制连接生命周期。
- 始终使用
net.DialTimeout或更推荐的net.DialContext配合context.WithTimeout - 协议名必须是
"tcp"（不是"tcp4"或"tcp6"，除非你明确要限定 IP 版本） - 地址格式为
"host:port"，其中host可以是域名（自动解析）或 IP 字符串，port必须是字符串（如"8080"）
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
conn, err := net.DialContext(ctx, "tcp", "127.0.0.1:9000")
if err != nil {
log.Fatal("connect failed:", err) // 注意：这里 err 可能是 *net.OpError，包含 Timeout() 方法
}
发送数据前先确认连接状态，别依赖 err == nil
即使 net.DialContext 成功返回 conn，也不能保证后续读写一定可用。TCP 连接可能在握手后瞬间被对端 RST，或中间网络设备中断。Go 不会在 Write 前自动探测连接活性。
- 不要跳过写入后的错误检查：
_, err := conn.Write([]byte("HELLO"))的err可能是write: broken pipe或write: connection reset by peer - 如果需要保活，手动发心跳包；
SetKeepAlive只影响底层 socket 选项，不能替代应用层探测 - 对短连接场景，写完立即
conn.Close()；长连接需自行管理重连逻辑
读取响应时小心 Read 的阻塞与截断
conn.Read 是底层 syscall read 的封装，它不保证一次读完所有数据——尤其当服务端分多次 Write，或网络存在延迟/分片时，很容易只读到部分响应。
立即学习“go语言免费学习笔记（深入）”；
- 永远不要假设
Read会填满整个 buffer；返回的n才是实际字节数 - 避免用
io.ReadAll(conn)直接读取，它会一直等到 EOF（即对端关闭），而多数 TCP 服务不会主动关连接 - 常见做法：按协议约定读取（如固定头长 + body 长度字段），或用
bufio.Reader配合ReadString('\n')/ReadBytes('\n')
reader := bufio.NewReader(conn)
line, err := reader.ReadString('\n')
if err != nil {
log.Fatal("read line failed:", err) // 可能是 io.EOF（对方关闭）、io.TimeoutError 或 net.OpError
}
fmt.Print("received:", strings.TrimSpace(line))
关闭连接前确保写缓冲已刷新，且读取残留数据
conn.Close() 只关闭 socket，不等待内核发送队列清空。如果刚调用 Write 就 Close，数据可能丢失；同时，对端可能已在关闭前发来最后几字节，不读就丢。
- 写完关键数据后，可调用
conn.SetWriteDeadline防止无限 hang，再Write+ 检查 err - 关闭前建议设一个短读超时（如 100ms），尝试读一次，避免遗漏最后一段响应
- 注意：多次调用
Close()是安全的，但不能再对已关闭连接进行读写
真正麻烦的从来不是“怎么连”，而是“连上之后怎么知道它还活着、数据有没有发全、对方回没回、回的是否完整”。这些细节不写进日志、不加 timeout、不检查 n，线上就容易静默失败。
