Go net.Resolver LookupHost 超时设置不生效的原因

我第一次遇到这个问题，是给 DNS 查询加了一个很短的超时，日志里却发现调用仍然拖了很久。后来把代码拆开看，真正的问题通常不在“超时太小”，而在于调用的函数没有接收这个 context.Context，或者自定义的 DNS 拨号器拿到 ctx 后又把它丢掉了。

官方地址：https://pkg.go.dev/net#Resolver.LookupHost

想让 DNS 查询受超时控制，应调用 Resolver.LookupHost(ctx, host)，不要调用包级的 net.LookupHost(host)。如果还配置了 Resolver.Dial，该函数也必须把 ctx 传给支持上下文的拨号方法；否则 deadline 只能约束外层，不能约束被阻塞的自定义拨号。

先看调用点：是不是把 Context 丢在门外了

最容易忽略的是两个 API 名字很接近：包级的 net.LookupHost(host) 和方法级的 resolver.LookupHost(ctx, host)。前者的官方实现会在内部创建 context.Background()，所以你在函数外部创建的 deadline 根本没有机会传进去。

package main

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

func lookupHost(ctx context.Context, host string) ([]string, error) {
	resolver := net.DefaultResolver // 复用默认解析器，但显式传入调用方的 ctx
	addrs, err := resolver.LookupHost(ctx, host)
	if err != nil {
		// 先识别 deadline，再保留原始错误供日志定位 DNS 细节
		if errors.Is(err, context.DeadlineExceeded) {
			return nil, fmt.Errorf("DNS 查询超时: %w", err)
		}
		return nil, err
	}
	return addrs, nil
}

func main() {
	ctx, cancel := context.WithTimeout(context.Background(), 800*time.Millisecond)
	defer cancel() // 无论成功或失败都释放定时器关联资源

	addrs, err := lookupHost(ctx, "service.example")
	if err != nil {
		fmt.Println(err)
		return
	}
	fmt.Println(addrs)
}

这个改动只解决“deadline 没传到 API”的问题，不保证每次调用都刚好在 800 毫秒返回。比如输入是字面量 IP 时，标准库可以直接返回；如果名称命中了本机 hosts，也可能没有等待外部 DNS。超时是对可等待操作的上限，不是人为制造一次 DNS 失败。

再查 Resolver.Dial：自定义拨号最容易让超时失去意义

如果项目为了指定 DNS 服务器而设置了 Resolver.Dial，排查重点就从调用点移到了这个回调。Go 的解析器会把查询上下文传给 Dial；正确做法是把它继续交给 net.Dialer.DialContext。如果回调里改用不接收 ctx 的拨号函数，外层 deadline 不能强行中断那段自定义阻塞。

resolver := &net.Resolver{
	PreferGo: true, // 明确偏好 Go 内置解析器，便于统一使用 Dial 回调
	Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
		var dialer net.Dialer
		// DNS 服务器地址应是字面量 IP:端口，DialContext 才能响应 ctx
		return dialer.DialContext(ctx, network, "192.0.2.53:53")
	},
}

ctx, cancel := context.WithTimeout(context.Background(), 800*time.Millisecond)
defer cancel() // 查询结束后及时取消 deadline

addrs, err := resolver.LookupHost(ctx, "service.example")
if err != nil {
		// 网络错误可能包裹 deadline，用 errors.Is 判断更可靠
		if errors.Is(err, context.DeadlineExceeded) {
			fmt.Println("DNS 查询达到 deadline")
		}
		fmt.Println("lookup failed:", err)
}
fmt.Println(addrs)

这里的 192.0.2.53 只是文档示例地址，不代表可用的公共 DNS。生产环境应从受控配置读取 DNS 服务器，并确认地址是 IP 而不是域名；官方源码也说明，传给自定义 Dial 的 DNS server 地址会是字面量 IP 和端口。

另一个常见误区是只给 DNS 拨号设了超时，却把整个业务 deadline 忘在了外面。比较稳妥的做法是让一次请求共享一个上层 ctx，解析、连接和后续 I/O 各自遵守同一个剩余时间预算。

最后确认系统解析器：同一段 Go 代码不一定走同一条路径

net 的域名解析依赖操作系统环境。在 Unix 系统上，它可能使用直接读取 /etc/resolv.conf 的 Go resolver，也可能使用 cgo 调用系统的 getaddrinfo 等函数。系统配置、环境变量和平台差异都会影响选择，所以不要只凭一次机器上的耗时判断“Context 没有作用”。

排查时我会记录四个字段：传入的 host、deadline 是否存在、解析器是否配置了 PreferGo/Dial，以及错误能否被 errors.Is(err, context.DeadlineExceeded) 识别。若 host 是字面量 IP，Resolver.LookupHost 会直接返回它；若请求命中本地 hosts，也可能绕过外部 DNS。只有确认确实进入了需要等待的解析路径后，超时结果才有比较意义。

我会怎样做最后一次复查

先把包级 API 全部替换为带 ctx 的方法，再检查自定义 Dial 是否把 ctx 传到网络层；然后分别用一个真实域名、一个字面量 IP 和一个明确不存在的域名观察差异。错误处理用 errors.Is 判断 deadline，用 net.Error.Timeout() 补充网络错误语义，日志中同时记录 deadline 与实际错误，不只打印“耗时超了”。

这套处理适合 HTTP 客户端、服务发现和需要自定义 DNS 的后台服务。它不能替代对系统 DNS 配置的治理，也不能让一个不响应 Context 的第三方回调自动变得可取消；如果阻塞发生在 cgo 或自定义代码内部，应继续沿调用链定位真正不受控的那一层。

常见问题

net.LookupHost 能不能直接设置超时？

不能直接传入 Context。应改用 net.DefaultResolver.LookupHost(ctx, host)，或使用你自己的 net.Resolver。

PreferGo 设置后就一定能按 deadline 返回吗？

它只影响解析器偏好，不能修复你在 Resolver.Dial 中丢弃 ctx 的代码，也不代表每次输入都会触发网络查询。

为什么输入 IP 地址时几乎立即返回？

因为 Resolver.LookupHost 会先识别字面量 IP 并直接返回，不需要等待 DNS 服务器。