Docker 默认通过 docker stop 向容器 PID 1 发送 SIGTERM 实现优雅停止，需应用捕获该信号、启动时用 exec "$@" 确保直接接收、合理设置 --stop-timeout、并通过退出码和日志验证是否真正优雅退出。
docker 默认使用 docker stop 命令终止容器时，正是通过向容器主进程（pid 1）发送 sigterm 信号来实现“优雅停止”的——前提是容器内应用能正确捕获并响应该信号。关键不在于手动发信号，而在于确保整个链路支持优雅退出：镜像构建、应用逻辑、stop 参数协同工作。
确认容器主进程能接收并处理 SIGTERM
容器中 PID 1 进程默认不会转发信号（Linux 内核限制），若应用本身未监听 SIGTERM，或启动方式绕过了信号传递（如直接执行二进制、未用 exec 启动），则 SIGTERM 会被忽略。
- 应用代码需注册
SIGTERM处理器，完成清理（如关闭连接、刷写缓存、保存状态）后正常退出 - 启动脚本中推荐用
exec "$@"替代"$@"，确保应用以 PID 1 运行并直接收信号 - 避免使用
sh -c 'your-command'包裹主命令，它会让 shell 占据 PID 1，而 shell 默认不转发SIGTERM
合理设置 stop_timeout（可选但重要）
docker stop 发送 SIGTERM 后会等待一段时间，超时再发 SIGKILL 强杀。默认 10 秒，对需要较长清理时间的服务可能不够。
- 启动时指定：
docker run --stop-timeout=30 nginx - 或在
Dockerfile中声明：STOPSIGNAL SIGTERM+STOP_TIMEOUT=30（需 Docker 20.10+ 且运行时支持） - 也可修改容器配置：
docker update --stop-timeout=45 my-container
验证 SIGTERM 是否真正送达
别依赖“容器停了”就认为优雅退出成功——可能只是被 SIGKILL 终止的。
- 查看容器退出码：
docker inspect my-container | jq '.State.ExitCode'；优雅退出应为 0（或应用自定义的正常退出码），非 137（SIGKILL的典型码） - 在应用日志中搜索
received SIGTERM、shutting down等关键词 - 临时进入容器测试：
docker exec -it my-container kill -TERM 1，观察日志和行为是否符合预期
补充：STOPSIGNAL 指令的作用
Dockerfile 中的 STOPSIGNAL 并不改变 docker stop 的默认行为（它始终发 SIGTERM），而是用于定义 docker stop 在未显式指定信号时的 fallback 信号，同时影响 docker kill 的默认信号。
- 写
STOPSIGNAL SIGQUIT后，docker stop仍发SIGTERM；但docker kill my-container会发SIGQUIT - 真正影响
docker stop发什么信号的，只有命令行参数：docker stop --signal=SIGUSR2 my-container - 除非有特殊需求，保持默认
SIGTERM即可，无需在 Dockerfile 中覆盖
