Docker Compose服务名重名不会导致运行时命名空间污染，但会引发容器、网络、卷三者撞名冲突，造成数据错乱或启动失败；需确保服务名唯一、显式指定项目名（-p）隔离上下文，并为卷/网络设带环境前缀的显式名称。
服务名重名在 Docker Compose 中不会直接造成“命名空间污染”或“类覆盖”，但会引发卷、网络、环境隔离失效等实际冲突，进而导致数据错乱、服务无法启动或配置被意外覆盖。关键在于：Compose 本身不管理 PHP 或 Java 的运行时命名空间，它只管理容器资源的命名与绑定；所谓“污染”实为资源标识冲突的误称，需从卷、网络、服务别名三方面系统处理。
确认是否真为服务名冲突
先排除常见误判：
- 运行 docker-compose config 查看解析后的完整配置，确认服务名是否重复（如两个
db:块） - 执行 docker-compose ps 观察容器名——默认格式是
<project>_<service>_<index>，若项目名相同、服务名又一样，容器名就完全一致，必然冲突 - 检查
docker network ls和docker volume ls，看是否有同名网络或卷被多个项目复用
服务名重名的直接后果与修复
服务名（service name）是 Compose 内部调度核心标识，重复即报错或行为异常：
- 同一
docker-compose.yml中定义两个同名服务（如都叫api），docker-compose up会直接失败，提示 “Service 'api' is defined multiple times” - 不同项目使用相同服务名 + 相同项目名（默认目录名），会导致容器、网络、卷三者全部撞名，后启动的覆盖前者的端口绑定和 DNS 解析
- 修复方式：确保每个
docker-compose.yml内服务名唯一；跨项目部署时，统一用 -p 项目名 显式指定隔离上下文，例如：docker-compose -p myapp-dev up -d与docker-compose -p myapp-prod up -d
卷与网络命名冲突的预防
服务名本身不决定卷/网络名，但默认命名规则依赖它，容易引发隐性覆盖：
- 若未显式设置
volumes.name或networks.name，Compose 会生成<project>_<volume-or-network-name>—— 服务名只是卷声明中的 key（如db-data:），真正影响全局唯一性的是项目名 + 卷 key 组合 - 推荐做法：对关键卷/网络显式命名，且带环境与功能前缀，例如：
volumes:<br> db-data:<br> name: myapp_prod_db_volume
- 禁止在不同项目中复用相同显式卷名，否则
docker volume inspect xxx将返回同一个卷，数据被共享而非隔离
服务别名（network aliases）导致的 DNS 污染
这是最接近“命名空间污染”的场景：多个服务通过 aliases 声明相同内部域名，造成容器内 DNS 解析不可控：
- 例如 service A 和 service B 都配置：
networks:<br> default:<br> aliases:<br> - api.internal
则任意容器访问api.internal时，DNS 返回的 IP 是随机的（取决于 Docker 内部记录顺序） - 解决方法：严格按用途分配别名，避免泛用；必要时用
extra_hosts固定映射，或通过反向代理（如 nginx）做路由分发，不依赖 DNS 负载 - 验证方式：进入容器执行
nslookup api.internal，观察是否返回多个 IP；再用curl -v http://api.internal看实际连到哪个服务
