优雅关闭web容器的关键是“等完再停”，需确保sigterm触达应用、应用监听并响应信号、设置合理宽限期，并通过日志和退出码验证。
要让正在处理长连接请求（如 WebSocket、SSE、长轮询或大文件上传）的 Web 容器优雅关闭，核心不是“快停”，而是“等完再停”——给应用留出时间完成已有连接、拒绝新请求、释放资源。关键在于信号配合、超时设置和应用层协同。
确保 SIGTERM 能真正触达你的 Web 应用
很多 Web 容器失败优雅关闭，根本原因是 PID 1 进程没收到 SIGTERM。常见陷阱包括：
- 用
sh -c "exec myserver"启动，导致 shell 占据 PID 1，而 shell 默认不转发信号 - Dockerfile 中未使用 exec 形式启动（应写成
ENTRYPOINT ["./server"]，而非ENTRYPOINT sh -c "./server"） - 未显式声明停止信号（可加
STOPSIGNAL SIGTERM到 Dockerfile）
推荐做法：启动命令用 exec "$@" 包装，或直接以应用二进制为 PID 1；Kubernetes 用户可在 Pod spec 中加 terminationMessagePolicy: FallbackToLogsOnError 辅助调试。
在应用中监听并响应 SIGTERM
Web 框架需主动注册信号处理器，进入“退出准备态”。不同语言典型写法：
-
Node.js：
process.on('SIGTERM', () => { server.close(); /* 等待活跃连接结束 */ }) -
Go：用
signal.Notify(c, syscall.SIGTERM)接收信号，调用http.Server.Shutdown()等待活跃请求完成 -
Python（FastAPI/Flask）：配合
uvicorn的--graceful-timeout或自定义信号 handler +server.shutdown() -
Java（Spring Boot 2.3+）：启用
server.shutdown=graceful，自动等待请求完成（默认 30 秒）
重点不是“立刻退出”，而是“不再接受新请求 + 给活跃连接设超时上限”。
延长停止宽限期，匹配实际业务耗时
默认 10 秒对长连接远远不够。必须根据最长可能的连接持续时间（比如视频流上传、批量导出）设定合理宽限期：
- Docker CLI：
docker stop --time=60 my-web-container（单位：秒） - Docker Compose：
stop_grace_period: 60s写入服务配置 - Kubernetes：
terminationGracePeriodSeconds: 60设置在 Pod spec 中
建议值参考：普通 HTTP 请求 → 15–30 秒；含上传/导出 → 60–180 秒；WebSocket 保活连接 → 需配合应用层心跳与主动断连逻辑，宽限期可设为 90 秒并辅以连接池主动关闭。
验证是否真优雅：看日志和退出码
停止后别只看容器状态，要确认行为是否符合预期：
- 执行
docker ps -a | grep my-web，观察 STATUS 是否显示Exited (0)（正常退出）；若为Exited (137)，说明被 SIGKILL 强杀（大概率超时） - 运行
docker logs my-web-container --tail 20，查找关键词如shutting down、gracefully closing、received SIGTERM、all connections drained - 检查应用日志末尾是否有“拒绝新连接”的提示，以及最后一条活跃请求是否自然结束（而非中断报错）
不复杂但容易忽略
