直接用net.Resolver配置自定义DNS服务器地址即可让Go微服务绕过系统默认DNS直连CoreDNS解析内部域名，无需修改宿主机或容器网络配置；需显式指定UDP地址（如10.10.2.5:53）、设3秒超时、启用PreferGo:true，并配合CoreDNS的kubernetes+forward插件实现内网域名解析与外部域名兜底转发。
直接用 net.Resolver 配置自定义 DNS 服务器地址，就能让 Go 微服务绕过系统默认 DNS，直连 CoreDNS 解析内部域名。不需要改宿主机配置，也不依赖容器网络的 /etc/resolv.conf 注入——那是 Kubernetes 默认干的事，但你在裸 Go 服务或非 K8s 环境里得自己控制。
Go 代码里显式指定 CoreDNS 地址
Go 标准库的 net.Resolver 支持传入自定义 Net 和 Addr，可精准指向你的 CoreDNS 实例（比如 10.10.2.5:53）。这比改全局 GODEBUG=netdns=cgo 或环境变量更可靠，也避免影响其他 DNS 调用。
- 必须用
udp协议（tcp也可，但 UDP 是 DNS 查询默认且更轻量） -
Timeout建议设为3s左右，太短易超时，太长拖慢服务启动和重试逻辑 - 如果 CoreDNS 启用了
bind插件限制监听地址，确保它监听了服务能访问到的 IP（比如不是只绑127.0.0.1）
CoreDNS 配置要支持非集群域名的 fallback
微服务调用的域名分两类：一类是内网服务名（如 auth.svc.cluster.local），另一类是外部 HTTP 客户端要访问的第三方 API（如 api.paypal.com）。CoreDNS 必须能区分并正确转发，否则你的 http.Client 会卡住。
- 在
Corefile中，kubernetes插件负责处理*.svc.cluster.local；其余域名应由forward插件兜底，比如forward . 8.8.8.8 1.1.1.1 - 避免写成
forward . /etc/resolv.conf—— 容器里这个文件可能为空或不可靠，尤其在 init 容器未就绪时 - 加
cache 30能显著降低重复解析开销，对高频服务发现场景很关键
别忽略健康检查与失败降级路径
CoreDNS 不是永远在线的。你的 Go 服务启动时若 DNS 不通，net.LookupIP 会阻塞并最终超时；运行中 CoreDNS 挂了，后续所有服务调用都会失败。不能只靠重试，得有明确 fallback 行为。
- 启动阶段建议做一次预检：
resolver.LookupHost(ctx, "kubernetes.default.svc.cluster.local")，失败则记录告警但不 panic - 业务代码中不要把 DNS 解析放在 hot path 上反复调用——解析结果应缓存（例如用
sync.Map存host → []net.IP），TTL 参照 CoreDNS 的cache设置 - 极端情况下可 fallback 到静态映射表（如读取
config.yaml里的services列表），但这只是保底，不是常态方案
最常被忽略的一点：Go 的 net.Resolver 不会自动重试 TCP fallback 当 UDP 响应被截断（TC bit set），而 CoreDNS 在返回大响应（比如含多条 A 记录的 SRV 查询）时可能触发这个行为。如果你的服务依赖 SRV 记录做负载均衡，务必在 Resolver 初始化时显式启用 PreferGo: true 或用 miekg/dns 库手动处理 TC 重试逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
