核心是切断孤儿进程对信号链路的干扰，让SIGTERM能真正触达主应用并完成清理：先通过ps、docker top和inspect确认孤儿进程存在及主进程假死状态，再用--init注入tini接管进程树，修正启动方式避免shell中转导致的孤儿进程，并在主应用内同步处理SIGTERM主动终止子任务。
核心是切断孤儿进程对信号链路的干扰，让 SIGTERM 能真正触达主应用并完成清理。
确认孤儿进程是否真实存在
先验证问题根源，避免误判：
- 进入容器执行 ps auxf，观察是否存在长期运行、PPID 不为 1 的子进程（即已脱离父进程但未被 init 回收）
- 检查 docker top
输出中是否有持续存在的非主进程 PID - 用 docker inspect
查看 State.Status是否卡在running，同时State.StoppedReason为空——这常表明主进程“活着”但不响应信号
用 --init 强制注入 tini 管理进程树
tini 不仅回收僵尸进程，也能接管并清理孤儿进程，防止它们阻塞主进程退出路径：
- 启动时加 --init 参数：
docker run --init -d myapp-image - 若需自定义 tini 行为（如忽略子进程退出码），可改用显式入口：
ENTRYPOINT ["/sbin/tini", "--", "myapp"] - 注意：tini 必须是 PID 1，因此 Dockerfile 中不能用 shell 形式 CMD，否则 tini 会被绕过
修复启动方式，杜绝孤儿进程产生源头
很多死循环孤儿进程源于错误的启动脚本写法：
- ❌ 错误写法：
CMD ["sh", "-c", "myapp & wait"]—— shell 是 PID 1，myapp是后台子进程，wait只等它一次，之后 fork 出的新进程就成孤儿 - ✅ 正确写法：
ENTRYPOINT ["exec", "myapp"]或CMD ["myapp"]（直接可执行文件，无 shell 中转） - 若必须用脚本，结尾务必写
exec "$@"，确保替换当前 shell 进程，让应用直接受控于 tini
主应用内同步处理 SIGTERM 并主动终止子任务
即使有 tini，主应用也需配合，避免自身派生出不可控子进程：
- 在代码中监听 SIGTERM，收到后立即停止新建任务、关闭监听端口、中断长循环
- 对已有子进程（如通过 fork/spawn 启动的），调用 kill() 或 process.kill() 主动终止，不要依赖操作系统回收
- Python 示例中使用
signal.signal(signal.SIGTERM, handler)；Go 中用signal.Notify(c, syscall.SIGTERM)
