net.Dial 是 Go 中建立 TCP 连接最直接方式，需配置超时、检查错误、正确处理写入与关闭，并解决粘包、半包及假活问题。
如何用 net.Dial 建立 TCP 连接并发送数据
Go 中最直接的 TCP 客户端通信方式是调用 net.Dial，它返回一个实现了 io.ReadWriteCloser 的 net.Conn。只要连接成功，就能用 Write 发送字节流。
常见错误是忽略连接超时或写入阻塞：默认 net.Dial 不设超时，若服务端不可达，会卡在 SYN 重传（Linux 默认约 30 秒）；写入大块数据又没设写超时，可能长期挂起。
- 始终用
net.DialTimeout或更推荐的net.Dialer配置Timeout和KeepAlive - 发送前确认
conn != nil，且检查Write返回的n, err——n < len(data)表示只发了部分，需循环或改用io.WriteString/bufio.Writer - 不要在未关闭连接的情况下反复调用
Dial，容易触发 “too many open files”
conn, err := net.Dial("tcp", "127.0.0.1:8080", 5*time.Second)
if err != nil {
log.Fatal(err)
}
defer conn.Close()
_, err = conn.Write([]byte("HELLO\n"))
if err != nil {
log.Printf("write failed: %v", err)
}
为什么 Write 后要 Flush 或 Close 才能确保对方收到
TCP 是字节流协议，Write 只是把数据拷贝进内核 socket 发送缓冲区，不保证已发到对端。如果客户端写完立刻退出，而缓冲区还没来得及推送（比如 Nagle 算法延迟合并小包），服务端就收不到任何数据。
典型表现：服务端死等，Wireshark 看不到 FIN 或数据包；本地 strace 显示 write() 成功但无后续 send() 调用。
- 对短连接，写完后调用
conn.Close()—— 关闭会触发 FIN，并强制冲刷缓冲区 - 对长连接，用
bufio.NewWriter(conn)包装，写完调用Flush()；避免直接用WriteString后不 flush - 禁用 Nagle：
conn.(*net.TCPConn).SetNoDelay(true)，适合实时性要求高的场景（如游戏、指令控制）
如何处理粘包和半包问题
TCP 没有消息边界，Read 返回的 []byte 长度完全取决于内核当前可读字节数 —— 可能一次读到多个逻辑消息，也可能一个消息被拆成两次读取。这是应用层必须解决的问题，Go 标准库不自动处理。
常见误操作：用 Read 一次性读固定长度（如 1024），以为能截出完整请求；结果要么丢数据，要么阻塞等待填满。
- 协议层加长度头：先写 4 字节 uint32 表示后续 payload 长度，再读指定字节数 —— 用
binary.Read+io.ReadFull组合 - 用分隔符（如
\n）：配合bufio.NewReader的ReadString('\n')或ReadBytes('\n') - 避免在
for { conn.Read(...) }循环里直接处理业务逻辑，应先按协议拼出完整帧，再解析
连接异常时如何快速失败并重试
网络抖动、服务端重启、防火墙中断都会导致 Write 或 Read 突然返回 io.EOF、net.ErrClosed 或 syscall.ECONNRESET。如果没做判断，程序可能继续往已断开的连接写，得到 write: broken pipe 错误。
关键点在于：TCP 连接状态无法主动探测，只能靠 I/O 操作触发错误。心跳（如定期 Write 小包）能提前暴露问题，但增加复杂度。
- 每次
Read和Write后必须检查err，且区分临时错误（net.OpError.Temporary() == true）和永久错误 - 对临时错误（如
io.Timeout），可重试；对永久错误（如connection refused），应重建连接 - 用
context.WithTimeout控制单次读/写的最大耗时，防止 goroutine 卡死
真正麻烦的是连接“假活”：socket 还开着，但中间链路已断，此时 Write 仍成功（数据进了缓冲区），直到下次 Write 或 Close 才报错。这种场景下，应用层心跳几乎是必需的。
