关键在于精准识别异常、安全触发恢复、防止误操作；需结合状态码、日志、依赖及健康检查判断，限制重启频率与窗口，并记录全过程。
编写自动化脚本巡检并重启异常服务，关键不是“一劳永逸地重启”，而是“精准识别异常 + 安全触发恢复 + 防止误操作”。不同系统（windows/linux/macos）机制差异大，但核心逻辑一致：定期检查、状态判定、条件重启、留痕闭环。下面分场景说明实用做法。
Windows：用 PowerShell 实现服务状态巡检与可控重启
适用于企业环境中的关键服务（如 SQL Server、自定义后台服务）。不建议用简单 net start，而应结合状态码、依赖项和启动超时判断是否真“异常”：
- 用
Get-Service "SvcName" | Select Status, StartType, DependentServices判断服务是否该自动运行但当前已停止 - 若状态为
Stopped且StartType是Automatic，再查事件日志最近 5 分钟是否有 Event ID 7024（启动失败）或 7000（服务未响应） - 确认后执行
Start-Service -Name "SvcName" -PassThru，并用$?.ToString()检查返回结果是否为True - 每次操作写入日志：
"$(Get-Date): SvcName restarted. ExitCode: $LASTEXITCODE" | Out-File C:\logs\svc-monitor.log -Append
Linux（systemd 系统）：优先用原生机制，脚本只做兜底
systemd 本身已支持故障自愈，脚本应作为补充手段（例如监控业务健康端点而非仅进程存活）：
Windows TTS (WSL2)
下载
在 Windows 11 上"直接发声"的 TTS（从 WSL2/TUI 调用 powershell.exe + System.Speech）。适用于用户说"说出来/读出来/语音播报/用TTS"，或反馈"没声音/tts 生成的 mp3 是空的/播不出来"，以及需要中文语音但 OpenClaw 内置 tts 不可用时。
- 在服务单元文件中启用可靠重启策略：
Restart=on-failure+RestartSec=10+StartLimitIntervalSec=600+StartLimitBurst=3（防雪崩） - 额外写一个检测脚本（如
/usr/local/bin/check-http-health.sh），用curl -sf http://localhost:8080/health | grep "UP"验证业务层可用性 - 若健康检查失败，再调用
systemctl try-restart myapp.service（比 restart 更安全，只对 running 状态服务生效） - 用
systemctl --state=failed定期扫描失败服务，避免遗漏未配置 Restart 的旧服务
跨平台通用原则：避免盲目重启，必须加“守门”逻辑
自动重启若无约束，可能掩盖真实问题，甚至引发连锁故障。所有脚本都应包含以下守门机制：
- 频率限制：同一服务 10 分钟内最多重启 2 次，超限则发告警并暂停自动操作
- 依赖验证：重启前检查其依赖服务（如数据库、Redis）是否正常，否则跳过并记录原因
- 启动后验证：重启成功后等待 5 秒，再执行业务探针（如 telnet 端口、curl 接口、读取 PID 文件）
- 静默窗口：每日 02:00–04:00 或维护窗口期内禁止自动重启，改由人工介入
附：一行可复用的 Windows 巡检重启命令（管理员权限下运行）
将以下命令保存为 watch-svc.ps1，替换 MyAppSvc 后即可使用：
