extra_hosts是最轻量可控的静态dns映射方式，通过向容器/etc/hosts追加“域名:ip”实现高优先级解析，绕过docker内置dns干扰，适用于解决域名冲突或强制指向测试环境。
直接用 extra_hosts 为微服务注入静态 DNS 映射，是最轻量、最可控的方式——它绕过 Docker 内置 DNS 的干扰，让容器在解析特定域名时直接走预设 IP，不查服务名、不走外部 DNS，特别适合解决域名冲突或强制指向测试/灰度环境。
extra_hosts 的基本写法与生效逻辑
它本质是往容器的 /etc/hosts 文件里追加行，格式为 "域名:IP地址"。Docker 在启动容器时自动注入，优先级高于内置 DNS 和系统 DNS。只要域名匹配，就立即返回指定 IP，跳过所有后续解析流程。
- 写在
docker-compose.yml对应服务下，不是全局配置 - 支持多个映射，每条单独一行；IP 必须是可达地址（如宿主机 IP、内网服务 IP、甚至 127.0.0.1）
- 注意引号：带点号的域名必须用双引号包裹，避免 YAML 解析错误
常见使用场景与配置示例
不是所有域名都适合硬编码，关键看是否需要“绕开服务名解析”或“屏蔽公网访问”。典型用法包括：
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
-
屏蔽同名服务干扰：比如你的服务叫
auth，但又要调用公网auth.example.com，就加"auth.example.com: 203.208.60.1" -
指向本地开发后端：前端容器需连宿主机上的 API，写
"api.local: 172.17.0.1"（Docker0 网桥地址）或"api.local: host.docker.internal"（Docker Desktop/Mac/Win 支持） -
模拟多环境域名：测试支付回调时，把
"pay.test: 10.10.20.5"指向测试网关，避免误调生产
注意事项与避坑点
看似简单，但几个细节容易导致失效：
- 容器内应用必须用
getaddrinfo或标准 DNS 接口（绝大多数语言默认如此），不能自己读取/etc/resolv.conf后硬编码 DNS 服务器 - 如果用了自定义 DNS（如 CoreDNS、
dns字段），extra_hosts仍有效，但需确认 DNS 配置没覆盖 hosts 行为 - 在 Swarm 或 Kubernetes 中不适用——那是集群 DNS 的管辖范围，
extra_hosts仅限单机 Compose 场景 - 修改后必须重建容器：
docker-compose up --force-recreate，单纯 restart 不会重载 hosts
配合其他机制提升灵活性
纯写死 IP 缺乏弹性，可结合以下方式增强适应性：
- 用
.env文件变量：在docker-compose.yml中写"api.example.com: ${API_HOST}"，启动前设置API_HOST=192.168.1.100 - 搭配
network_mode: "host"时慎用：此时容器共享宿主机网络栈，extra_hosts会被忽略 - 调试时进容器执行
cat /etc/hosts，确认映射已写入；再用ping -c1 api.example.com验证解析结果
