Go Resolver PreferGo 与系统解析器的差异边界

net.Resolver.PreferGo 解决的是“优先采用哪套名称解析实现”，不是“优先访问某一台 Go DNS 服务器”。把它设为 true，会请求使用 Go 内置解析器；保留默认值时，运行时还会结合 GODEBUG、构建标签、操作系统和名称服务配置做选择。若目标是指定 DNS 地址，还必须配置 Resolver.Dial。

我第一次认真区分这两个边界，是因为同一个服务在本机能解析内网短名称，放进精简容器后却只认完整域名。起初我把问题归因于网络，后来才发现真正需要核对的是：宿主机是否依赖系统名称服务，容器里最终走的是 Go 解析器还是原生解析器，以及两边读取到的配置是否一致。

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

标准库源码：https://go.dev/src/net/conf.go

先把 PreferGo 的边界说清楚

在 Unix 系统上，net 包主要有两条名称解析路径。Go 解析器会直接读取系统配置文件并自行发送 DNS 请求；基于 cgo 的原生解析器会调用操作系统提供的 C 库接口，例如 getaddrinfo。前者通常只占用 goroutine 等待网络，后者阻塞时会占用系统线程，因此 Go 文档说明 Unix 默认更倾向纯 Go 路径，但存在一组切换到原生解析器的条件。

package resolverdemo

import (
	"context"
	"net"
)

func lookupWithGo(ctx context.Context, host string) ([]string, error) {
	resolver := &net.Resolver{
		// 只选择 Go 内置解析实现，不等于指定了 DNS 服务器
		PreferGo: true,
	}

	// 超时与取消由调用方传入的 context 控制
	return resolver.LookupHost(ctx, host)
}

这个字段是请求优先使用 Go 解析器，而不是跨平台的绝对承诺。最终能力仍受目标系统与构建方式约束。更重要的是，系统原生解析器可能理解 Go 解析器尚未实现的名称服务规则。若企业环境通过 NSS、目录服务或特殊系统配置解析主机名，直接打开 PreferGo 可能改变结果，而不仅仅是改变性能。

解析器选择由哪些层级共同决定

我排查这类问题时，会把影响因素分成三个层级：实例级字段、运行与构建配置、系统环境。实例上的 PreferGo 最接近业务代码；GODEBUG=netdns=... 适合部署和诊断；netgo、netcgo 构建标签决定二进制中包含与偏好的实现；最后，操作系统和名称服务配置仍会影响默认选择。

官方文档列出的 Unix 切换条件包括 LOCALDOMAIN、非空的 RES_OPTIONS 或 HOSTALIASES，以及 resolv.conf、nsswitch.conf 中 Go 解析器不支持的功能。不同操作系统也有不同偏好，所以“我的 Linux 容器里是 Go 解析器”不能外推为“所有机器都会如此”。

什么时候 PreferGo 更可控

对我来说，PreferGo 最有价值的场景是运行环境简单且目标明确：服务只需要标准 DNS，镜像不想依赖 cgo，或者希望开发、测试、生产都走同一条 Go 代码路径。此时二进制行为更容易描述，阻塞查询也不会占住额外的系统线程。

不过“更可控”不等于“自动更正确”。上线前至少要核对以下内容：

• 业务域名是否都能通过标准 DNS 或 hosts 文件解析。
• 是否依赖短名称、搜索域、主机别名或企业目录服务。
• 容器中的 resolv.conf 与宿主机是否一致。
• 查询超时与调用链的 context 截止时间是否匹配。
• 构建产物是否启用了 netgo，从而彻底排除了原生路径。

如果这些依赖都能被标准化，显式选择 Go 解析器会减少“换一台机器就换一种行为”的模糊空间。反之，如果团队还说不清主机名来自 DNS、hosts 还是系统目录服务，先强制 PreferGo 往往会把隐含依赖变成线上故障。

什么时候应该保留系统解析器

系统解析器的优势不是“更高级”，而是它能继承平台已经配置好的名称服务语义。桌面系统、企业 Linux、VPN 客户端或受管设备，可能通过系统库整合搜索域、分流 DNS、目录服务和本地别名。只要应用需要忠实跟随这套环境，保留默认选择或显式对照 cgo 路径通常更稳妥。

代价也很明确：cgo 增加构建与运行依赖；被阻塞的 C 调用会占用系统线程；不同镜像中的 C 库与系统配置可能带来差异。Go 的 net 包会限制并发 cgo 查询数量，官方文档当前给出的上限是 500，用于避免耗尽系统线程。这个数字是实现保护，不应被当成业务并发目标。

