@xuxueli 因项目需要，最近也在关注TO DO里的“流程任务”，期待它早日出炉。关于“流程任务”，有几点想法：
假定一个流程任务，A->B->(C,D)->E，其中CD并行，其余串行。A~E中部分为存量定时任务。
1. 什么算“轻量依赖”？ 如果是强依赖，即稍有乱序或重叠执行就出问题，那么这个流程任务最好被直接设计成一个整体任务（可以搞成聚合服务），流控如果复杂最好上工作流。如果说是弱依赖，即允许存在一定的乱序或重叠执行，只是A~E的触发链用simpleTriggr或cronTrigger不好描述，我觉得这应该算“轻量依赖”，也就是不需要为依赖做那么多的保障，能方便描述这种链式触发时机即可。
2.前后置依赖检查还是“流程任务”？ TO DO里说要弃用子任务模式，这点挺认同。试用了下xxl-job v1.9.2，就是简单的后置触发，这样做优点在于简单、调度代码易实现，缺点在于环的问题需要妥善处理（搞了三个测试任务，2是1的子任务，3是2的子任务，2是3的子任务，执行1，几分钟之后，2和3循环执行的日志列表足足三千多页，而且控制台上没有可以停止这种环的按钮，那个暂停对环没用），除了环，对于触发链条的整体描述也不够清晰，在可视化和监控上会比较麻烦。
3. “流程任务”的几个潜在问题 （1 存量任务执行频度的干扰：假如A~E中B为存量crontrigger触发的任务，如果不想让其周期性的执行影响流程任务，最好把B停掉。这个可以做强制检查，或者作为最佳实践推荐。 （2 是否存在死链：比如执行到B失败，下一次还是从A开始执行，因为A短期内已执行成功（也可能是正常cron调度成功的），存量任务大都是独立定时任务，此时A的执行逻辑极有可能定义为执行失败，那么B及之后的任务就没有机会执行。建议增强整体的失败重试机制，比如对于流程任务整体，设置“断点续执行”（配合最大执行次数的限定），先从log表中拿执行状态，然后决定从A还是B或C开始执行。 (3 流程任务中的元任务是否可以为别的流程任务：首先，元任务肯定不能为自身，如果可以，且流程任务里有一些简单的串并行支持，那么互相结合就能描述相对复杂的串并行，但是这样也有潜在的环需要检测，实现细节上还是要做不少处理；如果不可以，那么干脆就支持简单的串并行好了，其实绝大多数场景都够用了，不够用的估计也不算“轻量依赖”。