Go Resolver LookupHost 为什么在容器里结果顺序变化

Go 的 Resolver.LookupHost 返回的是本地解析器得到的地址切片，不是“第一项永远主用、第二项永远备用”的业务契约。容器里的 /etc/resolv.conf、/etc/hosts、网络命名空间和 Go/cgo 解析路径可能与宿主机不同，A/AAAA 结果经过不同处理后，顺序变化是正常现象。

稳定做法是把返回值当作候选集合：先记录解析路径，再在应用层把地址解析成 netip.Addr，按明确的 IPv4/IPv6 或区域策略排序，最后逐个连接并处理失败回退。

官方事实入口：https://pkg.go.dev/net#Resolver.LookupHost

LookupHost 没有承诺业务优先级

官方文档对 LookupHost 的承诺很短：使用本地 resolver 查找主机，并返回该主机的地址切片。文档没有把切片位置定义为主备、延迟最小或固定 DNS 记录顺序。若代码直接取 addrs[0]，实际上把环境细节当成了产品规则。

同一域名同时拥有 IPv4 和 IPv6 时，结果还会受到地址族、系统 resolver、DNS 响应和排序规则影响。Go 的 Unix 内置 resolver 源码会处理 /etc/hosts、DNS 查询并按 RFC 6724 相关规则整理地址，但这不等于所有平台、所有解析路径都给出你期望的首项。

先对照容器的三个输入

排查时不要先改排序代码。先在同一镜像、同一网络模式和同一域名下比较以下内容：

容器中不要只打印最终切片。把配置摘要、GODEBUG=netdns=go+2 或 netdns=cgo+2 的对照结果写入一次性排障日志；敏感环境只记录 nameserver 的网段或哈希，不要把完整内部域名和地址写入公共日志。

用受控对照确认 Go 或 cgo 路径

如果只是想确认解析路径，可以给单次 resolver 设置 PreferGo，不要把它误解成“固定返回顺序”的开关。它只控制在可用平台上是否优先使用 Go 内置 DNS resolver。

package main

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

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel() // 及时释放定时器，避免诊断程序长期持有资源

    resolver := &net.Resolver{PreferGo: true}
    addrs, err := resolver.LookupHost(ctx, "service.example")
    if err != nil {
        // 记录错误类型和阶段，不把内部 DNS 地址直接写入公共日志。
        fmt.Printf("lookup failed: %v\n", err)
        return
    }
    // 这里只展示原始候选，不把第一项当成业务主地址。
    fmt.Printf("resolver candidates: %v\n", addrs)
}

这段代码的价值是建立对照样本。把 PreferGo 改为默认值，或通过进程级 GODEBUG 做另一组实验，再比较候选集合和顺序。生产环境不建议为了“看起来固定”强行锁死解析路径，除非你已经确认目标平台和 NSS 行为，并愿意承担升级后的差异。

把地址顺序改成应用层显式策略

如果业务确实需要“先尝试 IPv6，失败后尝试 IPv4”或反过来，就把规则写出来并测试。下面示例把地址解析为 netip.Addr，先按地址族分组，再以字符串形式做稳定的次级排序；它不声称哪种地址族一定更快。

package main

import (
    "fmt"
    "net/netip"
    "sort"
)

// orderAddrs 将 DNS 候选转成可比较地址，并明确 IPv4 优先规则。
func orderAddrs(raw []string) []netip.Addr {
    out := make([]netip.Addr, 0, len(raw))
    for _, text := range raw {
        addr, err := netip.ParseAddr(text)
        if err != nil {
            // 单个异常记录不应让其他可用地址全部丢失。
            continue
        }
        out = append(out, addr)
    }
    sort.SliceStable(out, func(i, j int) bool {
        // 业务规则：IPv4 先于 IPv6；同族再按规范化文本稳定排序。
        if out[i].Is4() != out[j].Is4() {
            return out[i].Is4()
        }
        return out[i].String() 

如果业务不是 IPv4 优先，而是优先同地域、同可用区或最近探测成功的地址，就替换比较函数，不要继续依赖 DNS 的返回位置。连接层还应限制单个地址的尝试时间，并在所有候选失败后保留原始错误上下文。

上线前补齐四个边界测试

• 同一域名返回多条 IPv4，验证排序是否与业务规则一致。
• 同时返回 IPv4 和 IPv6，验证地址族策略，而不是只断言 addrs[0]。
• 容器内只有一个可用地址或 DNS 暂时失败，确认能区分空结果、解析错误和连接错误。
• 修改 resolv.conf 或切换 Go/cgo 对照后，确认日志能说明环境差异，且不会泄露内部 DNS 细节。

一句话收束：容器改变的是解析环境，LookupHost 只负责给出候选地址；真正的主备、地址族和回退规则，应由应用层明确表达。

常见问题

能不能直接对 LookupHost 的结果调用 sort.Strings？ 可以作为简单稳定化手段，但它不表达 IPv4/IPv6、地域或健康度策略。生产代码最好先解析成 netip.Addr，再按业务规则比较。

PreferGo: true 能彻底解决容器顺序变化吗？ 不能。它只改变可用平台上的 resolver 路径，DNS 响应、hosts 文件和地址族仍可能改变候选集合。

为什么同一个域名每次顺序还可能不同？ DNS 响应、缓存、地址族查询和平台排序都可能参与结果形成。除非业务自己排序，否则不要把一次输出当作稳定协议。

容器排查应该先改应用还是先改 DNS？ 先比较配置和解析路径，确认是环境差异还是业务误用；若业务确实需要优先级，再在应用层实现可测试的策略。