Docker构建Python容器运行正常，docker-compose启动时立即退出

两种启动表现的差异完全来自运行参数配置，和镜像构建流程、Dockerfile内容没有关联：

• 手动执行docker run时，你传入了--interactive --tty两个核心参数：
  • --interactive（简写-i）保持容器标准输入流（STDIN）为开放状态
  • --tty（简写-t）为容器分配伪交互终端
    容器内启动的/bin/bash检测到自身连接着开放的交互终端，会一直挂起等待输入，不会主动退出。
• 通过docker compose启动时，默认既不分配伪终端，也不保持STDIN开放。这种场景下容器内的/bin/bash启动后立刻检测到标准输入已关闭，没有交互终端支撑，会正常执行完启动逻辑直接退出，返回退出码0，和你观察到的*Exited (0)*状态完全匹配——这不是程序报错，是bash本身的运行机制导致的退出。

结合你搭建开发环境、后续需要联动调试其他服务的场景，两种方案可按需选择：

方案1：对齐手动docker run的交互逻辑 #

直接在docker-compose.yml的python服务配置块中补充两行配置，效果完全等价于docker run的-it参数：

services:
  python:
    # 保留原有全部配置
    tty: true
    stdin_open: true

修改完成后重新执行docker-compose up --build -d启动，容器表现就会和手动用docker run启动时完全一致，保持持续运行状态。后续需要进入容器调试时，直接执行docker-compose exec python /bin/bash即可。

方案2：替换为常驻后台进程 #

如果不需要持续维持交互终端，只要求容器保持运行支撑后续调试，可以通过配置覆盖原有的启动命令，用一个永远不会主动退出的前台进程作为容器启动入口：

services:
  python:
    # 保留原有全部配置
    command: tail -f /dev/null

这种方式资源占用更低，没有交互终端的额外开销，适合长期运行的开发服务场景。

修改配置启动后，执行docker-compose ps可以看到python服务的状态为Up，即代表配置生效；如果仍有异常，可通过docker-compose logs python查看容器启动日志定位问题。

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