Go net.Resolver PreferGo 改变解析结果时怎么排查

Go 程序在不同机器上解析同一个域名，结果不一致时，先不要急着改 DNS 地址。net.Resolver.PreferGo 只负责影响解析器选择：设为 true 时优先使用 Go 内置解析器；设为 false 时仍可能由平台和构建环境决定是否使用系统解析器。真正的差异还可能来自 resolv.conf、hosts、搜索域、A/AAAA 查询组合和 context 截止时间。

排查顺序应是“先确认走哪条解析路径，再比较错误和地址集合，最后单独判断超时”。PreferGo 改变的是解析方式，不会把一个错误域名变成正确域名；若两条路径看到的系统配置或网络环境不同，返回结果自然可能不同。

先确认 PreferGo 改的是什么

官方 net.Resolver 文档把 PreferGo 定义为：在平台允许时优先使用 Go 内置 DNS 解析器，它等价于对该解析器设置 GODEBUG=netdns=go 的偏好。这个字段不是“指定 DNS 服务器”，也不会改变域名记录。

因此第一轮记录应包括：运行平台、是否启用 cgo、GODEBUG、构建标签，以及使用的是默认 net.DefaultResolver 还是自定义 Resolver。如果同时设置了环境变量和 PreferGo，不要凭经验猜优先级；以当前二进制的实际配置和官方源码行为为准。

用同一个 context 对照两条解析路径

不要一边调用 LookupHost，另一边改用 LookupIPAddr；不同入口可能引入不同的地址处理逻辑。可以只改变 PreferGo，记录同一个主机名的地址集合、错误和耗时：

package main

import (
    "context"
    "fmt"
    "net"
    "time"
)

func lookup(host string, preferGo bool) ([]string, error) {
    // 每次比较都使用独立 Resolver，避免共享可变配置。
    resolver := &net.Resolver{PreferGo: preferGo}
    ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
    defer cancel() // 释放计时器，避免短任务留下定时器资源。

    addresses, err := resolver.LookupHost(ctx, host)
    if err != nil {
        // 同时保留 context 错误，便于区分超时和 DNS 返回错误。
        return nil, fmt.Errorf("preferGo=%t lookup %q: %w (context=%v)", preferGo, host, err, ctx.Err())
    }
    return addresses, nil
}

比较时至少保留三列：PreferGo 值、错误及 context.Err()、地址集合。地址顺序不同不一定是故障，尤其在多地址返回时；真正需要先处理的是一条路径成功、另一条路径失败，或者只返回 IPv4/IPv6 中的一部分。

检查查询配置与结果边界

两条路径的输入可能并不完全相同。系统解析器会遵循平台的名称服务配置；Go 内置解析器会读取它能识别的 DNS 配置，但不一定复现系统名称服务模块的全部行为。排查时逐项确认：

StrictErrors 只影响 Go 内置解析器处理临时错误的方式：对于 A+AAAA 或搜索域这类多子查询，它可以让错误终止整次请求，而默认策略可能保留部分结果。这个字段不能修复 DNS 服务；它只决定“不完整结果是否可接受”。

把超时与修复策略分开

超时不是“PreferGo 不好用”的充分证据。先检查 ctx.Err()，再看底层错误是否包含 DNS 服务失败；如果 context 已截止，继续增加 timeout 只能延后暴露问题。对有严格网络出口要求的服务，可以为自定义 Resolver 设置 Dial，把 DNS 连接指向明确的 IP 和端口，但要同时承担可用性、轮换和故障切换责任。

修复策略可以按这个顺序落地：默认场景保留 Go 的动态选择；只有确认系统解析器与 Go 解析器的行为差异会影响业务时，才在局部 Resolver 上固定 PreferGo；如果问题是搜索域、hosts 或 DNS 服务配置，则修环境而不是改代码；如果只是不接受部分结果，再评估 StrictErrors。

常见问题

PreferGo 设为 false 就一定使用 cgo 吗？

不一定。它表示不偏好 Go 内置解析器，最终选择仍受平台、构建能力和其他 DNS 配置影响。

为什么两个 Resolver 返回的地址顺序不同？

返回顺序可能受解析路径、协议族和系统排序影响。先比较集合、错误与可连接性，不要仅因顺序变化就判定 DNS 错误。

StrictErrors 应该默认打开吗？

不能一概而论。打开后多子查询中的临时错误可能使整次查询失败；只有业务不能接受部分地址时才适合明确评估。

小结：遇到 net.Resolver.PreferGo 改变结果，先固定比较条件，再把解析器选择、DNS 配置、子查询策略和 context 超时拆开观察。证据指向哪一层，就只修哪一层。