Go中用net.Dial建立TCP连接需调用net.Dial("tcp", "host:port", nil)，注意协议名、地址格式及默认30秒超时；应使用net.Dialer设置连接超时，SetRead/WriteDeadline控制读写超时；读取需处理分片与EOF，粘包需按协议解析；Close不保证数据发出，半开连接需心跳检测。
怎么用 net.Dial 建立基础 TCP 连接
Go 里写 TCP 客户端，核心就是 net.Dial —— 它负责发起连接、返回 conn，后续读写都靠它。别绕弯子，直接上最简可用代码：
conn, err := net.Dial("tcp", "127.0.0.1:8080", nil)
if err != nil {
log.Fatal(err)
}
defer conn.Close()注意两点："tcp" 是协议名（不是 "tcp4" 或 "tcp6"），除非你明确要限制 IPv4/IPv6；第二个参数是 "host:port" 字符串，不能漏冒号，也不能写成 "localhost:8080" 后又期望它总能解析——DNS 失败时会卡在连接阶段。
-
net.Dial默认有约 30 秒连接超时，线上服务必须自己控制 - 如果目标地址不存在或端口未监听，错误是
dial tcp 127.0.0.1:8080: connect: connection refused，不是 timeout - 不要在循环里反复调用
net.Dial却不 close，容易耗尽本地端口（TIME_WAIT状态堆积）
怎么设置连接超时和读写超时
默认不设超时，客户端可能卡死：连不上就一直等，连上了写一半就 hang 住。得用 net.Dialer 和 conn.SetDeadline 分开控制。
dialer := &net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
}
conn, err := dialer.Dial("tcp", "127.0.0.1:8080", nil)连接建立后，再设读写截止时间：
立即学习“go语言免费学习笔记（深入）”；
conn.SetDeadline(time.Now().Add(10 * time.Second)) // 读写共用 // 或分开设： conn.SetReadDeadline(time.Now().Add(5 * time.Second)) conn.SetWriteDeadline(time.Now().Add(5 * time.Second))
-
SetDeadline是绝对时间，每次读/写前都要重设，否则第二次操作会立即失败 -
SetReadDeadline影响Read，SetWriteDeadline影响Write，但不影响Close - 超时错误是
read: i/o timeout或write: i/o timeout，不是context deadline exceeded
怎么安全地收发字节流（别被 Read 卡住）
TCP 是流式协议，conn.Read 不保证一次读完所有数据，也不保证一次只读一个包。常见错误是直接 Read(buf) 就以为拿到了完整消息。
- 永远检查
n, err := conn.Read(buf)的n，它可能小于len(buf)，也可能为 0（对端关闭） - 遇到
err == io.EOF表示对方已关闭连接，不是异常，不用打日志报警 - 如果协议有长度头（比如前 4 字节是 body 长度），必须循环读够指定字节数，不能依赖单次
Read - 别用
bufio.Scanner处理非文本协议——它按行切分，TCP 包里根本没换行符
简单粘包处理示例（固定头 4 字节长度）：
var header [4]byte
_, err := io.ReadFull(conn, header[:])
if err != nil { return }
bodyLen := binary.BigEndian.Uint32(header[:])
body := make([]byte, bodyLen)
_, err = io.ReadFull(conn, body)
if err != nil { return }为什么 conn.Close 后还看到 broken pipe 错误
这不是 bug，是正常现象：你调了 Close，但之前发的 Write 还在内核缓冲区，对方已经断开，内核回包 RST，下次 Write 就触发 write: broken pipe。
- 错误发生在
Write调用时，不是Close时；Close本身几乎总是成功 - 别在
Close后还往 conn 写数据，也别假设Close会等所有数据发完（它不会） - 如需确保数据发出，先
SetWriteDeadline，再Write，最后Close；但依然无法 100% 保证对方收到 - 生产环境建议加
recover捕获 panic（比如往已关闭 conn 写），但更该从逻辑上避免
真正难处理的是半开连接（对方崩溃但没发 FIN）：你发数据过去，没人响应，只能靠心跳或读超时发现。这点容易被忽略，一卡就是几分钟。
