Go DNS 查询超时时为什么 context 已取消仍有延迟

Go 的 DNS 查询超时后，context 已取消却仍能看到延迟，并不一定是取消失效。先看你调用的是不是 Resolver.LookupHost(ctx, host)：包级 net.LookupHost 会在内部使用 context.Background，无法接收你的请求上下文。即使传对了 context，也要区分“调用方已经返回”和“底层解析工作完全停止”这两个时间点。

排查顺序应是：确认调用入口，再判断实际使用纯 Go 解析还是 cgo，最后看 DNS 配置导致的重试与搜索域。纯 Go 路径通常能用连接 deadline 结束请求；cgo 路径可能先返回取消错误，而底层阻塞的系统调用仍在运行。

先确认是不是把 context 传给了可取消的查找

第一处最常见的误判是给上层 HTTP 请求设置了超时，却在 DNS 位置调用了没有 context 参数的函数。下面的两个调用看起来相近，行为却不同：

ctx, cancel := context.WithTimeout(context.Background(), 300*time.Millisecond)
defer cancel() // 释放超时定时器

// 错误示例：包级函数内部使用 Background，ctx 不会传入 DNS 查询。
addrs, err := net.LookupHost("api.example.test")

// 正确入口：让 Resolver 看到同一个 ctx。
resolver := &net.Resolver{}
addrs, err = resolver.LookupHost(ctx, "api.example.test")
if err != nil {
    // 先判断上下文，再读取 DNSError 的具体信息。
    if errors.Is(err, context.DeadlineExceeded) || errors.Is(err, context.Canceled) {
        log.Printf("dns canceled: %v", err)
    }
}

如果 ctx.Err() 已经非空，查找可能直接返回；如果错误被中间层包装，使用 errors.Is 比比较错误字符串可靠。还要记录“开始查找”“收到返回”“ctx.Done 关闭”三个时间点，否则日志中的“取消”很容易被误读成“底层 socket 已关闭”。

纯 Go 解析为什么还会看到多次等待

在 Unix 上，Go 通常优先使用内置解析器，但系统配置或平台条件可能让它改用 cgo。纯 Go 路径不是“一次 UDP 请求”：它会读取 /etc/resolv.conf 中的 nameserver 和 timeout/attempts 配置，按需要尝试多个服务器；UDP 响应被截断时还可能回退 TCP。对未带结尾点的名字，搜索域也可能产生多个候选名称；地址查询还可能同时涉及 A 与 AAAA。

每个 DNS 连接都会设置由 context 派生出的 deadline，所以总耗时通常是若干次小等待叠加，而不是简单等于一次 WithTimeout。若同一主机被并发查询，Resolver 还会合并同 key 的请求；取消的调用方可以先返回，但共享查找可能为了其他调用继续。

因此，“取消后抓包仍有 DNS 包”并不能直接证明 context 没生效。应同时记录 resolver 模式、查询名是否带搜索域、A/AAAA 数量、nameserver 数量和调用方返回时间。

cgo 解析为何返回了错误但后台仍有延迟

cgo 路径调用系统 C 库的解析函数。Go 源码对这类不支持 context 的阻塞操作采用单独 goroutine 等待：context 先结束时，调用方可以得到一个对应的 DNS 错误，但注释明确说明 blocking function 可能在该函数返回后继续运行。于是你会同时看到两件事：业务请求已经快速失败，进程里的解析线程或系统 resolver 仍在收尾。

这也是“接口耗时”和“资源恢复耗时”不一致的来源。不要在收到 context deadline exceeded 后立即把所有延迟归咎于 DNS 服务器；先确认是否发生了 cgo 选择、是否存在大量并发查询，以及是否把取消后的 goroutine/线程数量当成了单次请求耗时。

一套可定位的 Go 写法

生产代码可以把 resolver 作为依赖显式注入，并为一次业务请求设置总 deadline。需要诊断模式时，可临时强制纯 Go 解析；不要把它当成所有平台的永久修复。

func lookup(ctx context.Context, host string) ([]string, error) {
    ctx, cancel := context.WithTimeout(ctx, 500*time.Millisecond)
    defer cancel() // 无论成功或失败都释放定时器

    r := &net.Resolver{PreferGo: true}
    start := time.Now()
    addrs, err := r.LookupHost(ctx, host)
    elapsed := time.Since(start)
    if err != nil {
        var dnsErr *net.DNSError
        if errors.As(err, &dnsErr) {
            log.Printf("dns host=%s elapsed=%s timeout=%t temporary=%t err=%v",
                host, elapsed, dnsErr.Timeout(), dnsErr.Temporary(), dnsErr)
        }
        return nil, err
    }
    log.Printf("dns host=%s elapsed=%s addrs=%d", host, elapsed, len(addrs))
    return addrs, nil
}

PreferGo: true只影响这个 Resolver；全局诊断也可以临时使用 GODEBUG=netdns=1 查看选择结果。若必须接入指定 DNS 服务，可使用 Resolver.Dial，但自定义拨号函数同样要尊重传入的 context，不能重新创建一个永不过期的连接上下文。

线上排查清单

1. 确认调用点使用的是 LookupHost(ctx, host) 或同类带 context 的方法。
2. 记录 errors.Is 结果、DNSError.Timeout()、总耗时和 host 是否为完整域名。
3. 用 GODEBUG=netdns=1 或构建环境信息确认纯 Go/cgo 选择，不要只凭操作系统猜测。
4. 检查 /etc/resolv.conf 的 nameserver、timeout、attempts、search 和 ndots；修改前先确认它由谁管理。
5. 若调用方已返回但线程或 DNS 包仍增长，重点看 cgo 阻塞、共享查找和取消后的后台工作，而不是盲目缩短业务超时。

官方资料可对照 net 包文档、LookupIPAddr 实现、纯 Go DNS 客户端实现 和 cgo 解析实现。它们分别说明 resolver 选择、共享查找、连接 deadline 与阻塞调用的取消边界。

相关问题

context.Canceled 和 context.DeadlineExceeded 有什么区别？

前者通常表示主动取消或父 context 取消，后者表示 deadline 到期。两者都说明调用方不应继续等待，但不能单独说明底层解析采用了纯 Go 还是 cgo。

强制 PreferGo 就能保证立刻停止 DNS 吗？

不能把“立刻”当成保证。它能避开 cgo 选择，并让纯 Go 请求使用连接 deadline；服务器轮询、TCP 回退、搜索域和并发共享仍会影响观测到的收尾时间。

把“调用方何时返回”和“解析资源何时完全停止”分开记录，通常就能解释这类看似矛盾的日志。先修正入口，再确认 resolver 模式，最后收敛系统 DNS 配置，排查会比反复加大或减小一个超时值更快。