精通 Salesforce Future 方法：Apex 异步编程深度解析

背景与应用场景

作为一名 Salesforce 开发人员，我们每天都在与平台的执行限制 (Governor Limits) 打交道。Salesforce 是一个多租户 (multi-tenant) 环境，为了保证所有用户都能公平地共享资源，平台对代码执行的方方面面都设置了严格的限制，例如单次事务中的 SOQL 查询次数、DML 操作行数以及 CPU 处理时间等。在标准的同步 (synchronous) 执行模式下，例如由用户操作触发的 Apex Trigger，所有逻辑必须在这些限制内快速完成，否则事务将失败并回滚。

然而，在很多业务场景中，我们需要执行一些耗时较长或资源密集型的操作。如果我们试图在同步事务中处理这些任务，不仅会极大地影响用户体验（页面长时间无响应），还极有可能触及 Governor Limits。为了解决这一挑战，Salesforce 提供了 Apex 异步编程 (Asynchronous Apex) 模型，而 Future Methods 便是其中最基础、最常用的一种实现方式。

Future methods 允许我们将某些方法的执行推迟到后台，在一个独立的、拥有更高执行限制的事务中运行。这使得它们成为处理特定问题的理想工具。主要应用场景包括：

1. 从 Apex Trigger 中执行 Web 服务调用 (Callout)

Salesforce 平台规定，在一个事务中，不能在执行了数据库修改 (DML) 操作之后再进行外部服务调用 (Callout)。这是因为外部服务的响应时间不可控，长时间等待会锁定数据库资源，影响平台稳定性。然而，业务上常见的需求是在创建或更新一条记录后（例如，新建客户后通知外部财务系统），立即通知外部系统。Future method 完美地解决了这个问题，我们可以将 callout 逻辑封装在一个 future method 中，从 trigger 中调用它。这样，callout 就会在一个新的、与原始 DML 操作分离的事务中异步执行。

2. 隔离混合 DML 操作 (Mixed DML Operation)

在同一个事务中，Salesforce 不允许同时对设置对象 (Setup Objects)（如 User, Profile）和非设置对象 (Non-setup Objects)（如 Account, Contact）进行 DML 操作。尝试这样做会导致 `MIXED_DML_OPERATION` 错误。例如，你可能希望在一个自动化流程中，当一个 Opportunity 关闭时，创建一个 Case 记录（非设置对象）并同时更新相关 User 的某个字段（设置对象）。通过将对 User 的更新操作放入一个 future method 中，我们就能将这两个 DML 操作分离到不同的事务中，从而绕过此限制。

3. 避免同步 Governor Limits

对于一些复杂的计算或数据处理任务，例如在订单生成后进行复杂的利润计算和分摊，这些操作可能会消耗大量的 CPU 时间或执行过多的 SOQL 查询。将这些“重活”移交给 future method，可以让主事务快速完成，从而为用户提供流畅的前端体验。后台的 future job 会在资源可用时处理这些复杂逻辑，因为它享有更高的异步 Governor Limits（例如，同步事务中 SOQL 查询上限为 100 次，而异步则为 200 次）。

原理说明

Future method 的核心是 `@future` 注解。当你在一个 Apex 方法前加上这个注解时，你就在告诉 Salesforce 平台：“这个方法不需要立即执行，请你将它放入一个队列中，在系统资源允许的时候再运行它。”

其工作流程如下：

调用：当代码执行到一个 future method 的调用时，系统不会立即执行该方法体内的逻辑。相反，它会将这个方法的请求以及传递的参数序列化后，添加到一个异步处理队列中。
排队：这个请求会在队列中等待，直到 Salesforce 的异步处理框架有可用的资源来处理它。这个过程通常很快，但并不能保证是瞬时的。
执行：一旦资源就绪，Salesforce 会启动一个新的 Apex 事务来执行这个 future method。这个新事务拥有自己独立的 Governor Limits，并且这些限制通常比同步事务更为宽松。
独立性：由于 future method 在其自己的事务中运行，它无法直接访问调用它的那个原始事务的状态。所有需要的数据都必须通过方法参数传递进去。这也是为什么 future method 的参数类型受到限制的原因。

