Golang实现TCP客户端通信示例

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，或网络存在延迟/分片时，很容易只读到部分响应。

• 永远不要假设 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，线上就容易静默失败。