守护进程仅负责保活，不提供热重载；热重载必须由服务自身通过信号、文件监听、中心化配置或双缓冲等方式实现；二者协同：守护进程兜底进程级故障，服务处理运行时状态更新。
守护进程本身不直接执行业务逻辑，它的职责是“保活”——确保目标服务持续运行。真正的可配置性与热重载能力，必须由被守护的服务自身实现，而非守护进程提供。
守护进程只管“活没活”，不管“配没配”
Supervisor、systemd、openclaw-keep-alive 这类工具的核心逻辑是：监听目标进程的 PID 是否存在、退出码是否异常、CPU 或内存是否超限。它们能做的只有三件事：拉起进程、杀掉进程、记录日志。所有配置项（如启动命令、环境变量、重启策略）都在守护配置文件里静态定义，修改后必须 reload 守护进程本身才能生效——这本身就是一次中断。
因此，把“动态加载服务逻辑”的期望放在守护进程上，属于职责错位。它就像保安，只负责门禁和巡逻，不会帮你改办公室里的流程制度。
热重载必须由服务内部完成
要让服务在不重启的前提下更新逻辑或配置，关键在于服务自身的架构设计。常见且可靠的做法包括：
- 信号触发重载：服务监听 SIGHUP 或 SIGUSR2，收到后重新读取 config.yaml、重初始化路由表或模型权重；
- 文件变更监听：用 inotify（Linux）或 watchdog（Python）监控配置文件或代码模块目录，检测到修改后自动 reload；
- 中心化配置监听：接入 Nacos/Apollo/etcd，服务启动时注册 Watcher，配置变更时通过回调函数更新内存中的配置快照；
- 双缓冲原子切换：维护两套配置对象（old/new），新配置校验通过后，用 volatile 引用或 atomic 指针一次性替换，避免读写竞争。
守护进程可以配合热重载，但不能替代它
一个健壮的部署方案，是让守护进程和服务热加载机制协同工作：
- 守护进程确保服务永不“彻底死亡”——哪怕热加载失败导致 panic，也能立刻重启兜底；
- 服务自身实现毫秒级热重载，覆盖日常配置调整、策略更新、小版本逻辑变更等高频场景；
- 两者分工明确：守护进程处理“进程级故障”，服务自身处理“运行时状态更新”。
典型组合示例：AIGlasses_for_navigation
这个系统用 Supervisor 守护 Flask 主进程，同时在 Flask 内部实现了 API Key 热加载模块：
- Web 界面提交新 Key → 调用 /api/config 接口；
- Flask 后端将 Key 写入磁盘，并触发内存中 client 实例的重建；
- 整个过程无进程重启，请求持续可用；
- 万一中间出错崩溃，Supervisor 1 秒内拉起新进程，恢复服务。
