服务启动失败主因是依赖关系错乱，需先用sc qc 服务名或services.msc依存关系选项卡查清依赖项，再逐个验证其状态与启动类型，错误1068即表明至少一个依赖服务未运行或异常。
服务启动失败常因依赖关系错乱，比如该等的服务没等、不该等的却卡着，修改依存关系是治本手段，不是简单重启或禁用就能解决的。
先查清当前服务到底依赖谁
盲目改配置容易引发连锁故障。Windows 下打开命令提示符（管理员），运行：
- sc qc 服务名 —— 查看该服务声明的依赖项（即“DependOnService”字段）
- services.msc → 右键服务 → “属性” → “依存关系”选项卡，直观看到“此服务依赖”和“被哪些服务依赖”
- 若服务报错 1068，就说明 DependOnService 列出的至少一个服务未运行或状态异常，必须逐个验证其状态和启动类型
Linux（systemd）下显式声明依赖链
systemd 不按文件名或安装顺序启动，只认单元文件里的依赖指令。关键不是“谁先”，而是“谁等谁”：
Windows TTS (WSL2)
下载
在 Windows 11 上"直接发声"的 TTS（从 WSL2/TUI 调用 powershell.exe + System.Speech）。适用于用户说"说出来/读出来/语音播报/用TTS"，或反馈"没声音/tts 生成的 mp3 是空的/播不出来"，以及需要中文语音但 OpenClaw 内置 tts 不可用时。
- 在 /etc/systemd/system/your-service.service 的
[Unit]段中添加：Wants=postgresql.serviceAfter=postgresql.service
（仅After不够，它只控时序；Wants或Requires才建立实际依赖） - 改完务必执行：systemctl daemon-reload，否则配置不生效
- 验证是否生效：systemctl list-dependencies --after your-service.service 或 systemctl show -p After,Requires,Wants your-service.service
Docker Compose 中不能只靠 depends_on
depends_on 只保证容器进程起来，不保证服务就绪。真正要解决启动顺序冲突，得结合健康检查：
- 为被依赖服务（如 db）加上
healthcheck，例如检测 MySQL 是否能响应 ping - 在依赖方（如 app）的
depends_on中指定条件：
db:<br> condition: service_healthy
- 同时应用代码里加连接重试逻辑，避免健康检查通过后瞬间网络抖动导致失败
改完别跳过验证环节
修改依存关系后，不能直接上线。必须做三件事：
- 用 systemctl start 服务名（Linux）或 net start 服务名（Windows）手动触发启动，观察是否成功
- 查日志：journalctl -u 服务名 -n 50 -f（Linux）或 事件查看器 → Windows 日志 → 系统（Windows）找最近错误
- 模拟断电重启或宿主机重启，确认服务在真实启动流程中仍能按预期顺序拉起
