应使用类型断言 err.(*net.OpError) 识别底层网络错误，因其结构体字段 Op、Net、Addr、Err 稳定可靠；需配合 errors.As 处理多层包装，并在访问 opErr.Err 前判空。
怎么用类型断言识别 net.OpError
Go 的 net 包里，底层网络错误（比如连接超时、拒绝连接、DNS 解析失败）基本都包装成 *net.OpError。直接用 err == nil 或 strings.Contains(err.Error(), "timeout") 不可靠——前者判不准，后者一换错误消息就崩。
正确做法是做类型断言：
if opErr, ok := err.(*net.OpError); ok {<br> // 这才是真正的底层网络操作错误<br>}注意必须用
*net.OpError（带星号），因为 net.Dial、conn.Write 等返回的都是指针类型错误。
为什么不能只看 Error() 字符串
err.Error() 是给人看的，不是给代码解析用的。不同 Go 版本、不同系统（Linux/macOS/Windows）、甚至不同网络栈（如启用了 SOCKS 代理）下，错误文本可能完全不同：
-
"dial tcp 10.0.0.1:8080: i/o timeout"（Go 1.19+ Linux） -
"dial tcp 10.0.0.1:8080: operation was canceled"（带 context.Cancel） -
"dial tcp: lookup example.com: no such host"（DNS 失败）
*net.OpError 结构体字段稳定：Op（操作名）、Net（协议）、Addr（地址）、Err（底层错误）——这些才是可信赖的判断依据。
常见误判场景和对应处理
不是所有网络相关错误都是 *net.OpError。容易混淆的有：
-
url.Error：HTTP 请求中http.Get返回的错误，外层是它，内层才可能是*net.OpError，需递归取err.Unwrap()或访问urlErr.Err -
context.DeadlineExceeded或context.Canceled：它们本身不是*net.OpError，但常和它一起出现（比如超时后触发 dial）。别试图对它们做*net.OpError断言，会失败 -
syscall.Errno（如syscall.ECONNREFUSED）：可能作为opErr.Err出现在*net.OpError内部，而不是独立顶层错误
if opErr, ok := err.(*net.OpError); ok && opErr.Err != nil {<br> var se syscall.Errno<br> if errors.As(opErr.Err, &se) {<br> switch se {<br> case syscall.ECONNREFUSED:<br> // 处理连接拒绝<br> case syscall.ENETUNREACH:<br> // 处理网络不可达<br> }<br> }<br>}
为什么 errors.Is 和 errors.As 更安全
Go 1.13+ 推荐用 errors.Is 和 errors.As 替代裸断言，尤其当错误被多层包装时（比如 http.Client + context + net）。errors.As 能穿透嵌套，比手动 err.(*net.OpError) 更鲁棒：
var opErr *net.OpError<br>if errors.As(err, &opErr) {<br> // 成功拿到 *net.OpError，不管它被包了几层<br>}而 errors.Is(err, syscall.ECONNREFUSED) 在某些场景下也能直接命中底层 errno，省去解包步骤。但注意：errors.Is 对 *net.OpError 本身不生效（它不是 error 值相等），只能用于其内部的 Err 字段。
立即学习“go语言免费学习笔记（深入）”；
最易忽略的一点：*net.OpError 的 Err 字段可能为 nil（比如某些内部逻辑提前返回），不做空检查直接解包会 panic。每次取 opErr.Err 前，先判空。
