Go net.Resolver LookupIP 取消后为什么仍可能看到部分地址

我第一次排查“DNS 取消后还剩几个地址”时，先怀疑的是 Go 的解析器。后来对照 net.Resolver.LookupIP 的返回路径才发现：标准库不会把取消时已经解析到的半截列表当成成功结果返回。取消分支是 nil, error；如果日志里仍出现部分 IPv4 或 IPv6，通常是调用方保留了旧切片、先打印了中间结果，或者并发封装把另一次查询的结果混到了当前请求里。

处理 LookupIP 的原则很简单：只有 err == nil 才替换业务地址列表；一旦 Context 被取消或超时，丢弃本次返回值，并用 ctx.Err() 区分调用方取消与 DNS 自身失败。

官方文档：https://pkg.go.dev/net

先确认取消时 LookupIP 的返回契约

Resolver.LookupIP(ctx, network, host) 的成功结果是 IPv4/IPv6 地址切片，network 可以是 ip、ip4 或 ip6。但这不代表解析器会边收到 DNS 响应边把结果交给调用方。源码在 Context 完成后直接构造 DNS 错误并返回 nil 地址；底层查找如果已经有错误，返回路径同样先丢弃地址。

因此，“部分地址”不能当作取消场景下的稳定 API 语义。最常见的假象是复用了上一次成功的变量：

var cached []net.IP

func lookup(ctx context.Context, r *net.Resolver, host string) ([]net.IP, error) {
    // 只有本次查询成功，才覆盖旧结果，避免取消后继续使用旧切片。
    addrs, err := r.LookupIP(ctx, "ip", host)
    if err != nil {
        return nil, err
    }
    cached = append(cached[:0], addrs...)
    return append([]net.IP(nil), cached...), nil
}

用一次调用区分取消、超时和 DNS 失败

排查时先看 ctx.Err()，再看返回错误。调用方主动取消通常对应 context.Canceled，截止时间耗尽对应 context.DeadlineExceeded；如果 Context 还没结束，才继续判断 net.DNSError 的超时或解析失败属性。不要因为地址切片非空就跳过错误判断，也不要在错误分支把旧变量返回给连接池。

func resolve(ctx context.Context, r *net.Resolver, host string) ([]net.IP, error) {
    // network 用 ip 同时请求 IPv4 与 IPv6；需要单一地址族时改用 ip4 或 ip6。
    addrs, err := r.LookupIP(ctx, "ip", host)
    if err != nil {
        // 先判断上游状态，避免把用户取消误记成 DNS 故障。
        if errors.Is(ctx.Err(), context.Canceled) {
            return nil, fmt.Errorf("解析被调用方取消: %w", ctx.Err())
        }
        if errors.Is(ctx.Err(), context.DeadlineExceeded) {
            return nil, fmt.Errorf("解析超过请求截止时间: %w", ctx.Err())
        }
        return nil, fmt.Errorf("解析 %s 失败: %w", host, err)
    }
    if len(addrs) == 0 {
        // nil 错误但空列表仍不适合交给后续拨号逻辑，按业务决定是否重试。
        return nil, fmt.Errorf("解析 %s 没有地址", host)
    }
    return addrs, nil
}

这里的关键不是把错误包装得更长，而是让“本次调用的结果”与“上一次成功结果”彻底分开。日志可以记录 host、network、地址数量和 ctx.Err()，但不要记录或展示未确认成功的中间地址。

并发相同主机查询为什么会让现象看起来更复杂

Go 的解析实现会对相同 resolver 和主机的并发查找做合并。一个调用的 Context 取消后，当前调用会尽快返回；如果还有别的调用正在等待同一主机，底层查找可能继续完成，后续调用可以共享这个结果。这是资源复用，不是“取消调用返回部分地址”。

容易出错的封装是：多个 goroutine 共用一个可写的包级切片，或把结果通过无标签 channel 发给请求方。这样第二个请求成功写入的地址可能被第一个请求的日志读到。每次调用都应返回自己的切片副本，并把请求 ID 与 host 绑定。

把地址列表交给拨号前的检查清单

如果解析结果随后用于 net.Dialer，建议在边界处做四个检查：第一，调用是否使用了带截止时间的 Context；第二，是否只在 err == nil 时更新缓存；第三，是否复制了切片，避免异步写入；第四，是否把空结果、取消和 DNS 失败分成不同指标。不要为了“保住部分地址”而忽略取消，因为那些地址没有通过这一次调用的成功契约。

常见问题

LookupIP 会返回“部分地址 + error”吗？

标准 Resolver 的公开返回路径不会把取消或解析错误下的部分地址作为成功结果交给调用方；如果看到这种形态，应先检查自定义 resolver、缓存和日志变量。

取消后底层 DNS 查询一定立刻停止吗？

不一定。当前调用会返回取消错误；当有其他相同主机的调用共享查找时，底层工作可能继续完成，以便服务其他调用。