关键在于确保主进程作为PID 1接收并响应SIGTERM：需用exec格式启动、注册信号处理器、配置足够终止宽限期，并排除nohup等干扰因素。
关键在于让主进程能真正收到并响应 SIGTERM，而不是被屏蔽、忽略或根本没机会处理。
主进程必须是 PID 1 且可捕获信号
容器中只有 PID 为 1 的进程才能直接接收 Docker 发送的 SIGTERM。如果启动方式用了 shell 形式（如 CMD nginx -g "daemon off;"），实际 PID 1 是 /bin/sh，而 nginx 是它的子进程——shell 默认不转发信号，导致 nginx 收不到 SIGTERM。
- 改用 exec 模式：CMD ["nginx", "-g", "daemon off;"]
- 或显式使用 tini/dumb-init 作为 init 进程，自动转发信号
- 验证方式：进入容器执行 ps -eo pid,ppid,comm，确认应用进程 PID 确实为 1
应用代码需主动注册 SIGTERM 处理器
即使信号送达 PID 1，程序默认行为仍是立即退出。要实现优雅关闭，必须在代码中显式监听并阻塞等待该信号，再执行清理逻辑。
- Go 中用 signal.Notify 注册 syscall.SIGTERM
- Python 中用 signal.signal(signal.SIGTERM, handler)
- Node.js 中用 process.on('SIGTERM', ...)
- 清理动作应包括：停止接收新请求、等待活跃连接完成、关闭数据库连接、保存状态等
配置足够长的优雅终止窗口
Docker 默认只给 10 秒宽限期，Kubernetes 默认是 30 秒。若清理耗时更长，超时后会强制发 SIGKILL，前序工作白做。
- Docker CLI：用 docker stop --timeout=30 调整
- Docker Compose：在 service 下设置 stop_grace_period: 30s
- Kubernetes：在 Pod spec 中设置 terminationGracePeriodSeconds: 45
- 数值应略大于应用最坏情况下的清理耗时
避免常见干扰因素
有些看似无关的配置会悄悄破坏信号链路。
- 不要在启动脚本里用 nohup 或 & 后台运行主进程，这会脱离前台进程组
- 健康检查探针（liveness/readiness）在终止过程中应快速失败，避免干扰调度器判断
- 测试时用 docker kill --signal=SIGTERM 手动触发，比 docker stop 更直接可控
- 日志中确认收到 SIGTERM 并开始执行 shutdown 流程，而非静默退出
