Go中判断网络超时应使用errors.Is(err, context.DeadlineExceeded)或类型断言net.Error.Timeout()；区分HTTP错误需用errors.As解包至net.DNSError、net.OpError、*tls.HandshakeError；net.Dial错误须逐层解包再判断系统errno；自定义Transport时应在DialContext中透传并增强连接错误。
Go 中判断网络连接是否超时
Go 的网络错误本身不直接提供 IsTimeout() 这类方法，但标准库中所有基于 net.Conn 的操作（如 http.Client、net.Dial、conn.Read()）在超时时返回的错误，**一定实现了 net.Error 接口**。关键就在这里：你要用类型断言或 errors.Is() 去识别它。
常见误写是直接比对错误字符串，比如 err.Error() == "i/o timeout" —— 这不可靠，不同系统/版本返回的字符串可能不同（Windows 可能带中文，某些环境带额外空格或前缀）。
- 正确方式一（推荐 Go 1.13+）：
if errors.Is(err, context.DeadlineExceeded) { // 请求级超时（如 http.Client.Timeout） } - 正确方式二（底层连接级）：
if nerr, ok := err.(net.Error); ok && nerr.Timeout() { // 底层读/写/拨号超时，如 dial timeout、read timeout } - 注意：
context.DeadlineExceeded和nerr.Timeout()不等价：前者是上下文取消导致的逻辑超时，后者是底层 I/O 操作真实阻塞超限，二者可能同时出现，但语义不同
HTTP 客户端如何区分 DNS 失败、连接拒绝、TLS 握手失败
Go 的 http.Client 错误堆栈通常很长，但根源错误藏在最内层。直接看 err.Error() 很难定位，必须层层解包。
典型场景下，错误链结构是：*url.Error → 底层 net.OpError → 具体错误（*net.DNSError / *net.OpError / *tls.HandshakeError 等）。
立即学习“go语言免费学习笔记（深入）”；
- DNS 解析失败：
var dnsErr *net.DNSError if errors.As(err, &dnsErr) { log.Printf("DNS error: %v, is not found? %v", dnsErr.Err, dnsErr.IsNotFound) } - 连接被拒（如目标端口未监听）：
var opErr *net.OpError if errors.As(err, &opErr) && opErr.Err != nil { if strings.Contains(opErr.Err.Error(), "connection refused") { // 注意：不建议字符串匹配，仅作说明；实际应结合 syscall.Errno 判断 } } - TLS 握手失败（证书问题、协议不支持等）：
var tlsErr *tls.HandshakeError if errors.As(err, &tlsErr) { log.Printf("TLS handshake failed: %v", tlsErr) }
为什么 net.Dial 返回的错误不能直接用 errors.Is(err, syscall.ECONNREFUSED)
因为 net.Dial 封装后返回的是 *net.OpError，原始系统错误被嵌套在它的 Err 字段里。直接对顶层错误调 errors.Is 会失败。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
必须先解包到内层错误，再判断系统码。而且不同平台 errno 值不同（Linux 是 111，macOS 是 61），所以更稳妥的方式是结合 errors.As + 类型判断，而非硬编码 errno。
- 错误示范：
if errors.Is(err, syscall.ECONNREFUSED) { /* 永远 false */ } - 正确做法：
var opErr *net.OpError if errors.As(err, &opErr) { var sysErr syscall.Errno if errors.As(opErr.Err, &sysErr) { switch sysErr { case syscall.ECONNREFUSED: log.Println("connection refused") case syscall.ENETUNREACH: log.Println("network unreachable") } } } - 补充：若只关心“是否连不上”，用
opErr.Timeout()或opErr.Temporary()更实用 —— 前者表示可重试超时，后者表示临时性错误（如连接拒绝、网络不可达），都返回true
自定义 HTTP Transport 时如何统一捕获连接建立阶段异常
默认 http.DefaultTransport 对连接失败（DNS、dial、TLS）只返回泛化错误，不利于精细化重试或监控。你需要替换 Transport.DialContext 或 Transport.DialTLSContext，把底层错误透传出来或打标。
一个轻量做法是包装 net.Dialer，在 DialContext 返回错误时记录并增强上下文：
transport := &http.Transport{
DialContext: func(ctx context.Context, network, addr string) (net.Conn, error) {
conn, err := (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext(ctx, network, addr)
if err != nil {
// 在这里可以加日志、指标、或包装错误
return nil, fmt.Errorf("dial failed for %s: %w", addr, err)
}
return conn, nil
},
}注意：不要在 DialContext 里做重试 —— http.Client 本身不重试连接失败，且重试逻辑应由业务层控制（比如配合 backoff.Retry）。这里只做可观测性增强。
真正容易被忽略的是：即使你设置了 Transport.IdleConnTimeout，它只影响空闲连接复用，**不影响新建连接的超时控制**——新建连接超时由 Dialer.Timeout 决定，务必显式设置。
