go应用容器内dns解析超时主因是ndots=5：短域名如redis被拼为redis.default.svc.cluster.local.多次查询失败后才回退，导致连接卡顿或超时。
Go 应用在容器里解析域名超时，大概率是 ndots 搞的鬼
Go 的 net.Resolver 默认走 cgo（即调用系统 getaddrinfo），而容器中 /etc/resolv.conf 通常带 search 域和 ndots:5。这意味着像 redis 这种短名字，会被拼成 redis.default.svc.cluster.local. 再去查——查一圈失败才回退到 redis.。实际表现就是：net.Dial("tcp", "redis:6379") 卡 5 秒才连上，或直接超时。
- 默认
ndots是 5，只要域名里点数 redis（0 点）、db.prod（1 点）全中招 - Go 不读
options ndots:N的降级逻辑（比如点数 ≥ N 就不拼 search），它要么全拼，要么不拼——取决于是否启用 cgo - Alpine 镜像（musl libc）默认禁用 cgo，
net.Resolver切回纯 Go 解析器，但该解析器压根不读search和ndots，反而“意外”快了
强制 Go 走纯 Go DNS 解析器，绕过 ndots 和 search
最简单有效的解法：让 Go 完全不用系统解析器。通过环境变量关闭 cgo，逼它用内置解析器。这个解析器只做 A/AAAA 查询，不拼 search 域，也不看 ndots，行为可预测。
- 构建时加
CGO_ENABLED=0：CGO_ENABLED=0 go build -o app . - 运行时确保没开 cgo（检查
os.Getenv("GODEBUG")里没netdns=cgo） - 注意：纯 Go 解析器不支持 SRV、TXT 等记录，如果你用
net.LookupSRV（比如 gRPC 的服务发现），这条路走不通 - Alpine 镜像天然满足条件，但 Debian/Ubuntu 镜像必须显式关 cgo，否则默认走 cgo
保留 cgo 但改 ndots，要动容器 DNS 配置
如果必须用 cgo（比如依赖 SRV 记录），就得从容器侧调低 ndots。Kubernetes Pod 的 dnsConfig.options 可覆盖，默认值来自 kubelet 的 --cluster-dns 配置，不能直接改节点上的 /etc/resolv.conf。
- 在 Pod spec 中显式设
ndots: 1：dnsConfig: options: - name: ndots value: "1" - 值设为 1 后，只有像
a.b这样至少带 1 个点的域名才会拼 search 域；redis直接查redis.，不再瞎拼 - 别设
ndots: 0—— 某些旧版 libc 会当 1 处理，行为不一致；Kubernetes 1.22+ 才真正支持 0 - 改完要验证：进容器执行
cat /etc/resolv.conf，确认options ndots:1生效，且search行还在
本地开发和 CI 环境 DNS 行为不一致，容易漏掉问题
本地 docker run 默认用 host 网络或自建 bridge，/etc/resolv.conf 通常是宿主机的（ndots:1 或没有），而 Kubernetes Pod 里是 ndots:5 + 一长串 search。这就导致本地跑得飞快，一上集群就超时。
立即学习“go语言免费学习笔记（深入）”；
- CI 流水线里跑集成测试，务必用跟生产一致的镜像 + Pod 配置，别用
docker-compose模拟 - 临时调试可在 Pod 中手动改
/etc/resolv.conf（加options ndots:1），但这是临时手段，不能进配置管理 - Go 1.19+ 提供了
GODEBUG=netdns=go运行时开关，可用于快速验证纯 Go 解析器行为，但别长期依赖——它绕过了系统配置，上线后可能和预期不符
真正麻烦的是混合场景：一部分服务用 SRV（必须 cgo），另一部分只用 A 记录（可以关 cgo）。这时候没法一刀切，得按调用链拆开治理，或者统一用 FQDN（比如写死 redis.default.svc.cluster.local）来规避拼写逻辑。
