精通 Salesforce 管控限制：Force.com 平台可扩展应用架构师指南

十月 07, 2025

背景与应用场景

作为一名 Salesforce 架构师，在设计任何解决方案时，我的首要考虑因素之一便是平台的底层架构。Force.com（现已发展成为 Lightning Platform 的核心部分）是一个功能强大的 Platform as a Service (PaaS) 平台，它之所以能够为全球数十万家企业提供稳定、可靠的服务，其核心在于其多租户 (Multi-tenant) 架构。在这种架构中，所有客户（租户）共享相同的计算资源、基础设施和数据库。为了确保没有任何一个租户的低效代码或超量请求会影响到其他租户的性能和可用性，Salesforce 引入了一套严格的资源使用规则，这便是大名鼎鼎的 Governor Limits（管控限制）。

理解、尊重并在架构设计中充分考虑 Governor Limits，是区分优秀 Salesforce 解决方案与平庸方案的关键。一个看似简单的业务需求，如“当客户地址更新时，同步更新其下所有联系人的地址”，如果处理不当，极易在数据量稍大的情况下撞上 Governor Limits，导致业务流程中断、用户体验下降。因此，本文将从架构师的视角，深入探讨 Force.com 平台上的 Governor Limits，解释其背后的原理，并提供遵循最佳实践的代码示例，旨在帮助开发者和管理员构建可扩展、高效且稳健的 Salesforce 应用。

原理说明

Governor Limits 的存在完全是为了服务于多租户架构的公平性和稳定性。想象一下一栋公寓楼，所有住户共享水电总管道。如果某一家住户无限制地用水，必然会导致其他住户水压不足。Salesforce 的服务器资源就像这栋楼的总管道，而 Governor Limits 就是每家每户的水表和流量限制器，确保资源被公平、合理地分配。

这些限制几乎涵盖了在 Force.com 平台上执行的所有操作，尤其是在使用 Apex（Salesforce 的后端编程语言）时。它们不是为了束缚开发者，而是为了引导开发者写出更高效、更“批量化”的代码。从架构层面，我们可以将常见的 Governor Limits 分为以下几类：

1. Per-Transaction Apex Limits（单次事务 Apex 限制）

这是最常见也最需要关注的一类限制。一次“事务”可以理解为由一个入口点触发的完整执行链，例如一次 DML 操作触发的 Apex Trigger，或一次 Visualforce 页面的请求。在此事务完成之前，所有的操作都必须遵守以下限制：

SOQL Queries Issued: 在一次事务中，总共可以执行的 SOQL (Salesforce Object Query Language) 查询次数。同步执行上限为 100 次。
DML Statements Issued: 在一次事务中，总共可以执行的 DML (Data Manipulation Language) 操作（如 insert, update, delete）次数。上限为 150 次。
Total number of records processed: SOQL 查询返回的总记录数上限为 50,000 条；DML 操作处理的总记录数上限为 10,000 条。
Maximum CPU time: 在 Salesforce 服务器上消耗的总 CPU 时间。上限为 10,000 毫秒（10秒）。

这些限制直接推动了“Bulkification（批量化）”这一核心编程范式。其核心思想是：代码必须能够处理单条记录，也必须能够高效地处理多达 200 条记录的集合，因为 Trigger 和许多 API 调用都是批量执行的。

2. Asynchronous Apex Limits（异步 Apex 限制）

对于需要处理大量数据或执行长时间运行的操作，Salesforce 提供了异步处理机制，如 @future Methods, Queueable Apex, 和 Batch Apex。它们在独立的事务中运行，拥有更高、更宽松的 Governor Limits。例如，Batch Apex 每个 `execute` 方法都有自己的一套独立限制，并且每日的异步 Apex 执行总次数也有一个组织级别的限制。

3. Static Apex Limits（静态 Apex 限制）

这类限制与代码本身相关，例如 Apex 代码的总字符数限制（6MB），`with sharing` 或 `without sharing` 关键字的强制声明等。

示例代码（含详细注释）

理论是枯燥的，让我们通过一个具体的例子来感受 Governor Limits 的威力，以及如何通过“批量化”来优雅地应对它。这是一个非常经典的“反模式”与“最佳实践”的对比。

