必须显式声明项目名和容器名——在docker-compose.yml顶部加name字段固定项目名，删除container_name让Compose自动生成唯一名称，扩展服务时避免service名重复并检查网络卷冲突。
直接改项目名或网络名，别依赖默认行为——Docker Desktop 扩展 Compose 服务时的名称冲突，90% 都是 COMPOSE_PROJECT_NAME 没设、name 字段没显式声明、或多个项目共用同一目录名导致的。
docker-compose.yml 里没写 name 字段，Desktop 自动用目录名当项目名
这是最隐蔽的坑：Docker Desktop 启动 Compose 时，若 docker-compose.yml 顶部没声明 name，它就取当前文件所在目录名作为 COMPOSE_PROJECT_NAME。两个同名目录（比如都叫 myapp）下启动的项目，会共享 myapp_default 网络、同名容器前缀、甚至 DNS 记录。
- 解决办法：在
docker-compose.yml顶部加name: myapp-dev或name: myapp-staging，强制固定项目名 - 不推荐只靠
-p命令行参数：Docker Desktop GUI 启动时不读命令行，-p对它无效 - 如果已存在冲突网络，先
docker-compose down，再docker network rm myapp_default（确认无其他容器在用）
多个服务用了相同 container_name，Desktop 报错并拒绝启动
Docker Desktop 对容器名唯一性检查比 CLI 更严格，一旦两个服务在同一个 docker-compose.yml 里写了重复的 container_name: api，会直接报错：container name "api" is already in use，连容器都不拉。
- 删掉所有
container_name字段——让 Compose 自动生成{project-name}_{service-name}_1，这是最安全的做法 - 真要固定名，确保每个
container_name全局唯一（跨项目也要查一遍：docker ps -a --format "{{.Names}}"） - 注意：
container_name不能含下划线开头、不能纯数字、不能和已存在的卷/网络同名
扩展服务后 DNS 解析串台，访问错容器
比如你用 Docker Desktop 的 “+ Add service” 功能往现有项目里加了个新 web 服务，但原项目已有 web，结果两个 web 容器注册到同一网络的 DNS 里，后启动的那个覆盖了前一个的 A 记录——curl web:80 永远打到新容器上，老服务失联。
- 根本解法：扩展时重命名新服务，比如叫
web-v2或web-legacy，避免 service 名重复 - 临时绕过：把新服务挂到独立网络（
networks: [- isolated-net]），再用反向代理转发 - 别信“只改端口就行”——DNS 错乱和端口无关，只要 service 名一样，内网调用就不可控
Desktop 启动后看不到新服务，或者服务状态一直 pending
这不是 UI 卡顿，大概率是后台资源命名冲突触发了静默失败：比如你扩展了一个 db 服务，但主机上已有同名容器、或同名卷 myapp-db-data 被旧项目占着，Desktop 不报具体错误，只让服务停在 pending。
- 查真实原因：打开 Docker Desktop 终端，运行
docker-compose config，看是否输出警告（如WARNING: Service "db" is using volume "myapp-db-data" which is also used by another container） - 清理残留：执行
docker volume ls | grep myapp，删掉无主卷：docker volume rm xxx - 关键动作：每次扩展服务前，先确认
volumes、networks、container_name三项没有和其他项目撞名
真正麻烦的不是名字重复本身，而是 Docker Desktop 在后台悄悄复用已有资源却不提醒——它不会告诉你“这个网络正在被另一个项目使用”，只会让服务起不来。所以每次扩展前，手动跑一遍 docker network ls 和 docker volume ls，比等报错再排查快得多。
