如何在Golang中捕获网络连接错误_GolangTCP UDP连接异常管理

net.Dial错误不全是net.Error，可能为os.SyscallError或errors.errorString，应使用errors.Is或errors.As判断；udp错误发生在WriteTo/ReadFrom而非DialUDP；TCP连接分建立与通信两阶段，超时需用context.Context统一控制。

go 中 net.Dial 返回的错误类型不全是 net.Error

很多人以为 net.Dial 失败时一定返回实现了 net.Error 接口的错误，可以安全断言。但实际中，dns 解析失败（如域名不存在）常返回 *net.OpError，而某些系统级错误（如 “no route to host”）可能包装为 *os.SyscallError，甚至极少数情况是纯 *errors.errorString。直接 err.(net.Error) 会 panic。

• 正确做法是用 errors.Is 或 errors.As 判断底层原因，例如：

  if errors.Is(err, syscall.ECONNREFUSED) { /* 被拒绝 */ }

• DNS 类错误通常可通过检查 err.Error() 是否包含 "lookup" 或使用 net.ParseIP(host) == nil 提前探测
• UDP 的 net.DialUDP 同样适用该逻辑，但注意：UDP 是无连接协议，DialUDP 只做地址解析和 socket 初始化，真正错误往往出现在第一次 WriteTo 时

区分 TCP 主动连接失败与连接后中断

TCP 连接分两个阶段出错：建立阶段（net.Dial）、通信阶段（Read/Write）。前者错误多属网络可达性问题；后者则可能是对端崩溃、防火墙中断、KeepAlive 超时等，错误类型和重试策略完全不同。

• net.Dial 失败：常见 connection refused、timeout、no route to host，适合指数退避重试
• conn.Read 返回 io.EOF 表示对端正常关闭；返回 io.ErrUnexpectedEOF 或 read: connection reset by peer 往往意味着异常中断，需重建连接
• 务必检查 conn.SetReadDeadline 和 conn.SetWriteDeadline，否则阻塞读写可能永久挂起

UDP 连接错误只在发送/接收时暴露

UDP 没有“连接”概念，net.DialUDP 成功仅表示本地 socket 创建成功且远端地址可解析。真正的网络错误（如目标主机不可达、ICMP port unreachable）要到第一次 WriteTo 或 ReadFrom 才触发，且错误可能延迟返回（尤其 ICMP 错误依赖路由器响应）。

• 不要依赖 DialUDP 的返回值判断服务是否可用；必须发送探测包并等待响应或超时
• UDP 错误常为 *net.OpError，其 Err 字段可能是 syscall.EHOSTUNREACH 或 syscall.EPORTUNREACH，需用 errors.As 提取
• 若用 net.ListenUDP + WriteTo，错误同样发生在 WriteTo，而非监听阶段

如何统一处理超时与取消

硬编码 time.Sleep 重试不可靠；应优先使用 context.Context 控制整个连接生命周期，包括 DNS 解析、TCP 握手、I/O 操作。

立即学习“go语言免费学习笔记（深入）”；

• 用 net.Dialer 配合 Context：

  d := &net.Dialer{Timeout: 5 * time.Second, KeepAlive: 30 * time.Second} conn, err := d.DialContext(ctx, "tcp", "example.com:80")

• 对 UDP，DialUDP 不支持 context，但可用 net.ListenUDP + WriteTo 组合，并在 WriteTo 前设置 conn.SetWriteDeadline 实现超时
• 注意：context.WithTimeout 的 cancel 函数必须调用，否则 goroutine 泄漏；defer cancel() 是基本操作

真正麻烦的是 ICMP 错误的不可靠性——它可能永远不回来，也可能延迟数秒才到。别指望靠它判断服务状态，UDP 健康检查必须自己设计应用层心跳或 ACK 机制。