Salesforce Future 方法开发者指南（@future 注解详解）

九月 23, 2025

背景与应用场景

作为一名 Salesforce 开发人员 (Salesforce Developer)，我们日常工作中不可避免地会与 Salesforce 平台的 governor limits (执行限制) 打交道。这些限制是为了保证多租户环境的稳定性和公平性而设定的，但也给我们带来了挑战。在一个同步的 Apex (Apex) 事务中，我们面临着 CPU 时间、DML (Data Manipulation Language, 数据操作语言) 语句数量、SOQL 查询次数等多重限制。

更重要的是，在某些场景下，同步执行模式完全无法满足业务需求。例如，当一个 Apex trigger (触发器) 或 Visualforce controller (控制器) 执行了数据库更新操作后，我们不能在同一个事务中立即对外部系统进行 callout (外部调用)。这样做会立即导致一个 CalloutException 错误。此外，一些资源密集型的操作，如复杂的计算、大规模数据处理或文件生成，如果放在同步事务中，极有可能因为超时而失败，严重影响用户体验。

为了解决这些问题，Salesforce 提供了多种异步处理机制，而 Future Methods 正是其中最简单、最常用的一种。它允许我们将某些方法的执行推迟到后台，在一个独立的、拥有更高执行限制的事务中运行。

核心应用场景：

从触发器中执行外部调用： 这是 future methods 最经典的应用场景。当 DML 操作（如创建或更新记录）发生后，触发器无法直接调用外部 Web 服务。通过将 callout 逻辑封装在一个 future method 中，我们可以完美地绕过这个限制。
隔离混合 DML 操作： 在一个事务中，不能同时对 Setup 对象（如 User、Profile）和非 Setup 对象（如 Account、Contact）进行 DML 操作。我们可以将其中一种操作放入 future method 中，从而将它们分离到两个不同的事务中执行。
处理耗时或资源密集型任务： 对于可能超过同步 CPU 时间限制（10秒）的操作，可以将其放入 future method。异步事务的 CPU 时间限制更高（60秒），为复杂计算提供了更宽松的环境。

原理说明

Future methods 的实现原理非常直观。我们通过在 Apex 方法上添加 @future annotation (注解) 来告诉 Salesforce 平台：“请不要立即执行这个方法，而是将它放入一个队列中，在系统资源可用时异步执行。”

当平台遇到一个带有 @future 注解的方法调用时，它会将这个请求序列化并添加到 Apex 的异步执行队列中。然后，主事务会继续执行，不会等待这个异步方法的完成。系统会根据服务器的负载情况，在稍后的某个时间点从队列中取出该请求，在一个全新的事务中执行它。这个新事务拥有自己独立的 governor limits，通常比同步事务更为宽松。

方法签名要求：

一个方法要成为 future method，必须遵循以下严格的规则：

必须是静态方法 (static method)： 异步执行不依赖于任何特定类的实例状态，因此方法必须是静态的。
必须返回 void 类型： 异步执行是“即发即忘”的模式，调用方无法直接接收返回值。方法的执行结果需要通过更新数据库记录或其他方式间接传递。
参数必须是原始数据类型： 方法的参数只能是 primitive data types (原始数据类型)，如 Integer, String, Boolean，或者是这些原始数据类型的数组或集合 (List, String[])。

特别注意： Future methods 不能接受 sObject (sObject 对象) 或其他非原始数据类型作为参数。这是一个非常重要的限制。原因是，从调用 future method 到它实际执行之间可能存在延迟。在这段时间内，作为参数传递的 sObject 记录可能已经被其他用户或流程修改。如果直接传递 sObject，方法内部处理的将是过时的数据。因此，最佳实践是传递记录的 Id，然后在 future method 内部重新查询最新的记录数据，确保数据一致性。

外部调用注解：

如果你的 future method 需要执行外部 callout，必须在注解中明确指出，格式为 @future(callout=true)。这会告知 Salesforce 将该任务分配给能够执行外部调用的服务器资源池。