场景：当一组 Account 记录被更新时，需要将这些 Account 的 `ShippingCity` 字段值同步到其下所有的 Contact 记录的 `MailingCity` 字段上。

反模式：在循环中执行 SOQL 查询

这是一个初学者极易犯的错误。这种写法在处理单条 Account 更新时或许没有问题，但一旦有超过 100 个 Account 被批量更新（例如通过 Data Loader），代码将立即因为超出 SOQL 查询 100 次的限制而失败。

// 触发器：当 Account 更新时执行
trigger AccountTrigger on Account (after update) {
    // 遍历所有被更新的 Account 记录
    for (Account acc : Trigger.new) {
        // !!! 严重错误 !!!
        // 在 for 循环中执行 SOQL 查询。
        // 如果 Trigger.new 包含 101 条记录，这里将执行 101 次 SOQL 查询，
        // 从而超出 100 次的 Governor Limit。
        List<Contact> contacts = [SELECT Id, MailingCity FROM Contact WHERE AccountId = :acc.Id];

        // 遍历查询到的联系人并更新
        for (Contact con : contacts) {
            con.MailingCity = acc.ShippingCity;
        }

        // !!! 潜在的另一个错误 !!!
        // 在循环中执行 DML 操作也是一个坏习惯，虽然在这个例子中它被包含在 contacts 列表的更新中，
        // 但如果单独写 update contacts; 也会导致 DML 次数超限。
        update contacts; // 这个 update 也会在循环中被多次调用，很快会超出150次DML限制。
    }
}

⚠️ 未找到官方文档支持：上述代码是一个典型的反面教材，官方文档中会明确指出要避免此类模式，但不会直接提供这段“错误”代码作为正面示例。

最佳实践：批量化（Bulkification）

正确的架构思路是“一次查询，一次更新”。我们首先收集所有需要处理的 Account 的 ID，然后用一次 SOQL 查询获取所有相关的 Contact，最后再用一次 DML 操作更新所有需要变更的 Contact。

以下代码示例改编自 Salesforce 官方文档中关于触发器和批量请求的最佳实践部分。

// 触发器：当 Account 更新时执行
trigger AccountTrigger on Account (after update) {
    // 步骤 1: 创建一个 Set 集合来收集所有触发本次更新的 Account 的 ID。
    // 使用 Set 可以自动去重，效率更高。
    Set<Id> accountIds = Trigger.newMap.keySet();

    // 步骤 2: 执行一次 SOQL 查询，获取所有与这些 Account 相关联的 Contact。
    // 这是“批量化查询”的核心。无论有多少个 Account 被更新，SOQL 查询只执行一次。
    List<Contact> contactsToUpdate = [SELECT Id, AccountId, MailingCity FROM Contact WHERE AccountId IN :accountIds];

    // 步骤 3: 准备一个 Map，用于快速通过 Account ID 查找到对应的 Account 对象。
    // Trigger.newMap 是一个系统提供的 Map，键是记录ID，值是记录本身，非常方便。
    Map<Id, Account> accountMap = Trigger.newMap;

    // 步骤 4: 遍历需要更新的 Contact 列表，而不是 Account 列表。
    // 这样逻辑更清晰，直接处理目标数据。
    for (Contact con : contactsToUpdate) {
        // 从 Map 中获取当前 Contact 关联的 Account 对象
        Account parentAccount = accountMap.get(con.AccountId);
        
        // 更新 Contact 的 MailingCity 字段
        // 只有当值发生变化时才更新，这是一个微优化，可以避免不必要的 DML。
        if (con.MailingCity != parentAccount.ShippingCity) {
            con.MailingCity = parentAccount.ShippingCity;
        }
    }

    // 步骤 5: 执行一次 DML 更新操作。
    // 这是“批量化更新”的核心。所有需要更新的 Contact 在一个列表中被一次性提交。
    // 在执行 DML 前，检查列表是否为空是一个好习惯。
    if (!contactsToUpdate.isEmpty()) {
        update contactsToUpdate;
    }
}

