守护进程高可用的核心是崩溃后快速可靠恢复，而非追求永不崩溃；需将恢复逻辑嵌入运行时环境，按场景选择重启策略，并通过真实业务路径的健康检查验证服务能力。
守护进程的高可用性，核心不在于“永不崩溃”，而在于“崩溃后能快速、可靠地恢复”。真正有效的方案不是堆砌监控工具，而是把恢复逻辑嵌入运行时环境本身——让系统在服务退出的瞬间就做出反应，而不是等告警发出来再人工干预。
选对重启策略，比写十个脚本都管用
重启策略是第一道防线，必须按实际场景匹配，不能一概设为 always：
-
关键长期服务（如网关、数据库代理）：用
--restart=unless-stopped，既保证宿主机重启后自动拉起，又允许运维手动停机维护 -
任务型短周期进程（如批量处理脚本）：用
--restart=on-failure:3，只在非零退出时重试最多3次，避免死循环消耗资源 -
容器内轻量守护进程（如 Python watchdog）：推荐
--restart=no+ 外部守护工具，避免容器层和应用层双重重启逻辑冲突
健康检查不能只看进程存活，得验证服务能力
单纯检测进程是否 running 很容易漏掉“僵尸状态”——进程还在，但已无法响应请求。健康检查必须走真实业务路径：
- HTTP 服务：探测
/health或/ready，返回码为 200 且响应时间 - TCP 服务：用
nc -z localhost 8080验证端口连通性，再加一条简单协议交互（如发送PING收PONG） - 避免在健康接口里查数据库或调外部 API，否则检查本身可能成为故障放大点
Windows 下别依赖任务计划器做守护
任务计划器适合定时任务，不适合实时守护。它检测间隔最小为1分钟，且无法感知进程卡死、无响应等软故障：
- 优先用 NSSM 将程序封装为 Windows 服务，并在“恢复”选项卡中配置：第一次失败 → 重启服务；第二次失败 → 重启服务；后续失败 → 重启计算机（可选）
- 若需更精细控制（如判断日志关键词触发重启），可用 PowerShell 编写守护脚本，配合
Get-Process和Select-String实时扫描事件日志或应用日志 - 注意服务账户权限：默认 Local System 权限足够，若需访问网络资源，改用具备相应凭据的专用账户
Linux 下 systemd 是首选，但配置要精简
systemd 不仅能重启，还能管理依赖、限制资源、捕获标准输出，比自写 shell 脚本稳定得多：
- 关键字段示例：
Restart=on-failure、RestartSec=3（避免密集重启）、StartLimitIntervalSec=60、StartLimitBurst=5（1分钟内最多启动5次） - 加上
ExecStartPre=/bin/sh -c 'lsof -i :8080 &>/dev/null || exit 0'可提前释放端口，防止重启失败 - 日志统一走 journalctl，不用额外配 logrotate；用
StandardOutput=journal+console便于调试
