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)
连接建立后,再设读写截止时间:
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):你发数据过去,没人响应,只能靠心跳或读超时发现。这点容易被忽略,一卡就是几分钟。
golang免费学习笔记(深入):立即使用
在学习笔记中,你将探索golang的核心概念和高级技巧!











