容器内僵尸进程更难清理是因为pid 1非真正init，不自动收养孤儿或处理sigchld；必须用tini/dumb-init等轻量init接管pid 1职责，或在应用层显式wait回收。
在微服务容器化部署中，僵尸进程不是“能不能看到”的问题，而是“会不会悄悄堆积”的隐患。传统 Linux 宿主机上 kill 父进程还能临时解围，但在容器里——尤其是用 bash、sh 或自研启动脚本作为 PID 1 的镜像中，父进程一旦崩溃或未处理 SIGCHLD，子进程退出后就永远卡在 Z 状态，且 init（即 PID 1）不接管，因为容器里那个“1 号进程”根本不是真正的 init。
为什么容器里僵尸更难清理？
标准 Linux 系统中，孤儿进程会被 systemd 或 init（PID 1）自动收养并 wait；但 Docker 默认用你指定的命令（如 python app.py 或 ./server）直接作为 PID 1 启动。这个进程通常：
- 不响应
SIGCHLD（默认忽略） - 不调用
waitpid(-1, &status, WNOHANG)回收子进程 - 没有子进程生命周期管理逻辑
结果：子进程一 exit，立刻变僵尸，且无人收尸——因为 PID 1 不干这事。
Tini 是什么？它怎么起作用？
Tini 是一个极简、轻量、专为容器设计的 init 系统（PID 1），被 Docker 官方推荐并内置（--init 参数即启用 Tini）。它核心只做两件事：
- 作为 PID 1 运行，自动收养所有孤儿进程
- 收到子进程退出信号时，主动调用
waitpid()清理僵尸
它不改业务逻辑，不侵入应用，仅在启动链最前端加一层“守门人”。启用方式极其简单：
# 构建时指定 ENTRYPOINT（推荐） ENTRYPOINT ["/sbin/tini", "--"] <h1>或运行时加 --init（Docker 1.13+）</h1><p>docker run --init -d my-microservice</p>
注意：tini 必须是 PID 1，所以不能写成 CMD ["tini", "--", "python app.py"] ——那样 tini 是子进程，失效。正确写法是 ENTRYPOINT + CMD 组合，或直接 ENTRYPOINT ["tini", "--", "python", "app.py"]。
Dumb-init 对比：更透明，支持信号转发
Dumb-init 功能与 Tini 类似，但额外提供信号转发能力（比如 docker stop 发 SIGTERM，它会原样转给你的主进程，再优雅退出）。对需要精确控制信号行为的微服务（如 Go/Java 应用监听 TERM 做资源释放）更友好。
使用方式类似：
FROM python:3.11-slim RUN pip install dumb-init ENTRYPOINT ["dumb-init", "--"] CMD ["gunicorn", "-c", "gunicorn.conf.py", "app:app"]
它还支持配置文件定义信号映射（例如把 SIGUSR2 转发为 SIGHUP），适合复杂信号调度场景。
不换基座？至少得补 SIGCHLD 处理
若因合规或历史原因无法引入 Tini/Dumb-init（比如某些硬性要求禁止非业务二进制），必须在应用层兜底：
- Python：启动前加
signal.signal(signal.SIGCHLD, signal.SIG_IGN)（内核自动回收） - Go：用
exec.Command启子进程后，务必cmd.Wait()或启动 goroutine 调用wait - Bash 脚本：用
wait -n或循环wait %1监听后台作业，或设trap 'wait' CHLD
但这类方案易遗漏、难审计，不如 Tini/Dumb-init 一次接入，全局生效。
真正根除容器僵尸，不靠事后 ps | grep Z | kill -9 ppid，而靠从启动那一刻就让 PID 1 具备 init 职责。Tini 和 Dumb-init 就是为此而生的——小体积、零配置、开箱即用。选哪个？Tini 更轻更快；Dumb-init 更稳更可控。两者都远胜于裸跑一个无回收能力的业务进程当 PID 1。
