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 机制。
