根本原因在于容器中 PID 1 进程缺乏信号处理与子进程回收能力；Linux 要求 PID 1 必须响应 SIGTERM/SIGINT 并调用 waitpid()，而 Docker 默认将应用直启为 PID 1，若其不处理信号或不回收子进程，会导致 docker stop 卡住。
根本原因在于容器中 PID 1 进程不具备信号处理与子进程回收能力。Linux 内核对 PID 1 有特殊要求：它必须能主动响应 SIGTERM/SIGINT，并调用 waitpid() 清理僵尸子进程。而 Docker 默认把应用直接拉起为 PID 1，若该应用本身不处理信号、也不 fork 子进程（或 fork 后不 wait），就会导致 docker stop 发出的 SIGTERM 被内核静默丢弃，容器卡住、超时后被强制 kill -9。
用 tini 替代默认 init 进程
tini 是 Docker 官方推荐的轻量 init 实现，仅约 100KB，无依赖，自动完成两件事：
- 将收到的 SIGTERM、SIGINT 等信号原样转发给它的唯一子进程（即你的应用）
- 持续调用
waitpid(-1, ...)回收所有已退出的子进程，杜绝僵尸累积 - 当子进程退出时，tini 自动退出，容器随之终止
在 Dockerfile 中启用方式如下：
Debian/Ubuntu 基础镜像：
RUN apt-get update && apt-get install -y --no-install-recommends tini && rm -rf /var/lib/apt/lists/*
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["python", "app.py"]
Alpine 镜像更简洁：
RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["./server"]
确保应用自身成为 PID 1 并支持信号
适用于单进程、无子进程、且代码层已实现信号监听的场景（如 Go/Node.js/Python 应用）。关键是要避免 shell 层中转——因为 shell 不会自动转发信号。
- 错误写法（sh 占据 PID 1，不转发）：
CMD ["sh", "-c", "python app.py"] - 正确写法（exec 替换 shell，python 直接成为 PID 1）：
CMD ["sh", "-c", "exec python app.py"] - Go 示例中需显式注册：
signal.Notify(sigChan, syscall.SIGTERM, syscall.SIGINT) - Node.js 示例中需监听：
process.on('SIGTERM', () => { server.close(...); })
利用 Docker 内置 --init 选项（运行时补救）
无需修改镜像，适合测试或临时修复。Docker 1.13+ 自带轻量 init，功能等效于 tini：
docker run --init -d my-app:latest
该参数会在容器启动时自动注入一个 init 进程作为 PID 1，后续你的 CMD 命令变为其子进程。效果与在 Dockerfile 中配置 tini 一致，但优先级低于镜像内声明的 ENTRYPOINT。
验证是否生效的实操方法
不要只看容器是否退出，要确认信号真正抵达应用：
- 启动容器后，进入容器：
docker exec -it <id> sh</id> - 执行：
kill -TERM 1（向 PID 1 发 SIGTERM） - 观察应用日志是否输出“收到 SIGTERM”“开始关闭”等清理信息
- 再检查：
ps aux确认无 Z（zombie）状态进程 - 最后执行：
docker stop <id></id>，观察是否在 10 秒内干净退出
