17370845950

Go 中 net.Dial 失败时返回非 nil 的 error 且 conn 为 nil；典型错误是未检查 err 就操作 nil conn 导致 panic，err 通常是 *net.OpError，可断言判断超时或 syscall.ECONNREFUSED 等底层原因。

Go 中 net.Dial 失败时返回什么错误

Go 的 net.Dial（包括 net.DialTCP、net.DialUDP）在连接失败时**不会返回 nil，而是返回一个非 nil 的 error，且返回的 conn 为 nil**。这是最常被忽略的前提——很多新手会直接对 conn 调用 Close() 或写入，导致 panic。

典型错误现象：panic: runtime error: invalid memory address or nil pointer dereference

• 必须先检查 err != nil，再使用 conn
• err 类型通常是 *net.OpError，可类型断言获取底层原因（如超时、拒绝连接、无路由等）
• 常见底层错误值：syscall.ECONNREFUSED（连接被拒）、syscall.ETIMEDOUT（超时）、syscall.ENETUNREACH（网络不可达）

如何区分 TCP 连接超时和连接拒绝

默认 net.Dial 没有超时控制，会卡住直到系统级超时（可能长达数分钟）。必须显式设置超时，否则无法可靠区分“暂时连不上”和“服务根本不存在”。

conn, err := net.DialTimeout("tcp", "127.0.0.1:9999", 3*time.Second)
if err != nil {
    var opErr *net.OpError
    if errors.As(err, &opErr) {
        if opErr.Timeout() {
            fmt.Println("连接超时")
        } else if opErr.Err != nil {
            if errors.Is(opErr.Err, syscall.ECONNREFUSED) {
                fmt.Println("连接被拒绝（目标端口无服务）")
            }
        }
    }
    return
}

• DialTimeout 仅控制连接建立阶段，不控制后续读写
• opErr.Timeout() 判断是否为超时类错误（含 DNS 解析超时、TCP 握手超时）
• errors.Is(opErr.Err, syscall.ECONNREFUSED) 是判断“拒绝连接”的安全方式，比字符串匹配更可靠

UDP 请求如何判断发送失败

UDP 是无连接协议，net.DialUDP 成功只表示本地 socket 创建成功，WriteTo 或 Write **几乎不会返回错误**——即使目标主机宕机、端口关闭、ICMP 目标不可达，操作系统通常也不通知应用层。

这意味着：UDP 发送失败无法在调用时捕获，只能靠业务层超时 + 重传 + 应答机制保障可靠性。

• 若需感知目的端可达性，可搭配 net.ListenUDP + ICMP 探测（需 root 权限），或发后立即 ReadFrom 等应答（要求对方配合）
• WriteToUDP 返回 n, nil 不能说明数据已送达，仅表示已交给内核发送队列
• 唯一常见错误是本地资源不足（如 EMFILE 打开文件数超限），或地址格式错误（invalid argument）

HTTP 客户端错误处理要覆盖哪些底层网络错误

Go 的 http.Client 底层仍基于 net.Conn，其 Do 方法返回的 *url.Error 包含原始网络错误，但容易被忽略。

resp, err := http.DefaultClient.Do(req)
if err != nil {
    var urlErr *url.Error
    if errors.As(err, &urlErr) {
        if urlErr.Timeout() {
            log.Println("HTTP 请求超时:", urlErr.Err)
        } else if netErr, ok := urlErr.Err.(net.Error); ok && netErr.Timeout() {
            log.Println("底层网络超时")
        } else if strings.Contains(err.Error(), "connection refused") {
            log.Println("目标服务未启动")
        }
    }
    return
}

• url.Error 的 Timeout() 方法能统一识别所有超时场景（DNS、连接、TLS、读响应头）
• 不要只检查 resp.StatusCode，err != nil 时 resp 为 nil
• HTTP/2 场景下，某些连接复用错误可能表现为 http: server closed idle connection，属于可重试错误

TCP 连接错误的细节藏在 *net.OpError 里，UDP 根本不报错，HTTP 错误又套了多层包装——真正难的不是写 if err != nil，而是知道该断言什么类型、该查哪个字段、该容忍哪类失败。