生命周期与运维：热更、重启、优雅关停
这一章关注“能长期跑”：配置变更如何生效、出现异常如何修复、进程退出如何收口，决定了系统能不能稳定上线。
你需要掌握的要点
- 变更不是“文件一改就重启”：应先分类（可热更/需重启/无影响）
- 重启不是黑盒：需要交接信息让用户在原会话看到结果
- 关停必须按稳定顺序收尾：先停副作用来源，再广播，再关网络
1) 配置变更分类：hot reload / restart / noop
建议把“变更如何生效”做成明确规则，而不是文件变化就一律重启：
- hot reload：可不停进程应用（例如纯运行态策略变更）
- restart：必须重启才能生效（例如底层依赖需要重建）
- noop：无影响（避免抖动）
2) 延迟重启直到空闲（defer until idle）
对生产/长任务场景，建议把重启做成“可等待的动作”：
- 统计当前活动任务与队列情况
- 在超时窗口内尽量等到空闲再触发重启
- 超时后给出明确结果（继续重启或放弃）
3) 重启交接（sentinel）：让重启结果对用户可见
重启不应是黑盒。建议用“交接文件/哨兵”在旧进程与新进程之间传递：
- 谁请求了重启、为何重启
- 是否重启成功、何时恢复
这样用户可以在原会话看到“已重启/重启失败”的结果，而不是只看到连接断开。
4) 优雅关停：稳定顺序比“能关掉”更重要
建议把关停步骤固定为可重复执行的顺序：
- 先停发现/暴露与副作用来源（避免新连接与新任务）
- 再停 channels / plugins / watchers（停止外部输入与扩展）
- 广播
shutdown（让客户端可见） - 最后关闭 ws/http（收口网络）
失败场景与排障入口
- “任何小改动都触发重启”：先确认 reload plan 是否做了 hot/restart/noop 分类；再对照 Gateway 配置 与 日志 看变更路径与决策。
- 重启后用户只看到断线：检查是否有“重启交接信息”（sentinel）把结果回填到原会话；并在 Control UI / 日志 里确认重启链路是否完整。
- 关停后仍有残留任务/端口占用：按“先停副作用 → 再广播 → 最后关网络”的顺序排查；必要时用 Doctor 与 故障排除 做诊断闭环。
验收清单
- 小改动不会引发频繁重启（noop/hot/restart 分类正确）。
- 重启会尽量等待空闲，且超时有明确行为。
- 重启后用户能看到可读结果（交接信息生效）。
- 关停顺序稳定，不会出现“半关停半运行”的悬挂状态。
相关入口（站内）：
读源码入口（可选）
src/gateway/config-reload.tssrc/gateway/server-reload-handlers.tssrc/infra/restart.tssrc/gateway/server-restart-sentinel.tssrc/infra/restart-sentinel.tssrc/gateway/server-close.ts