简单来说，`@future` 注解就像是为你的代码逻辑开启了一个“后台线程”，让主流程可以继续前进，而不必等待耗时的任务完成。

示例代码

让我们来看一个来自 Salesforce 官方文档的经典示例。这个场景是：当一组 Account 记录被创建或更新后，需要将它们的账单信息发送给一个外部的计费系统。这是一个典型的 callout 场景，非常适合使用 future method。

首先，我们定义一个包含 future method 的类。这个方法接收一个 Account ID 列表，然后查询这些 Account 的信息，并（模拟）将它们发送到外部服务。

public class AccountProcessor {
    // @future 注解表明这是一个异步方法。
    // (callout=true) 参数是必须的，因为它明确地告诉 Salesforce 这个方法将要执行外部调用。
    // 如果没有这个参数，在 future method 中进行 callout 会导致运行时异常。
    @future(callout=true)
    public static void processAccounts(List<Id> accountIds) {
        
        // 最佳实践：在 future method 内部查询最新的数据。
        // 不要直接传递 sObject 列表作为参数，因为在方法执行时，这些数据可能已经过时。
        // 通过传递 ID 列表并在方法内重新查询，可以确保我们处理的是最新的记录状态。
        List<Account> accounts = [SELECT Id, Name, BillingStreet, BillingCity, BillingState, BillingPostalCode 
                                  FROM Account WHERE Id IN :accountIds];

        // 遍历需要处理的 Account 记录
        for (Account acc : accounts) {
            // 在实际场景中，这里会构建一个 HTTP 请求（如 REST 或 SOAP）
            // 并将其发送到外部服务的端点。
            // 例如：
            // HttpRequest req = new HttpRequest();
            // req.setEndpoint('https://api.billing-system.com/invoice');
            // req.setMethod('POST');
            // req.setBody(...); // 使用 acc 的信息构建请求体
            // Http http = new Http();
            // HTTPResponse res = http.send(req);

            // 为了演示，我们仅使用 System.debug 打印一条日志，模拟信息已发送。
            System.debug('Processing account and sending billing info for: ' + acc.Name);
        }
    }
}

接下来，我们需要在某个地方调用这个 future method。一个常见的场景是在 Account 的 trigger 中调用它。假设我们希望在 Account 创建后触发这个流程。

trigger AccountTrigger on Account (after insert) {
    // 创建一个 List 来收集需要异步处理的 Account 的 ID。
    // 这是一个非常重要的批量化 (bulkification) 实践。
    // 我们不应该在循环中为每条记录都调用一次 future method，
    // 因为每次调用都会消耗一个 future 调用限额。
    List<Id> newAccountIds = new List<Id>();

    // 遍历 Trigger.new 上下文变量中的所有新记录
    for (Account a : Trigger.new) {
        newAccountIds.add(a.Id);
    }

    // 检查列表是否为空，避免不必要的调用。
    if (!newAccountIds.isEmpty()) {
        // 一次性调用 future method，将所有需要处理的 ID 作为一个列表传递进去。
        // 这样，无论 trigger 处理了 1 条还是 200 条记录，都只消耗一次 future 调用。
        AccountProcessor.processAccounts(newAccountIds);
    }
}

注意事项

虽然 future methods 功能强大，但使用时必须遵守一系列规则和限制，否则会导致代码无法保存或在运行时出错。

方法签名限制

必须是静态方法 (static method)：future method 不能是实例方法，因为它不与任何特定的类实例相关联。
只能返回 void 类型：异步执行的特性意味着调用代码无法直接接收返回值。当你调用一个 future method 时，代码会立即继续执行下一行，而不会等待 future method 完成。
参数类型限制：参数必须是原始数据类型 (primitive data types)（如 `Integer`, `String`, `Boolean`），或者是这些原始类型的集合 (Collections) 或数组 (arrays)。你不能将 sObject（如 `Account`, `Contact`）作为参数直接传递给 future method。
原因：在调用时，参数会被序列化并存储起来，直到方法被执行。如果传递 sObject，那么在方法实际执行时（可能在几秒或几分钟后），数据库中的记录可能已经被其他用户或流程修改了。此时，方法处理的就是一份“过时”的数据。因此，最佳实践是传递记录的 ID，然后在 future method 内部重新查询，以获取最新的数据。

