PID 1 与信号该不该用：先看它解决的问题是不是你的问题

容器里的 PID 1 对没有 handler 的信号默认忽略，这是内核行为不是 Docker 的 bug

它擅长的是需要优雅退出的服务；如果你只是批量部署与滚动更新，用现成的东西更省事。

先说结论

PID 1 的问题只在「停得干不干净」上暴露，平时看不出，发布时才疼

• 适合：需要优雅退出的服务
• 不适合：会 fork 子进程的应用
• 学习成本：docker stop 先发 SIGTERM 等 10 秒再 SIGKILL，退出码 137 就是被强杀
• 最大收益：shell 形式的 CMD 会让 /bin/sh 成为 PID 1，应用自己收不到信号
• 最大风险：CMD 写成 shell 形式，docker stop 每次都要等满 10 秒

它到底解决什么

容器里的 PID 1 对没有 handler 的信号默认忽略，这是内核行为不是 Docker 的 bug。

换句话说，它把「需要优雅退出的服务」这件事从手工变成可重复的流程。这是它真正的价值，而不是功能列表的长度。

什么时候不该用

下面三种情况，用了反而更累：

CMD 写成 shell 形式，docker stop 每次都要等满 10 秒

应用不处理 SIGTERM，数据库连接没关就断，留下锁

把 --init 当万能药，应用自己的优雅退出还是没实现

和替代方案比

PID 1 不回收僵尸进程，长期运行会攒出一堆 defunct。

这台工具的关键细节

几个决定长期体验的点：

• docker stop 先发 SIGTERM 等 10 秒再 SIGKILL，退出码 137 就是被强杀
• shell 形式的 CMD 会让 /bin/sh 成为 PID 1，应用自己收不到信号
• PID 1 不回收僵尸进程，长期运行会攒出一堆 defunct
• tini 只有约 1MB，负责转发信号和回收孤儿进程，开销基本可以忽略

我的建议

PID 1 的问题只在「停得干不干净」上暴露，平时看不出，发布时才疼。

先用两周，跑一个真实的小任务；两周后你还想用它，再谈长期。

工具是解法，不是身份。