通过这种重构，无论本次事务处理 1 条还是 200 条 Account 记录，SOQL 查询和 DML 操作都各自只执行了一次，完全符合 Governor Limits 的要求，代码健壮且可扩展。

注意事项

权限（Permissions）

Apex 默认在系统模式（System Mode）下运行，通常会忽略当前用户的字段级安全（Field-Level Security）和对象权限。但在设计时必须考虑记录的共享（Sharing）。如果代码中没有使用 `with sharing` 或 `without sharing` 关键字声明，它将默认遵循调用它的上下文的共享规则。作为架构师，必须明确定义类的共享模型，以确保数据访问的安全性符合业务预期。

API 限制（API Limits）

除了 Apex Governor Limits，整个 Salesforce 组织还有 API 调用限制，通常是基于 24 小时滚动的。在设计集成方案时，必须考虑这些限制，采用批量 API (Bulk API) 处理大量数据，或者设计合理的缓存策略和调用频率，避免耗尽组织的 API 调用限额。

错误处理（Error Handling）

当代码确实达到了 Governor Limit 时，系统会抛出一个无法捕获的 `LimitException`，导致整个事务回滚。因此，预防远胜于治疗。在代码中，可以使用 Apex 的 `Limits` 类来主动监控资源消耗。例如，在复杂的循环处理前，可以检查剩余的 SOQL 查询次数或 CPU 时间。

// 在执行可能耗时的操作前，检查剩余的 SOQL 查询次数
Integer remainingQueries = Limits.getLimitQueries() - Limits.getQueries();
System.debug('Remaining SOQL Queries: ' + remainingQueries);

// 检查剩余的 CPU 时间
Integer remainingCpuTime = Limits.getLimitCpuTime() - Limits.getCpuTime();
System.debug('Remaining CPU Time (ms): ' + remainingCpuTime);

if (remainingQueries < 10 || remainingCpuTime < 1000) {
    // 如果资源即将耗尽，可以考虑抛出自定义异常，
    // 或者将任务放入异步队列中处理，以避免事务失败。
    // throw new MyCustomException('Approaching governor limits. Deferring process.');
}

对于可能部分成功部分失败的 DML 操作，应使用 `Database.update(records, false)` 方法，它的第二个参数 `allOrNone` 设置为 `false`，允许部分记录成功，并返回详细的错误结果供后续处理，这对于构建容错性强的系统至关重要。

总结与最佳实践

作为一名 Salesforce 架构师，我认为 Governor Limits 是 Force.com 平台最伟大的设计之一。它强制我们从一开始就思考扩展性、效率和资源共享。一个成功的 Salesforce 解决方案，必然是一个与 Governor Limits 和谐共存的方案。

以下是构建可扩展 Force.com 应用的核心最佳实践：

拥抱批量化（Bulkification）: 始终假设你的代码会处理多条记录。这是在 Salesforce 上编写代码的第一法则。
绝不在循环中执行 SOQL 或 DML: 这是导致性能问题和违反 Governor Limits 的头号元凶。
善用集合（Collections）: 高效地使用 `List`, `Set`, 和 `Map` 来收集数据、去重和快速查找，是实现批量化的基础。
选择正确的工具: 面对复杂的业务逻辑，不要试图用一个庞大的 Trigger 或 Apex Class 解决所有问题。合理利用 Flow 处理声明式逻辑，使用 Queueable Apex 或 Batch Apex 处理大批量数据和长时任务。
理解执行顺序（Order of Execution）: 深入理解 Salesforce 的保存操作执行顺序，可以帮助你预测 Trigger、Workflow Rule、Process Builder 和 Flow 的交互行为，避免产生意外的递归和性能瓶颈。
编写有意义的测试: 你的 Apex 测试类不仅要覆盖代码行，更重要的是要测试批量场景。创建一个包含 200 条记录的测试方法，是确保代码符合批量化要求的最佳方式。

总之，将 Governor Limits 视为架构设计的“护栏”而非“障碍”，你就能在 Force.com 这个强大的平台上构建出真正企业级的、经得起时间考验的应用程序。

Salesforce中文网