示例代码

以下示例来自 Salesforce 官方文档，演示了一个典型的场景：当 Account 记录被更新后，通过 future method 异步调用一个外部服务来同步这些信息。这个例子完美地展示了如何在触发器上下文中使用 future method 进行 callout。

1. Future Method 定义

我们首先创建一个包含 future method 的类。这个方法接收一个 Account ID 列表，并模拟向外部服务发送这些 Account 的名称。

public class FutureMethodExample {
    @future(callout=true)
    public static void sendAccountInfo(List<Id> accountIds) {
        // 首先，根据传入的 ID 列表查询最新的 Account 信息
        // 这是最佳实践，确保我们处理的是最新的数据
        List<Account> accounts = [SELECT Id, Name FROM Account WHERE Id IN :accountIds];

        // 将 Account 名称构造成一个 JSON 字符串
        // 在实际项目中，这里会构建更复杂的请求体
        String jsonBody = JSON.serialize(accounts);

        // 创建一个 HTTP 请求
        HttpRequest request = new HttpRequest();
        // 设置请求端点（Endpoint），这里使用一个示例地址
        request.setEndpoint('https://api.example.com/accounts');
        request.setMethod('POST');
        request.setHeader('Content-Type', 'application/json;charset=UTF-8');
        // 设置请求体
        request.setBody(jsonBody);

        Http http = new Http();
        try {
            // 发送请求并获取响应
            HttpResponse response = http.send(request);

            // 检查响应状态码
            if (response.getStatusCode() == 200) {
                // 请求成功，可以在这里记录日志或更新相关记录状态
                System.debug('Callout successful!');
            } else {
                // 请求失败，记录错误信息
                System.debug('Callout failed with status code: ' + response.getStatusCode());
            }
        } catch(System.CalloutException e) {
            // 捕获并处理 callout 异常
            System.debug('Callout error: '+ e.getMessage());
        }
    }
}

2. 从触发器调用 Future Method

接下来，我们创建一个 Account 触发器。当 Account 更新时，它会收集被更新记录的 ID，并调用上面定义的 future method。

trigger AccountTrigger on Account (after update) {
    // 创建一个 List 来收集需要异步处理的 Account ID
    List<Id> idsForFutureCall = new List<Id>();

    // 遍历触发器上下文中的所有记录
    for (Account acc : Trigger.new) {
        // 假设我们只关心特定条件下更新的记录
        // 例如，当 Account 的年收入发生变化时
        Account oldAcc = Trigger.oldMap.get(acc.Id);
        if (acc.AnnualRevenue != oldAcc.AnnualRevenue) {
            idsForFutureCall.add(acc.Id);
        }
    }

    // 确保列表不为空，避免无效调用
    if (!idsForFutureCall.isEmpty()) {
        // 调用 future method，将收集到的 ID 列表作为参数传入
        // 这是异步调用的起点，主事务会在这里之后继续执行而无需等待
        FutureMethodExample.sendAccountInfo(idsForFutureCall);
    }
}

这个例子清晰地展示了如何将耗时且受限制的 callout 操作从同步的触发器事务中剥离出来，交由 future method 在后台安全地执行。这也是 Bulkification (批量化) 的一个典范：我们没有在循环中为每条记录都调用一次 future method，而是收集所有 ID，进行一次批量调用，这极大地节约了资源并避免了触及限制。

注意事项

虽然 future methods 功能强大且易于使用，但在开发过程中必须牢记其限制和特性，以避免潜在的问题。