执行与限制

调用限制：在单个 Apex 事务中，最多只能调用 50 次 future methods。这也是为什么在 trigger 示例中我们将所有 ID 收集起来进行一次性调用的原因。
24小时限制：每个 Salesforce org 在 24 小时内可以执行的 future method 调用总数也有限制，通常是 250,000 或者 org 拥有的用户许可证数量乘以 200，取较大者。
执行顺序不保证：如果你在同一个事务中调用了多个 future method，系统不保证它们会按照你调用的顺序执行。因此，不要让不同的 future method 之间存在执行顺序上的依赖。
禁止链式调用：一个 future method 不能调用另一个 future method。如果需要更复杂的、可链接的异步任务链，你应该考虑使用 Queueable Apex。

测试 Future Methods

测试异步代码是至关重要的。Salesforce 提供了一套特定的测试机制。你需要将调用 future method 的代码包裹在 `Test.startTest()` 和 `Test.stopTest()` 方法块之间。当 `Test.stopTest()` 执行时，系统会同步执行所有在此之前调用的异步请求，这样你就可以在测试的后续部分对异步操作的结果进行断言 (assert)。

@isTest
private class AccountProcessorTest {
    @isTest
    static void testProcessAccountsCallout() {
        // 准备测试数据
        List<Account> accounts = new List<Account>();
        for (Integer i = 0; i < 10; i++) {
            accounts.add(new Account(Name = 'Test Account ' + i));
        }
        insert accounts;

        List<Id> accountIds = new List<Id>();
        for(Account acc : accounts) {
            accountIds.add(acc.Id);
        }

        // 标记测试的开始点
        Test.startTest();

        // 调用 future method
        AccountProcessor.processAccounts(accountIds);

        // 标记测试的结束点
        // 这会强制执行所有在 startTest 和 stopTest 之间调用的异步方法
        Test.stopTest();

        // 在这里，你可以添加断言来验证异步操作的结果
        // 例如，如果 future method 会更新某个字段，你可以查询该字段进行验证。
        // 由于我们的示例只是打印日志，所以没有直接可验证的数据库更改，
        // 但在真实场景中断言是必不可少的。
        System.assertEquals(10, [SELECT count() FROM Account WHERE Name LIKE 'Test Account %']);
    }
}

监控

你可以通过 `设置 (Setup) -> 环境 (Environments) -> 作业 (Jobs) -> Apex 作业 (Apex Jobs)` 来监控 future methods 的执行状态。在这里，你可以看到哪些作业正在排队、正在处理、已完成或失败。

总结与最佳实践

Future methods 是 Salesforce 异步 Apex 工具箱中的一个基础且强大的工具。它以简单的方式解决了许多常见的开发难题，尤其是在处理 callouts、混合 DML 和长时运行任务方面。

为了高效、可靠地使用 future methods，请遵循以下最佳实践：

始终进行批量化 (Bulkify)：你的 future method 应该设计为处理记录列表，而不是单个记录。永远不要在循环中调用 future method。
传递 ID，而非 sObject：坚持传递记录的 ID 列表，并在方法内部重新查询数据，以确保数据的一致性和实时性。
保持幂等性 (Idempotent)：在极少数情况下，异步作业可能会被重试。尽量将你的逻辑设计成幂等的，即多次执行和一次执行产生的结果是相同的。例如，在更新外部系统前，先检查该记录是否已被处理。
了解其局限性：Future method 简单易用，但功能有限。如果你需要获取作业的 ID、监控其进度、链接多个作业，或者传递复杂的非原始数据类型，那么 Queueable Apex 会是更好的选择。它提供了 future method 的所有功能，并在此基础上增加了更多的灵活性和控制力。
谨慎使用：不要仅仅为了绕过 Governor Limits 而滥用 future methods。要从业务流程和用户体验的角度出发，判断一个操作是否真的适合异步执行。

作为 Salesforce 开发人员，深刻理解并熟练运用 future methods，将使你能够构建出更健壮、更高效、更能适应复杂业务需求的应用程序。

Salesforce Einstein AI 编程实践：开发者视角下的智能预测

九月 15, 2025

阅读全文

Salesforce中文网