Windows通过注册表DependOnService多字符串值声明依赖服务名（如Netlogon），确保前置服务先启动；仅设DelayedAutostart无法保证依赖就绪，必须显式配置依赖项才生效。
修改服务依赖关系和启动先后顺序，关键在于明确“依赖谁”和“在谁之后启动”，不同系统用不同机制实现，不能只改顺序而不声明依赖。
Windows 用注册表调整服务依赖
服务名对应注册表路径：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\服务名。重点操作有两个：
- 添加或编辑 DependOnService 多字符串值：每行填一个被依赖的服务名称（如
Netlogon、LanmanWorkstation），系统会强制先启动这些服务 - 不靠修改启动类型或延迟时间来模拟依赖：仅设 Delayed Auto 启动无法保证前置服务已就绪，必须写入 DependOnService 才生效
Linux systemd 用 .service 文件配置
核心指令都在 [Unit] 段，需组合使用才可靠：
- Requires=xxx.service：强依赖，xxx 启动失败，本服务直接跳过
- Wants=xxx.service：弱依赖，xxx 启动失败不影响本服务尝试启动
- After=xxx.service：只控制顺序，不检查是否成功；常与 Wants 或 Requires 配合使用
- 改完必须执行
systemctl daemon-reload，否则新配置不加载
Docker Compose 中的 depends_on 不等于等待就绪
depends_on 只控制容器启动顺序，不判断内部服务是否真正可用：
- 数据库容器启动完成 ≠ PostgreSQL 已接受连接
- 必须配合 healthcheck（如
pg_isready）+ 外部等待脚本（如wait-for-it.sh）才能确保依赖服务就绪 - 单纯写
depends_on: [db]而不加健康检查，在生产环境容易导致应用启动报错
Kubernetes 用 Init Container 实现前置等待
Pod 级别的依赖控制靠初始化容器，不是靠 Deployment 的启动顺序：
- Init Container 在主容器前运行，阻塞主容器启动直到它退出成功
- 常用方式：用
busybox+nslookup检查 Service DNS 是否解析，或用wait-for-it.sh连接目标服务端口 - 注意：Service 必须先于 Pod 创建，否则 Init Container 无法解析服务名
