重启后服务没起来：恢复动作与依赖设置

多数情况是服务的"恢复"选项没配置：服务崩了没人拉起，重启后也没人负责启动它，应用自然连不上数据库或接口。 为什么重启后服务起不来 常见原因三类。启动类型是"手动"或"禁用"，重启后当然不会运行；依赖没理顺，它依赖的服务还没就绪它就先起，起一次失败一次；服务用专用账号登录运行，那边密码改了这边没更新，登录失败直接起不来。三种原因在服务属性里都能查证。 起不来先看日志 判断属于哪类原因，事件查看器的"系统"日志最快：服务启动失败会记 7000 或 7001，描述里写明失败原因和它等待的依赖；凭据失效型会记 7038，提示登录失败，对应上面第三类。先看日志再动手，比逐项试错快得多。 恢复选项怎么配 services.msc 双击服务，切到"恢复"页：第一次失败、第二次失败建议设为"重新启动服务"，重启服务的延迟设 1 分钟，给依赖方留出就绪时间；第三次失败慎用"重新启动计算机"，改成"运行一个程序"推一条告警更稳妥。这页配置建议对所有常驻服务检查一遍，尤其是应用依赖的数据库、消息队列、缓存服务。 依赖顺序怎么处理 服务属性里能看到它依赖谁、谁依赖它。确认存在先后问题时，把被依赖服务的启动类型设为"自动（延迟启动）"是简单有效的办法——晚半分钟启动，顺序问题自然抹平，不用写脚本控制时序。反过来，把某服务手动禁用之前，先看看有没有别人依赖它，一禁一串都起不来。 登录型服务的注意点 用域账号或专用账号运行的服务，密码变更后必须在服务属性"登录"页同步更新密码，否则永远起不来。把"改密码必改服务账号"写进运维流程，这一步漏掉的事故非常多。 建议：每次部署新服务，顺手把启动类型、恢复动作、依赖关系三项配齐，此后重启就不再是事故。