docker-compose启动项目时错误执行非本项目的docker-entrypoint.sh脚本

你遇到的跨项目配置串扰，和之前尝试的指定独立项目名、删除容器名配置、重命名docker目录这些操作没有关联——这些都是运行时的容器层配置，解决不了构建阶段的镜像匹配逻辑问题。本质上的串扰都来自Docker构建阶段的缓存复用、镜像标识冲突，和运行时的容器清理操作是两个完全独立的维度：哪怕你把所有容器都删干净，只要本地构建缓存里存在对应配置的旧镜像，就会被错误复用，导致前端项目意外执行后端的entrypoint脚本。

常见的触发场景有三类，可按优先级依次验证：

• 最常见触发：镜像标签重名导致的镜像复用
  如果你两个项目的docker-compose.yml里，build段定义的image标签完全一致，比如都写了image: my-app:latest，哪怕你每次执行--build，Docker也不会严格校验当前构建上下文的内容，会直接复用本地已经存在的、同名的旧镜像——也就是你之前后端项目构建的、带自定义ENTRYPOINT的镜像，根本不会触发前端项目Dockerfile的完整构建流程。
  快速验证：执行docker images，查找两个项目可能同名的镜像条目，如果能看到对应大小的后端镜像，哪怕没有跑对应容器，这个镜像也会被Compose优先匹配。
• 第二类触发：构建上下文路径配置错误
  如果你写docker-compose时，build的context路径指向了错误的目录，比如前端项目的compose把context指到了后端项目的根路径，或者两个项目共享了同一个上层父目录作为构建上下文，Docker会自动把目录下的docker-entrypoint.sh脚本打包进构建上下文，甚至因为Dockerfile里错误的COPY指令，把这个脚本拷贝到镜像内，继承原本后端项目的ENTRYPOINT配置。
  快速验证：在前端项目的docker目录下执行docker-compose config，查看输出中build段的context对应的绝对路径，确认是不是真的指向前端项目的根目录，没有交叉指向其他项目的路径。
• 第三类触发：Compose工作目录识别错误
  Compose会自动把执行命令时的当前工作目录名，作为默认项目名关联服务配置。如果启动前端项目时，终端的当前路径不小心切到了后端的docker目录，或者切到了两个项目的共同父目录，Compose会自动把后端项目已经定义的服务配置（包括带ENTRYPOINT的服务）拉起来，根本不会读取前端项目的配置。
  快速验证：在你准备执行前端启动命令的终端窗口，先执行pwd确认当前目录是前端项目的docker子目录，再执行docker-compose config --services，确认输出的服务列表只有前端项目的服务，没有混入后端项目的服务。

按顺序执行即可，每步完成后验证效果：

1. 清理关联的冗余缓存
   • 在前端项目的docker目录下执行docker-compose down --rmi local --volumes --remove-orphans，删除当前Compose项目关联的本地自建镜像、数据卷、孤儿容器
   • 全局查找本地重名的冗余镜像，执行docker rmi <冗余镜像ID>手动删除，不要留任何和两个项目镜像标签重名的条目
2. 给两个项目的镜像设置完全独立的专属标签
   不管之前的image配置怎么写，现在给两个项目的镜像设置绝对不重复的标签，比如后端项目的image配置为image: backend-service:local-dev，前端项目的image配置为image: frontend-static:local-dev。这里要明确：Docker匹配镜像时只看标签名，完全不关心镜像来自哪个项目的目录路径，只要标签重名就会触发复用。
3. 校验构建配置的正确性
   • 检查docker-compose中build段的context路径，确保两个项目的构建上下文分别指向自身的项目根目录，不存在路径交叉
   • 构建完成后，直接检查前端镜像的实际ENTRYPOINT配置：执行docker inspect <前端专属镜像ID> --format='{{.Config.Entrypoint}}'，如果输出的内容不是空值，说明之前的镜像构建存在内容串用
4. 启动时强制跳过所有构建缓存
   执行启动命令时，除了--build参数，额外加上--no-cache，也就是在前端的docker目录下执行docker-compose -p frontend-dev up -d --build --no-cache。这个参数会让Docker完全丢弃所有历史构建缓存，严格按照当前项目的Dockerfile从头构建镜像，不会偷偷复用之前后端项目的镜像层。

常见认知误区：很多人以为只要docker container ls返回空列表，就代表没有残留配置。实际上Docker的镜像、构建缓存是独立存储的，只要本地存在和compose配置中同名的镜像，不管有没有运行对应容器，Compose在构建时都会优先匹配这个镜像，不会追溯镜像最初的构建来源。

内容的提问来源于stack exchange，提问作者SmashingQuasar