任务依赖核心是状态判断而非时间排队，本质由数据时效性驱动，需区分“数据时间”与“调度时间”，依赖配置必须落实到实例粒度，并支持同/跨周期、偏移、多种拓扑关系及动态事件响应。
自动化调度系统里的任务依赖，核心不是“谁先谁后”，而是“什么条件下能启动”。它本质是一套状态判断机制，不是简单的时间排队。
依赖关系由数据时效性驱动
多数调度失败，根源在于没理清“数据时间”和“调度时间”的区别。比如一个每日2点跑的报表任务，它的业务日期（$bizdate）默认是前一天，而实际执行时间（$cyctime）是当天凌晨2点。如果下游任务要读上游昨天的数据，就必须明确依赖“上游昨天实例”，而不是笼统配个“上游任务”。跨周期依赖（如小时任务依赖天任务）、偏移依赖（如今天任务依赖前3天数据）都得靠这个逻辑落地。
- 同周期依赖：上下游调度频率一致，实例一一对应，配置最简单
- 跨周期依赖：上游是天级，下游是小时级，需在依赖配置中指定时间维度与偏移范围
- 依赖偏移：用区间模式（如-3,-1）或列表模式（如-7,-1,0）精确指定依赖哪些上游实例
依赖类型决定执行拓扑结构
任务之间不是只有串行一种关系。FS（完成-开始）最常见，但SS（开始-开始）支持并行启动，FF（完成-完成）适合收尾协同，SF（开始-完成）则用于反向控制。实际调度图是一个有向无环图（DAG），根节点无父依赖，叶子节点无子依赖，中间节点可能有多个父任务——只有所有父任务实例都成功，子任务才被触发。
- 任务间依赖：不同任务之间的常规上下游关系
- 任务自依赖：同一任务不同周期实例间的约束，比如“今天必须等昨天跑完”
- 工作流自依赖：整个工作流上一周期所有任务都完成后，本周期才启动
- 依赖下游：极少数场景，如异常回滚时需等待下游确认状态
动态依赖需要事件与规则双驱动
静态配置解决80%场景，剩下20%靠动态响应。比如上游任务因资源不足延迟30分钟，系统不能干等，而应通过事件监听捕获该异常，触发备用路径或自动调整下游启动窗口。更进一步，可基于历史失败率、资源负载预测模型，在任务提交阶段就预判潜在阻塞点，提前插入缓冲或降级策略。
- 依赖链路监控：记录每个实例的实际依赖满足时间，而非理论调度时间
- 超时兜底机制：设置最长等待阈值，超时自动告警或启用降级逻辑
- 依赖快照保存：每次调度生成依赖关系快照，便于故障回溯与链路审计
配置关键在实例粒度而非任务粒度
很多团队卡在“配了依赖却没生效”，问题常出在混淆了“任务”和“实例”。调度系统真正调度的是实例——某次具体执行。依赖配置必须落到实例层面：哪个上游实例、在什么时间偏移下、产出什么数据范围，下游才据此校验自身启动条件。DataWorks、Airflow等平台的依赖配置界面看似在选任务，底层实际是在定义实例间的数据契约。
- 查看上游任务的调度周期与时间维度设置，确认是否匹配下游预期
- 检查实例日志中的实际依赖检查结果，而非仅看任务状态图标
- 用测试实例手动触发，验证偏移参数在真实时间上下文中的计算结果