Governor Limits：
- 每个 Apex 事务最多只能调用 50 次 future methods。
- 在 24 小时内，一个组织可以调用的 future methods 总数是有限制的（通常是 250,000 或 Salesforce 用户许可证数量乘以 200，取较大者）。
- Future method 自身也受 governor limits 约束，尽管比同步的要宽松（例如 CPU 时间为 60 秒）。
执行顺序不保证：
Future methods 是并行执行的。如果你在短时间内调用了多个 future method，系统不保证它们会按照你调用的顺序执行。如果你的业务逻辑对执行顺序有严格要求，那么 future method 不是一个好的选择。此时应该考虑使用 Queueable Apex (可排队 Apex)，因为它支持任务链。
无法链式调用：
一个 future method 不能再调用另一个 future method。这样做会导致运行时错误。同样，如果需要链式处理，请使用 Queueable Apex。

测试 Future Methods：

测试 future methods 需要使用 Test.startTest() 和 Test.stopTest()。将 future method 的调用放在这两个方法之间。当 Test.stopTest() 执行时，Salesforce 会强制所有已排队的异步作业立即同步执行，这样你就可以在测试的后续部分对异步操作的结果进行断言 (assert)。

@isTest
private class FutureMethodExampleTest {
    @isTest
    static void testSendAccountInfoCallout() {
        // 准备测试数据
        List<Account> accounts = new List<Account>();
        for(Integer i=0; i<10; i++) {
            accounts.add(new Account(Name='Test Account ' + i));
        }
        insert accounts;
        
        // 设置模拟 Callout
        Test.setMock(HttpCalloutMock.class, new MockHttpResponseGenerator());
        
        List<Id> accountIds = new List<Id>();
        for(Account acc : accounts) {
            accountIds.add(acc.Id);
        }
        
        // 开始测试上下文
        Test.startTest();
        
        // 调用 future method
        FutureMethodExample.sendAccountInfo(accountIds);
        
        // 结束测试上下文，这会强制执行上面的 future method
        Test.stopTest();
        
        // 在这里可以添加断言来验证异步操作的结果
        // 例如，查询记录的状态是否已更新
    }
    
    // 模拟 HTTP 响应的辅助类
    public class MockHttpResponseGenerator implements HttpCalloutMock {
        public HTTPResponse respond(HTTPRequest req) {
            HttpResponse res = new HttpResponse();
            res.setHeader('Content-Type', 'application/json');
            res.setBody('{"status":"success"}');
            res.setStatusCode(200);
            return res;
        }
    }
}

监控：
你可以在 Salesforce 的“设置”菜单中，通过“作业” -> “Apex 作业”页面来监控 future methods 的执行状态（排队中、正在处理、已完成、失败等）。

总结与最佳实践

Future methods 是 Salesforce 异步 Apex 工具箱中的一把轻量级瑞士军刀。它为解决 callout 限制、混合 DML 问题和避免同步超时提供了一个简单直接的解决方案。

最佳实践回顾：

永远批量化你的调用： 永远不要在循环中调用 future method。应该将需要处理的记录 ID 收集到一个 List 中，然后对整个 List 进行单次调用。
传递 ID 而非 sObject： 为了保证数据的一致性，始终向 future method 传递记录的 ID，并在方法内部重新查询最新的数据。
保持方法的幂等性 (Idempotency)： 在分布式系统中，异步作业有时可能会被重试。确保你的逻辑是幂等的，即执行一次和执行多次的效果是相同的，以防止数据重复或错误。
选择正确的异步工具：
- Future Methods： 最适合简单的、独立的、无需链式调用或复杂参数的后台任务，特别是从触发器发起的 callout。
- Queueable Apex： 当你需要比 future 更强大的功能时，比如传递复杂的对象、链式调用作业、或获取作业 ID 以进行监控时，它是更好的选择。
- Batch Apex (批处理 Apex)： 当你需要处理成千上万甚至数百万条记录时，Batch Apex 是唯一的选择。它能将数据分块处理，有效管理 governor limits。

作为一名 Salesforce 开发人员，深刻理解并熟练运用 @future 注解，是编写高效、健壮、可扩展的 Apex 代码的关键一步。它虽然简单，但却是解决许多日常开发难题的有力武器。

Salesforce中文网