Triggers — Special Cases & Considerations

同学们，今天我们来讲几个关于Apex触发器的关键注意事项，这些点能帮你写出更健壮、更高效的代码。 首先记住，当记录被合并时，触发器并不是按我们直觉以为的那样触发合并事件，而是会激发删除和更新触发器。也就是说，系统会先删除被合并掉的旧记录，然后更新保留下来的主记录。所以你的删除和更新触发器必须能正确处理合并引发的操作。 接下来是“after undelete”触发器。它比较特殊，只会在顶级对象上触发。比如你直接从回收站恢复账户，触发器会运行；但如果是因为恢复了一个关联了该账户的子记录而级联恢复，它是不会触发的。这点在做审计或依赖恢复逻辑时很容易踩坑。 另外，很多系统级的批量操作，比如数据导入工具或者某些后台大容量处理，默认是不调用触发器的。如果你的业务逻辑高度依赖触发器，就需要在实施前确认使用的工具是否支持触发，或者设计备用的验证机制。 说到错误处理，我们经常用 `addError()` 来阻止不合规的DML操作，并且给出友好的自定义消息。和用验证规则相比，触发器里的 `addError()` 响应更快，而且逻辑可以更复杂，是首选的拦截手段。 最关键的设计原则是：，永远为批量处理设计触发器，。绝对不要假设触发器一次只处理一条记录。比如你写 `trigger.old[0]`，当批量更新200条记录时就会出错。应该遍历 `Trigger.old` 或 `Trigger.new` 列表。 在写SOQL查询时，尽量用集合（Set）和 `IN` 子句，把所有需要的ID收集起来，一次性查询，避免循环里出现SOQL。同理，DML操作也要收集到列表里，最后统一执行，而不是一条条 update。这样做能大幅减少DML语句的执行次数，显著提高性能。 把这些要点融入你的编码习惯，会让你的触发器又快又稳，适应各种真实场景。好，关于触发器的这些核心规则，大家理解了吗？我们下节继续深入。