Salesforce 开发人员指南：Apex 触发器最佳实践与实现
背景与应用场景
作为一名 Salesforce 开发人员，Apex Triggers (Apex 触发器) 是我们工具箱中最强大、最基础的工具之一。当标准的声明式工具，如 Flow Builder 或曾经的 Process Builder，无法满足复杂的业务逻辑需求时，Apex Triggers 便成为了我们的首选。它允许我们在数据操作语言 (Data Manipulation Language, DML) 事件（如 `insert`、`update`、`delete`）发生之前或之后，执行自定义的 Apex 代码，从而实现对 Salesforce 数据处理流程的精细化控制。
那么，我们通常在哪些场景下使用 Apex Triggers 呢？
- 复杂数据验证 (Complex Data Validation): 当验证规则需要跨越多个对象，或者涉及复杂的计算逻辑时，标准验证规则 (Validation Rules) 可能力不从心。例如，在创建合同 (Contract) 时，需要验证关联客户 (Account) 的年度收入 (Annual Revenue) 是否达到某个阈值，并且该客户下所有相关联系人 (Contacts) 的职位不能为“实习生”。这种跨对象的复杂查询和验证逻辑，正是 Apex Trigger 的用武之地。
- 相关记录的自动化操作 (Automation on Related Records): 当一个对象上的记录发生变化，需要自动更新或创建其他关联对象的记录时。一个经典的例子是，当一个业务机会 (Opportunity) 的阶段 (Stage) 更新为 “Closed Won” 时，自动更新关联客户 (Account) 的 “客户类型” 字段为 “VIP 客户”，并为客户团队成员创建一条庆祝任务 (Task)。
- 与外部系统集成 (Integration with External Systems): 虽然我们强烈推荐使用异步处理（如 Queueable Apex 或 Future 方法）来调用外部系统以避免事务延迟，但在某些特定场景下，触发器可以作为启动这些异步调用的起点。例如，当一个新订单 (Order) 创建后，触发器可以启动一个异步任务，将订单信息同步到公司的 ERP 系统中。
- 执行无法通过声明式工具实现的逻辑: 某些操作，如设置共享规则 (Sharing Rules) 或执行复杂的聚合计算，无法通过 Flow 实现，这时就需要借助 Apex Trigger 来完成。
尽管 Salesforce 平台大力倡导 “Flow Before Code” 的理念，鼓励优先使用声明式工具，但 Apex Triggers 在性能、复杂度和灵活性要求高的场景中，其地位依然不可替代。理解其工作原理和最佳实践，是每一位 Salesforce 开发人员的必备技能。
原理说明
要精通 Apex Triggers，首先必须理解其核心工作原理，这包括触发器事件 (Trigger Events)、上下文变量 (Context Variables) 以及它们在 Salesforce 保存执行顺序 (Order of Execution) 中的位置。
触发器事件 (Trigger Events)
Apex Triggers 可以响应两种主要类型的事件：
before事件: 在记录被保存到数据库之前执行。这类触发器非常适合用于数据验证或在记录提交前修改其自身的字段值。例如，在 `before insert` 事件中，可以将一个客户名称字段统一转换为大写，而无需额外的 DML 操作，因为更改会直接作用于即将被保存的记录上。after事件: 在记录被保存到数据库之后执行。这类触发器用于访问由系统生成的字段值（如记录的 Id 或 LastModifiedDate），或者对相关记录执行操作。需要注意的是，在 `after` 触发器中对触发当前事件的记录进行修改，需要执行一次额外的 DML `update` 操作，这可能导致递归调用，需要谨慎处理。
这些事件与 DML 操作组合，构成了七种具体的触发器事件：`before insert`, `before update`, `before delete`, `after insert`, `after update`, `after delete`, `after undelete`。
上下文变量 (Context Variables)
在触发器执行期间，Salesforce 提供了一系列静态的上下文变量，这些变量位于系统 `Trigger` 类中，帮助我们了解触发器运行时的上下文信息，并访问被处理的记录。
Trigger.new: 一个 sObject 记录的列表，包含了即将被创建或更新的新版本记录。在 `before insert` 触发器中，你可以直接修改此列表中的字段值。它在 `insert`, `update`, `undelete` 事件中可用。Trigger.old: 一个 sObject 记录的列表，包含了被更新或删除记录的旧版本。此列表是只读的。它在 `update`, `delete` 事件中可用。Trigger.newMap: 一个从记录 ID 到新版本 sObject 记录的映射 (Map)。它在 `after insert`, `before update`, `after update`, `after undelete` 事件中可用，因为只有在这些阶段记录才拥有 ID。Trigger.oldMap: 一个从记录 ID 到旧版本 sObject 记录的映射。它在 `update`, `delete` 事件中可用。- 布尔型变量: 如 `Trigger.isInsert`, `Trigger.isUpdate`, `Trigger.isExecuting`, `Trigger.isBefore`, `Trigger.isAfter` 等，用于判断当前的执行上下文，使我们可以在同一个触发器文件中为不同事件编写逻辑。
Trigger.size: 当前批次中处理的记录总数。
熟练运用这些上下文变量，特别是 `Trigger.newMap` 和 `Trigger.oldMap`，是编写高效、批量化代码的关键。
示例代码
遵循 “逻辑分离” 的最佳实践，我们应该保持触发器文件本身（.trigger）的简洁，仅用于根据上下文调用处理器类 (Handler Class) 中的相应方法。这种模式被称为 Trigger Handler Pattern (触发器处理器模式)。
场景：阻止用户删除任何有关联业务机会 (Opportunity) 的客户 (Account)。
第一步：创建触发器 (AccountTrigger.trigger)
这个触发器文件非常简洁，它的唯一职责就是判断当前的执行上下文（`before delete`），然后将执行委托给 `AccountTriggerHandler` 处理器类。
trigger AccountTrigger on Account (before insert, before update, before delete, after insert, after update, after delete, after undelete) {
// For this example, we only care about the 'before delete' event.
// In a real-world scenario, you would have a more robust dispatching mechanism.
if (Trigger.isBefore && Trigger.isDelete) {
// Delegate the logic to the handler class, passing the records being deleted.
AccountTriggerHandler.handleBeforeDelete(Trigger.old);
}
}
第二步：创建处理器类 (AccountTriggerHandler.cls)
所有的业务逻辑都存放在这个类中。这样做的好处是代码更易于维护、测试和复用。
public class AccountTriggerHandler {
/**
* @description Handles the logic before an Account record is deleted.
* @param oldAccounts The list of accounts that are about to be deleted (from Trigger.old).
*/
public static void handleBeforeDelete(List<Account> oldAccounts) {
// Use a Set to collect the IDs of the accounts being deleted for an efficient query.
Set<Id> accountIds = Trigger.oldMap.keySet();
// Find all opportunities that are related to the accounts being deleted.
// This query is bulk-safe as it queries all related opportunities in a single SOQL call.
List<Opportunity> relatedOpps = [SELECT Id, AccountId FROM Opportunity WHERE AccountId IN :accountIds];
// If no related opportunities are found, there's nothing to do.
if (relatedOpps.isEmpty()) {
return;
}
// Create a map to easily check which account has related opportunities.
Map<Id, Account> accountMap = new Map<Id, Account>(oldAccounts);
// Iterate through the found opportunities to identify which accounts cannot be deleted.
for (Opportunity opp : relatedOpps) {
// Check if the account is still in our map of accounts to be processed.
if (accountMap.containsKey(opp.AccountId)) {
// Get the account record from the map.
Account accountToError = accountMap.get(opp.AccountId);
// Add an error message to the specific account record.
// This prevents the deletion of this specific record and displays the message in the UI.
accountToError.addError('Cannot delete this account because it has related opportunities. Please delete the opportunities first.');
}
}
}
}
这个例子完美地展示了如何使用 `before delete` 事件、`Trigger.old` (通过 `Trigger.oldMap.keySet()` 间接使用) 以及 `addError()` 方法来阻止 DML 操作并向用户提供清晰的反馈。同时，它也遵循了批量化原则，只用了一次 SOQL 查询就处理了所有记录。
注意事项
编写 Apex Triggers 时，必须时刻警惕 Salesforce 平台的限制和潜在的陷阱。
Bulkification (批量化)
这是最重要的原则。你的代码必须能够处理单条记录，也必须能高效处理多达 200 条记录的批次。数据加载工具 (Data Loader)、API 调用和某些 Salesforce 自动化都可能导致触发器以批处理方式执行。绝对禁止在 `for` 循环中放置 SOQL 查询或 DML 语句，这会导致轻易超出 Governor Limits (执行限制)。
Governor Limits (执行限制)
Salesforce 是一个多租户环境，为了保证资源公平分配，平台对每个事务 (Transaction) 中的操作数量施加了严格限制。常见的限制包括：
- 每个事务中 SOQL 查询总数：100
- 每个事务中 DML 语句总数：150
- 每个事务中 DML 操作影响的总记录数：10,000
- CPU 执行时间上限：10,000 毫秒
不遵循批量化原则是超出这些限制的最常见原因。
Recursion (递归)
当一个触发器中的 DML 操作导致该触发器被再次触发时，就可能发生递归。例如，一个 `after update` 触发器更新了它正在处理的记录，这将再次触发 `update` 事件。如果不加控制，这会形成一个无限循环，最终耗尽资源并导致事务失败。一个常见的防止递归的模式是使用一个静态布尔变量。
public class MyTriggerHandler {
private static boolean hasRun = false;
public static void myMethod(List<SObject> newRecords) {
if (!hasRun) {
hasRun = true;
// ... your logic and DML operations here ...
}
}
}
Error Handling (错误处理)
使用 `try-catch` 块来捕获 DML 异常，并提供有意义的错误处理。对于数据验证，`addError()` 方法是标准做法，它可以将错误信息关联到特定记录或字段，并阻止保存操作。
总结与最佳实践
作为 Salesforce 开发人员，编写高质量的 Apex Triggers 是我们专业能力的体现。遵循以下最佳实践，可以确保你的代码健壮、高效且易于维护。
- One Trigger Per Object (每个对象一个触发器): 为每个 sObject 对象只创建一个触发器。Salesforce 不保证同一对象上多个触发器的执行顺序。将所有逻辑统一到一个触发器中，再通过 Handler 类和上下文变量进行分发，可以确保执行流程的可预测性。
- Logic-less Triggers (无逻辑触发器): 保持你的 `.trigger` 文件“无逻辑”。它应该只负责将执行委托给 Handler 类。这使得代码的业务逻辑部分可以被其他地方（如 Visualforce 控制器或 Aura/LWC 服务端控制器）复用，并且极大地简化了单元测试。
- Context-Specific Logic (上下文特定逻辑): 在 Handler 类中，使用 `if/else if` 结构和布尔上下文变量（`Trigger.isInsert`, `Trigger.isAfter`等）来清晰地组织和隔离不同事件的逻辑。
- Bulkify Your Code (代码批量化): 始终将你的代码设计为可以处理批量记录。利用 Set、List 和 Map 集合来高效地处理数据，避免在循环中执行 SOQL 或 DML。
- Avoid Hardcoding IDs (避免硬编码ID): 绝不要在代码中硬编码记录 ID、用户名或任何其他环境特定的值。使用 Custom Settings (自定义设置)、Custom Metadata Types (自定义元数据类型) 或动态 SOQL 查询来获取这些值。
- Comprehensive Test Coverage (全面的测试覆盖): 必须为你的触发器逻辑编写单元测试。测试不仅是为了满足 75% 的代码覆盖率要求，更重要的是要验证所有业务逻辑，包括正面场景、负面场景以及批量处理场景。使用 `Test.startTest()` 和 `Test.stopTest()` 来重置并测试 Governor Limits。
总之，Apex Triggers 是一个强大的自动化工具。通过深刻理解其原理，并严格遵循社区公认的最佳实践，我们可以构建出能够支持最复杂业务流程的、稳定可靠的 Salesforce 应用。
评论
发表评论