服务要重启，做到一半的请求怎么办？

可以把流程拆成三阶段：通知入口不要再把常规新请求送来；让已经接下的请求在期限内完成；在平台强制终止之前，预留时间记录未完成状态并退出。实际平台中，摘除流量和应用关闭可能并行发生，不应想象成一个瞬间完成的全局开关。

长连接、代理已经选好的请求以及传播延迟，都可能使停机开始后仍有请求到达。应用要有自己的拒绝新工作规则，入口也要支持连接排空。只把健康检查改成失败，却继续无限接受工作，或只关应用而不考虑入口，都可能在切换时暴露空档。

Spring Boot 3.5 文档说明，优雅关闭给已有请求完成的时间，并限制新请求；每个关闭阶段的等待可通过 spring.lifecycle.timeout-per-shutdown-phase 设置。不同内嵌服务器拒绝新请求的方式不同，不能要求所有框架都返回同一个状态码。

Kubernetes 普通 Pod 终止流程还包含 preStop、终止信号与平台的终止期限。preStop 也消耗这个收尾时间，不能把它当成额外赠送的等待。若平台更早强制终止，应用设置更长的等待也救不了在途请求；预算需要包含必要的退出阶段和余量。

假设零秒收到停机通知，一秒时不再接受新业务，原有请求甲在四秒完成，请求乙要到四十秒才完成，而平台在三十秒期限后可能强制结束。甲有机会正常返回；乙不能仅凭“开启优雅停机”就保证完成。这个时间线是设计练习，没有运行真实集群。

乙若已经提交数据库而响应没送达，客户端仍可能面对结果未知。停机策略需要和幂等重试、结果查询相配合。把请求从 HTTP 线程转交后台线程，也不等于它已经可靠保存；进程退出时，只有内存里的任务仍可能消失，必须明确任务归属和持久化时机。

在自己的测试环境准备短请求、可控慢请求和超时请求，开始停机后检查新请求是否停止接纳、已有请求是否完成、超时任务有没有清楚的结果。测试应使用平台真实的终止方式；某些 IDE 的停止按钮可能立即终止进程，和正常关闭流程不同。

记录接纳时间、业务提交时间、响应完成时间与进程退出时间，再对照客户端看到的结果。后台消费者、定时任务和自建线程池也要有各自的停止规则，不能把 Web 服务器收尾等同于整个应用所有工作均已完成。最后验证超时后的恢复过程，才知道剩余工作会被谁接手。