选择原则可以压缩成一句话：只依赖标准 DNS、追求可移植部署时偏向 Go 解析器；必须继承操作系统名称服务语义时，优先保留系统解析器并做环境对照。

自定义 DNS 必须配合 Dial

PreferGo: true 只把查询交给 Go 解析器，并不会把请求发送到某个自定义地址。要固定 DNS 端点，需要同时提供 Dial。这个钩子由 Go 解析器使用，因此把它与 PreferGo 放在同一个 Resolver 中，职责最清楚。

package resolverdemo

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

func newInternalResolver(dnsAddress string) *net.Resolver {
	return &net.Resolver{
		// 自定义 Dial 由 Go 解析器使用，因此显式选择 Go 路径
		PreferGo: true,
		Dial: func(ctx context.Context, network, _ string) (net.Conn, error) {
			dialer := net.Dialer{
				// 单次建连超时应小于外层查询截止时间
				Timeout: 2 * time.Second,
			}

			// dnsAddress 应来自受控配置，例如 10.0.0.53:53
			return dialer.DialContext(ctx, network, dnsAddress)
		},
	}
}

示例故意把 DNS 地址作为参数传入，而不是硬编码公共服务器。生产环境还要考虑 UDP 包过大、网络设备兼容性和必要时的 TCP 回退策略；如果组织已经提供受控的内部 DNS，就应沿用其访问控制和变更流程。

StrictErrors 也不是解析器选择开关。它影响的是并行查询中的临时错误处理：启用后，某一类查询遇到临时错误可能让整个查询失败；关闭时则可能返回已经获得的结果。是否开启应根据调用方能否接受部分结果决定，不要用它修复 Go 与系统解析器的差异。

用 GODEBUG 做双路径诊断

遇到“本机正常、容器失败”时，我不会先改业务代码，而是让同一个二进制分别强制两条路径。+1 会输出解析器决策信息，适合确认实际选择；业务层同时记录查询名称、截止时间、错误类型和部署环境，但不要记录敏感的内部域名清单。

# 强制 Go 解析器，并打印解析器选择信息
GODEBUG=netdns=go+1 ./app

# 强制系统原生解析器，使用同一输入做对照
GODEBUG=netdns=cgo+1 ./app

如果两条路径结果不同，下一步不是立即宣布谁“有问题”，而是对照 resolv.conf、nsswitch.conf、环境变量、搜索域与构建标签。若只有系统路径能解析，通常说明应用依赖平台名称服务；若只有 Go 路径稳定，则要检查 cgo 依赖、系统线程压力或目标镜像中的库与配置。

发布前的决策清单

1. 明确名称来源：标准 DNS、hosts、搜索域、目录服务还是系统别名。
2. 记录构建选择：是否启用 cgo，是否使用 netgo 或 netcgo。
3. 记录运行选择：是否设置 GODEBUG=netdns，实例是否启用 PreferGo。
4. 若指定 DNS，确认 Dial、地址、超时和网络策略同时配置。
5. 用相同域名和相同截止时间对照 Go 与系统路径。
6. 在目标镜像和目标操作系统中复查，不以开发机结果替代部署验证。

我的最终取舍通常不是“永远 PreferGo”或“永远系统解析器”，而是先把依赖写清楚。标准 DNS 服务会倾向 Go 路径；依赖企业名称服务的应用会保留系统路径；需要自定义 DNS 的组件则显式组合 PreferGo 与 Dial。解析策略一旦从默认猜测变成可审查配置，跨环境问题就容易定位得多。

常见问题

PreferGo=true 会忽略 /etc/hosts 吗？

不会简单等同于“只查远程 DNS”。Go 解析器会读取系统相关配置并按其支持的规则处理 hosts 与 DNS；真正需要核对的是当前系统配置是否使用了 Go 解析器未实现的名称服务能力。

设置 PreferGo 后还需要 GODEBUG 吗？

正常业务实例不一定需要。PreferGo 适合代码中的单实例选择，GODEBUG 更适合进程级强制和诊断。排障时用 netdns=go+1 或 netdns=cgo+1 能更直观地对照两条路径。

自定义 Resolver 会自动被 http.Client 使用吗？

不会。需要把 Resolver 配到 net.Dialer，再把 Dialer 的 DialContext 交给对应的 http.Transport。否则自定义 Resolver 只在你直接调用它的方法时生效。

PreferGo 一定比系统解析器快吗？

不能这样概括。它减少了阻塞 C 调用对系统线程的占用，但真实延迟仍取决于 DNS 服务器、缓存、网络和名称服务配置。选择解析器应先保证语义正确，再用目标环境数据评估性能。