STOPSIGNAL指令用于指定docker stop时向容器主进程发送的信号，默认SIGTERM，可设为SIGUSR1等可捕获信号，但不可设SIGKILL或SIGSTOP；需应用自身处理该信号才能实现优雅退出。
在 dockerfile 中用 stopsignal 指令，就能明确告诉 docker：当执行 docker stop 时，该向容器主进程发哪个信号。它不改变程序逻辑，只设定“敲门方式”——默认是 sigterm，但你可以换成 sigint、sigusr1 等其他可捕获的信号。
语法很简单，一行搞定
STOPSIGNAL 后直接跟信号名（不带 SIG 前缀）或数字编号：
STOPSIGNAL SIGTERMSTOPSIGNAL SIGUSR1-
STOPSIGNAL 15（等价于 SIGTERM） -
STOPSIGNAL 2（等价于 SIGINT）
注意：不能设为 SIGKILL（9）或 SIGSTOP（19），因为这两个信号无法被进程捕获或忽略，设了也无效。
必须配合应用自身支持才能生效
STOPSIGNAL 只是“发信号”，真正决定是否优雅退出的是容器里运行的程序。它得提前注册对应信号的处理函数，比如 Node.js 中监听 'SIGUSR1'，Go 程序中用 signal.Notify 捕获。
- 如果程序没处理你指定的信号，收到后会直接退出（类似无响应的关门）
- 如果程序只处理了
SIGTERM，而你设成STOPSIGNAL SIGUSR1，那它就收不到“关门提醒”，可能硬等到超时被 kill - 建议优先使用
SIGTERM，它是通用标准；特殊场景（如 reload 配置）才考虑SIGUSR1或SIGUSR2
和 Kubernetes 的 stopSignal 是什么关系？
Kubernetes v1.33+ 支持在 Pod YAML 中用 lifecycle.stopSignal 覆盖镜像定义的 STOPSIGNAL。优先级是：
- Pod 容器级
stopSignal设置 → 最高优先级 - 镜像中 Dockerfile 的
STOPSIGNAL→ 次之 - 运行时默认（通常是
SIGTERM）→ 最后兜底
也就是说，Dockerfile 设的 STOPSIGNAL 是镜像自带的“出厂设置”，适合跨平台统一行为；K8s 层的配置则更灵活，运维可在不改镜像的前提下调整策略。
验证是否生效的小技巧
构建完镜像后，可以用 docker inspect 查看 STOPSIGNAL 是否写入：
docker inspect your-image-name | grep -i stopsig
输出类似 "StopSignal": "SIGUSR1" 就说明已正确写入。再配合 docker stop -t 30 your-container 测试实际行为，观察日志中是否有预期的清理动作。
