go 直接用 net.lookuphost 解析 headless service 域名会失败，因其无 a 记录，须用 net.lookupip 获取各 pod 的独立 a/aaaa 记录；需用完整 fqdn、运行在集群内，并自行缓存与健康检查。
Go 直接解析 Headless Service 的 DNS 名会失败？
默认用 net.LookupHost 或 net.LookupSRV 查 Kubernetes Headless Service 域名（比如 my-svc.default.svc.cluster.local），大概率返回空或报 no such host。这不是 Go 的 bug，而是因为 Headless Service 不产生 A 记录，只生成 Pod IP 的 DNS 记录——但前提是客户端必须显式请求 AAAA/A 记录，并且 DNS 解析器要支持并启用对 SRV/AAAA 的递归查询。Kubernetes kube-dns/CoreDNS 默认对 Headless Service 返回的是 **每个 Pod 的独立 A/AAAA 记录**，不是单个聚合 IP。
- 必须用
net.LookupIP（而非LookupHost）才能拿到全部 IP 列表 - 如果 Pod 使用 IPv6 或双栈，
LookupIP可能混着返回 v4/v6，需按需过滤 - Headless Service 的域名在集群外无法解析，确保代码运行在集群内（Pod 中）或已配置好 CoreDNS 转发
为什么 net.Resolver 设置 PreferGo: true 会让解析变慢甚至超时？
Go 的 net 包默认用系统 libc resolver（如 glibc 的 getaddrinfo），它会自动处理 DNS 搜索路径、ndots、超时重试等；而 PreferGo: true 强制走 Go 自研的纯 Go DNS 解析器，它不读取 /etc/resolv.conf 中的 search 或 options ndots，导致像 my-svc 这种短域名不会自动补全为 my-svc.default.svc.cluster.local，最终查不到。
- Headless Service 必须用完整 FQDN（带
.svc.cluster.local后缀），否则 Go 的纯 Go 解析器不会尝试补全 - 若必须用
PreferGo: true（例如交叉编译无 libc 场景），得手动拼全域名，或自己实现搜索路径逻辑 - 生产环境建议保持默认（
PreferGo: false），依赖系统 resolver + CoreDNS 的行为一致性
如何轮询解析到的 Pod IP 并做健康检查？
单纯 net.LookupIP 返回的是静态快照，不能反映 Pod 实时存活状态。真实服务发现需要结合主动探测，否则容易把请求发到已终止但 DNS 缓存未过期的 Pod 上。
- 每次发起请求前，先调用
net.LookupIP获取最新 IP 列表（注意设置合理 TTL 缓存，比如 30 秒，避免高频查 DNS） - 对每个 IP 做轻量级健康检查：比如 TCP 连接是否通（
net.DialTimeout("tcp", ip+":port", 500*time.Millisecond)），比 HTTP 探针更轻更快 - 跳过连接失败的 IP，从剩余列表中随机或轮询选一个——不要直接用
rand.Perm全量 shuffle，避免重复建连开销 - CoreDNS 默认 TTL 是 5 秒，但 Go 的
net.Resolver不自动缓存结果，需自己加内存缓存（如sync.Map）
StatefulSet 场景下怎么区分有状态 Pod 的 DNS 名？
Headless Service + StatefulSet 会为每个 Pod 分配固定 DNS 名，形如 pod-0.my-svc.default.svc.cluster.local。但直接解析这个名字只能得到单个 Pod 的 IP，和普通 Service 解析行为不同。
立即学习“go语言免费学习笔记（深入）”；
- 若需获取全部 Pod 的稳定 DNS 名（不只是 IP），应解析
my-svc.default.svc.cluster.local，再对每个返回的 IP 反向查 PTR（net.LookupAddr），但该方式不可靠（PTR 记录不一定开启） - 更稳妥的做法是：通过 Kubernetes API 查询 Endpoints 对象（
/api/v1/namespaces/default/endpoints/my-svc），里面明确列出每个subsets[].addresses[].hostname - 如果只用 DNS，建议约定命名规则，比如用
my-svc-0.my-svc.default.svc.cluster.local这类“带序号的 headless 子域名”来定向访问特定 Pod
最常被忽略的一点：DNS 解析结果没有天然顺序保证，net.LookupIP 返回的切片顺序每次可能不同，别依赖下标 0 当“主节点”。另外，CoreDNS 的负载均衡策略（如 random、roundrobin）只影响同一查询的多次响应顺序，不改变单次 LookupIP 返回的切片结构——这事儿得自己做。
