Queueable Apex — Stack Depth Control

同学们，咱们今天来看一个非常有用的技巧，如何在 Salesforce 里控制那种“链式作业”——就是一个作业完成后，再自动触发下一个作业，一环扣一环。这种模式虽然灵活，但很容易失控，比如递归调用太深，或者一天之内提交的异步任务太多，超过了平台的上限。 好在平台给我们提供了一个安全阀门，那就是 ，System.enqueueJob， 配合 ，AsyncOptions， 里的 ，MaximumDeliverableStackDepth（最大可传递堆栈深度），。简单说，你可以给队列作业设定一个“最大深度”，比如 5 层。那么当作业一层层向下传递的时候，如果当前深度已经达到 5，它就不会再产生下一个作业了，链条自然终止。 那怎么检查和利用这个深度呢？，System.AsyncInfo， 类提供了几个非常方便的运行时方法，比如 ，hasMaxStackDepth()， 判断是否配置了最大深度，，getCurrentStackDepth()， 拿到当前作业是第几层，还有 ，getMaximumStackDepth()， 获取你设定的上限。另外它还能提供 ，getMinimumQueueDelayInMinutes()，，就是作业之间最小的延迟时间，有助于平滑作业的提交频率。 书本上给了一个经典的 ，Fibonacci 数列， 示例。Fibonacci 计算本来很适合递归，但在异步作业里如果无限制地链式调用，可能一天产生的作业数很快就会撞到每天的最大异步执行限制。所以在这个例子里，每次队列作业只计算一步，然后检查当前深度。如果还没到设定的最大深度，就创建下一个作业继续算；一旦，达到最大深度，就不再链接下一步了，而是把当前的中间结果直接保存到数据库里，，然后结束。这样既避免了无休止的链式作业，又保证不会超过每日的执行上限。 这种模式对于任何需要长时间运行、分步处理的链式操作都非常重要，因为你可以精准地控制资源使用——就像给一台机器装上了自动“熔断”装置，当深度或风险太高时，主动停下来，先把成果存好，而不是一股脑地往前冲，最后全被平台限制挡住，前功尽弃。 所以，下次你需要设计链式的异步作业时，一定要记得用上 ，AsyncOptions， 设定最大深度，配合 ，AsyncInfo， 来动态判断，打造一个稳健又可控的执行流程。这就是今天我们这一页幻灯片的精髓啦。