Docker容器主进程与子进程的退出条件及影响因素问询

先给个明确结论：Docker容器的生命周期完全绑定到PID 1的主进程（也就是你设置的entrypoint进程）。不管是Windows还是Linux容器，主进程一退出，容器立刻终止，不会等子进程跑完——这是Docker的核心设计逻辑，没商量。

那你遇到的两种不同情况，问题出在Windows进程的启动方式上，和宿主OS、Docker Desktop版本关系不大：

为什么会有不同表现？ #

• 子进程是否脱离了容器的进程命名空间
  在Windows里，如果你用不带/B参数的start命令启动子进程，它会新开一个控制台窗口，这个子进程会被Windows系统的csrss.exe接管，不再属于容器的进程组。这时候主进程退出后，容器确实会终止，但子进程会留在宿主机的进程列表里，看起来像是容器还在跑——但这只是Windows的进程托管机制，和Docker无关。
  要是你用start /B（后台启动，不建新控制台）或者直接启动子进程，子进程会属于容器的进程组，主进程退出时，Docker会把容器内所有进程都杀掉，子进程也会被终止。
• 主进程有没有主动等子进程
  如果你的主进程启动子进程后，调用了Windows的WaitForSingleObject这类API，或者用脚本里的timeout、循环检测进程的方式等着子进程结束，那主进程不会先退，容器自然会等到子进程跑完才终止。但如果主进程启动完子进程直接退出，容器立刻就停了。

可以自己测试验证 #

写个简单的批处理脚本当entrypoint试试：

1. 第一种情况（主进程直接退出，子进程被终止）：

   @echo off
   :: 启动记事本，不新开控制台
   notepad.exe
   :: 主进程直接退出
   exit 0
   

   运行容器后，你会看到容器秒退，记事本也会被直接杀掉。
2. 第二种情况（主进程退出，子进程残留宿主机）：

   @echo off
   :: 启动记事本，新开控制台
   start notepad.exe
   :: 主进程退出
   exit 0
   

   容器还是秒退，但记事本会留在宿主机进程里，因为它脱离了容器的进程组。
3. 第三种情况（主进程等待子进程，容器持续运行）：

   @echo off
   start /B notepad.exe
   :: 循环检测记事本进程，直到它退出
   :loop
   tasklist /fi "imagename eq notepad.exe" | find /i "notepad.exe" >nul
   if not errorlevel 1 goto loop
   exit 0
   

   这时候容器会一直跑，直到你关掉记事本，主进程才会退出，容器才终止。

总结 #

说白了，容器的终止逻辑从来没变过：主进程退，容器就退。你遇到的差异，本质是子进程有没有脱离容器的进程控制，以及主进程有没有主动等待子进程。和宿主系统、Docker版本几乎没关系，核心是主进程启动子进程的方式。

内容的提问来源于stack exchange，提问作者Jakob Bjerre Jensen