Docker stop默认先发SIGTERM再超时发SIGKILL，顺序固化不可配置；唯一可调参数是--time（默认10秒），用于控制SIGKILL触发时机；docker kill则直发SIGKILL，跳过SIGTERM阶段。
docker本身不提供“配置sigterm与sigkill优先级”的选项——因为它们根本不是并列可选的信号，而是有严格先后顺序的协作机制：sigterm总是先发，sigkill仅在超时后作为兜底强制手段。所谓“优先级”，其实是docker stop流程中固化的两阶段行为，不能颠倒，也不能跳过第一阶段。
理解 stop 的默认两阶段信号流程
Docker stop 的设计就是“先礼后兵”：
- 第一步：向容器内 PID 1 进程发送 SIGTERM（信号 15），通知它准备退出
- 第二步：若进程在超时时间内未退出，Docker 自动补发 SIGKILL（信号 9）强制终止
这个流程不可禁用 SIGTERM、也不允许把 SIGKILL 提前或设为默认。它不是配置项，而是 Docker 引擎内置的生命周期管理逻辑。
真正可调的只有超时时间（影响 SIGKILL 触发时机）
你无法改变“先 SIGTERM 后 SIGKILL”的顺序，但可以控制第二步何时启动：
- 默认等待 10 秒：docker stop my-app
- 自定义延长至 30 秒：docker stop --time=30 my-app
- 缩短至 2 秒（慎用）：docker stop --time=2 my-app
更长的 time 值，等于给 SIGTERM 留出更多响应窗口，降低 SIGKILL 被触发的概率；更短则相反。这是最直接、最安全的干预点。
让 SIGTERM 真正生效的关键配合项
光靠 docker stop --time 不够，容器内应用必须能收到并响应 SIGTERM：
- 主进程必须是 PID 1：避免用 sh -c "myapp" 启动，否则 shell 会拦截信号却不转发；推荐用 exec "$@" 或直接 CMD ["myapp"]
- 代码中显式监听 SIGTERM：例如 Node.js 中 process.on('SIGTERM', cleanup)，Go 中 signal.Notify(c, syscall.SIGTERM)
- 必要时声明期望信号：在 Dockerfile 加一行 STOPSIGNAL SIGTERM（虽默认即此值，但显式声明更清晰）
什么时候会绕过 SIGTERM 直接触发 SIGKILL？
只有两类操作会跳过第一阶段：
- docker kill my-app（默认行为，直发 SIGKILL）
-
手动发 kill -9
（在容器内或宿主机上）
注意：docker kill --signal=SIGTERM 是合法的，但它不会自动升级为 SIGKILL，也就没有超时机制——如果进程卡住，它就一直卡着。这和 docker stop 本质不同。
