可通过自定义net.Resolver并设PreferGo:true、实现Dial回调指定DNS服务器（如8.8.8.8:53）来替换系统DNS；需用DialContext配合超时控制，HTTP客户端需通过http.Transport.DialContext注入；UDP截断不会自动fallback TCP，需手动处理。
Go 里 net.Resolver 默认用系统 DNS，怎么换掉？
默认情况下，net.Resolver 会读 /etc/resolv.conf（Linux/macOS）或调用系统 API（Windows），没法控制 DNS 服务器地址或超时。想指定 8.8.8.8 或 1.1.1.1，必须自己构造 net.Resolver 实例并禁用系统解析逻辑。
关键在两个字段：PreferGo 设为 true，强制走 Go 自带的纯 Go DNS 解析器；Dial 回调用来指定 UDP/TCP 连接目标 DNS 服务端。
-
PreferGo: true是前提，否则Dial不生效 -
Dial必须返回net.Conn，且协议只能是udp或tcp（DNS 标准端口 53） - 别直接传
"udp://8.8.8.8:53"——Dial是函数，不是地址字符串
net.Resolver.Dial 怎么写才不 panic？
常见错误是返回了 nil net.Conn 或没处理 timeout/err，导致 ResolveIPAddr 等方法直接 panic。正确写法是用 net.DialTimeout 封装，并统一处理错误返回。
示例（UDP 查询）：
立即学习“go语言免费学习笔记（深入）”；
resolver := &net.Resolver{
PreferGo: true,
Dial: func(ctx context.Context, network, addr string) (net.Conn, error) {
d := net.Dialer{Timeout: 3 * time.Second}
return d.DialContext(ctx, "udp", "8.8.8.8:53")
},
}- 必须用
context.Context参数，否则超时控制失效 - 别硬写
net.Dial("udp", "8.8.8.8:53")—— 缺少上下文，无法中断阻塞 - TCP 场景下把
"udp"换成"tcp"即可，但注意某些 DNS 服务（如 Cloudflare）不支持 TCP fallback
自定义 Resolver 在 http.Client 中怎么生效？
Go 的 http.Client 不直接认 net.Resolver，得通过 net.DialContext 间接注入。核心是替换 http.Transport 的 DialContext 字段，再在里面调用你的 resolver.LookupHost。
典型写法：
resolver := &net.Resolver{ /* ... */ }
transport := &http.Transport{
DialContext: func(ctx context.Context, network, addr string) (net.Conn, error) {
host, port, _ := net.SplitHostPort(addr)
ips, err := resolver.LookupHost(ctx, host)
if err != nil {
return nil, err
}
for _, ip := range ips {
conn, err := (&net.Dialer{Timeout: 5 * time.Second}).DialContext(ctx, network, net.JoinHostPort(ip, port))
if err == nil {
return conn, nil
}
}
return nil, errors.New("failed to dial any resolved IP")
},
}- 别漏掉
net.SplitHostPort和net.JoinHostPort—— HTTP 的addr是"example.com:443"格式 -
LookupHost返回的是域名对应的所有 A/AAAA 记录，要逐个尝试连接 - 如果只做 DNS 解析不改 HTTP 流程，直接调
resolver.LookupNetIP更轻量
UDP DNS 查询失败后会自动切 TCP 吗？
不会。Go 的纯 Go DNS 解析器（PreferGo: true）在 UDP 响应截断（TC bit set）时，不会自动重试 TCP —— 这和 libc 的行为不同。你得自己判断并手动 fallback。
实际影响：
- 大响应（比如 DNSSEC 或大量记录）大概率被截断，导致
lookup failed: dns: overflow unpacking uint16 - 解决办法：在
Dial中根据 context 判断是否需要降级到 TCP，或预设双 resolver（先 UDP，失败后换 TCP Dial） - 更稳的做法是直接用
"tcp"，虽然慢点，但避免截断问题
真正难搞的不是写法，而是 DNS 截断、EDNS0 支持、以及某些内网 DNS 强制要求 TCP —— 这些细节不测真实环境根本发现不了。
