容器优雅退出保存上下文的核心是：捕获SIGTERM后立即阻塞新请求，于宽限期完成易失状态持久化，并借助preStop钩子做前置准备，同时应用层需支持可序列化上下文。
确保容器在优雅退出时保存上下文，核心在于三件事：信号捕获、状态持久化时机控制、以及与编排系统的协同。不是等收到 SIGTERM 才开始存，而是提前设计好“可中断点”和“最后快照”机制。
捕获 SIGTERM 并阻塞新请求入口
容器启动后必须主动监听 SIGTERM（Kubernetes 和 docker stop 默认发送），不能依赖默认行为。收到信号后第一动作不是立刻保存，而是停止接受新工作：
- HTTP 服务立即关闭监听端口或返回 503，同时让 readiness 探针失败，触发服务发现下线
- 消息消费者暂停拉取消息（如 RabbitMQ 的
channel.Cancel或 Kafka 的consumer.pause()） - 任务队列类服务标记自身为“draining”，拒绝新任务入队
在宽限期内完成上下文保存
保存操作必须落在 terminationGracePeriodSeconds（K8s）或 -t 参数（docker stop）指定的窗口内。常见误区是把所有清理逻辑堆在一起，导致超时被 SIGKILL 强杀：
- 优先保存易丢失的内存状态：会话缓存、未提交事务、临时计算中间结果
- 避免阻塞型 I/O：用带超时的写入（如
WriteContext(ctx, data)），超时则降级为日志记录+告警 - 对数据库连接，执行
db.Close()前先db.PingContext()确认连接可用，再发COMMIT或ROLLBACK
利用 preStop 钩子做前置准备
Kubernetes 的 preStop 钩子在 SIGTERM 发送前执行，适合做“不可逆准备”，比如：
- 向协调服务（如 etcd / Consul）注销实例注册信息
- 将运行时配置备份到共享存储（如 S3 / NFS），供下次启动读取
- 生成 checkpoint 文件（如 JVM 的
jmap -dump或 Python 的pickle.dump当前状态）
应用层需支持可序列化的上下文
如果上下文本身无法序列化，再完善的退出流程也白搭。开发阶段就要约束：
- 避免在内存中持有非序列化对象（如 open file handle、goroutine channel、数据库连接池句柄）作为上下文主体
- 用结构体字段替代闭包或函数引用；用 map[string]interface{} 或 Protobuf 替代 raw struct{} 直接存档
- 对敏感上下文（如用户 token、临时密钥），保存前加密，加载后校验完整性
