Go net.Resolver 纯 Go DNS 解析为什么和系统不同怎样构造最小复现

如果同一个 Go 服务在开发机和容器里解析同一域名时出现地址顺序不同、搜索域不一致，甚至一个环境成功另一个环境失败，先不要把锅甩给 DNS 服务器。net.Resolver 可能选择了不同的解析实现：纯 Go 解析器会直接发 DNS 请求，系统解析路径则通常通过 cgo 调用操作系统库。

PreferGo: true 只表达“这个 Resolver 优先使用 Go 内置解析器”；要判断真实分流，还要结合 GODEBUG=netdns=go/cgo、操作系统、/etc/resolv.conf 和系统解析配置。最小复现应固定 Dial 返回的 DNS 响应，不要依赖公网域名的偶然结果。

本文解决：从一个具体的“解析结果不一致”症状开始，区分两条解析路径，构造可控的最小示例，并把选择逻辑固化成回归测试。

先分清纯 Go 和系统解析走的是哪条路径

Go 在 Unix 上主要有纯 Go 和 cgo 两种解析方式。纯 Go 路径读取系统 DNS 配置并直接发送 DNS 请求；cgo 路径调用系统库，可能额外遵循搜索域、别名或操作系统自己的解析策略。它们都叫“解析域名”，但输入配置和错误边界并不完全相同。

net.Resolver 的 PreferGo 字段是最小控制点。设置为 true 后，该 Resolver 偏好 Go 内置解析器；它不是把系统配置复制到 Go 结构体里，也不是保证所有平台永远绕过系统库。默认选择还会受平台和环境变量影响。

package main

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

func main() {
	// PreferGo 只作用于这个 Resolver，便于把选择范围限制在一次查询。
	resolver := &net.Resolver{PreferGo: true}
	addrs, err := resolver.LookupHost(context.Background(), "example.com")
	if err != nil {
		// 解析失败时保留原始错误，后续可与 netdns 调试信息对照。
		fmt.Println("lookup error:", err)
		return
	}
	fmt.Println("addresses:", addrs)
}

这段代码适合说明入口，不适合当作确定性测试：真实 DNS 会变化，平台也可能触发不同的解析分流。排障时应先确认“同一个 Resolver 是否真的设置了 PreferGo”，再看进程启动环境里的 GODEBUG。

用 netdns 调试信息确认实际解析器

只看业务返回值，无法判断差异来自解析器选择、配置文件还是 DNS 响应。可以在一次诊断运行中设置 GODEBUG=netdns=1 观察 Go 的决策信息；需要强制路径时，再使用 netdns=go 或 netdns=cgo 做对照。

# 只在一次诊断运行中打印解析器决策，不把调试开关永久写入服务配置
GODEBUG=netdns=1 go run ./cmd/dnsprobe example.com

# 强制使用 Go 内置解析器，和上一条结果对比
GODEBUG=netdns=go go run ./cmd/dnsprobe example.com

# 强制优先使用系统解析路径；没有可用 cgo 时可能退回或报错
GODEBUG=netdns=cgo go run ./cmd/dnsprobe example.com

对比时记录四项信息：进程启动参数、GODEBUG 值、机器上的 DNS 配置和最终错误/地址列表。不要把“地址顺序不同”直接等同于“解析器坏了”，因为不同实现可能遵循不同的排序和系统策略。

在 Unix 环境里，LOCALDOMAIN、RES_OPTIONS、HOSTALIASES 等环境设置也可能让默认选择偏向 cgo。另一方面，macOS、Windows、Android 等平台有各自的兼容性考虑，不能把 Linux 上观察到的默认路径原样套用到所有系统。

把“同域名不同结果”缩小为三个可控变量

一个可复现的排障记录至少要把变量拆成三层：

如果你只是想比较解析器选择，不需要真的访问公网。给自定义 Resolver 提供一个测试用 Dial，让它连接到固定的本地测试地址，再让测试桩返回预设响应。这样测试的结论是“选择和处理逻辑是否符合预期”，不是“此刻公网 DNS 返回什么”。

用可控 Dial 把差异写成回归测试

下面的测试把“是否偏好纯 Go”作为表格输入，并把网络层替换成一个可替换的 Dial 函数。示例省略 DNS 报文编码细节，重点是测试边界：配置由测试表控制，解析结果由固定响应控制，业务断言不依赖真实域名。

package resolver_test

import (
	"context"
	"net"
	"testing"
	"time"
)

func TestResolverPreferenceIsExplicit(t *testing.T) {
	tests := []struct {
		name      string
		preferGo  bool
		wantLabel string
	}{
		{"pure-go preference", true, "go"},
		{"system preference", false, "system"},
	}

	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			resolver := &net.Resolver{
				PreferGo: tt.preferGo,
				Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
					// 测试桩不访问真实 DNS，只返回可识别的固定连接。
					return newFixedDNSConn(tt.wantLabel), nil
				},
			}
			ctx, cancel := context.WithTimeout(context.Background(), time.Second)
			defer cancel() // 防止测试失败时遗留超时上下文。

			// 业务代码应把 LookupHost 的结果和错误一起交给断言层。
			_, _ = resolver.LookupHost(ctx, "service.test")
			assertDialLabel(t, tt.wantLabel)
		})
	}
}

// newFixedDNSConn 和 assertDialLabel 由测试桩实现，用于记录调用路径。
// 这里省略 DNS 报文编解码，避免把网络库细节混入解析器选择测试。

真实项目中，测试桩需要返回合法的 DNS 响应，或把“调用了哪条 Dial 路径”记录到线程安全的测试状态中。关键是不要让测试同时依赖公网、宿主机的 resolv.conf 和当前 GODEBUG。

常见疑问

PreferGo 为 true 后一定不会调用系统解析库吗？

它表达的是该 Resolver 对 Go 内置解析器的偏好，但平台能力和实现条件仍然存在。需要确定路径时，结合 GODEBUG=netdns=1 的诊断输出和具体平台配置判断。

为什么只在容器里失败？

容器中的 /etc/resolv.conf、搜索域、环境变量和 cgo 可用性可能与宿主机不同。先把这些配置列入复现记录，再用固定 Dial 的测试隔离网络变量。

总结

net.Resolver 的纯 Go 与系统解析不是同一条实现路径；同一域名在不同环境出现差异时，优先确认 Resolver 配置、GODEBUG 和平台条件。用 netdns=1 观察选择，用 PreferGo 或 netdns=go/cgo 做对照，最后通过可控 Dial 和固定响应写回归测试，才能把“环境偶发差异”变成可维护的工程边界。