Salesforce中Standard Controller与Extension Controller的save()执行顺序问询

嘿，这个问题我之前在项目里踩过坑，刚好能给你掰扯清楚这里的执行逻辑——核心其实是扩展控制器的save()方法拥有绝对控制权，系统不会自动触发标准控制器的save()，一切都由你在扩展代码里的逻辑决定，具体分这几种场景：

• 仅执行扩展控制器的save()：当你的扩展类中定义了save()方法，且这个方法里**没有显式调用标准控制器的save()**时，系统会完全跳过标准控制器的保存逻辑，只执行你扩展里的代码。比如你在扩展里做了自定义校验、手动DML操作，甚至只是返回一个页面引用，标准控制器的save()都不会被触发。
• 先执行扩展前置逻辑 → 再执行标准控制器的save() → 最后执行扩展后置逻辑：如果你的扩展save()里主动调用了standardController.save()（比如代码里写了PageReference result = standardController.save();），那执行顺序严格按照代码编写顺序来：
  1. 先运行扩展save()中调用标准save()之前的代码（比如给字段赋值、自定义权限校验）
  2. 触发标准控制器的save()，执行标准的持久化操作、触发对象的触发器等
  3. 最后运行扩展save()中调用标准save()之后的代码（比如记录操作日志、跳转自定义页面）
• 仅执行标准控制器的save()：这种情况只有当你的扩展控制器没有定义save()方法时才会发生——此时系统会默认使用标准控制器的保存逻辑，和没有扩展的情况一致。
• 关于你提到的“覆盖”场景：这不是系统默认的执行规则，而是由你的代码逻辑导致的。比如：
  • 如果扩展save()里自己做了DML修改数据，却没有调用标准save()，那标准的持久化就不会执行，相当于用扩展逻辑替代了标准的；
  • 如果在扩展save()里调用了标准save()之后，又做了DML修改数据，那后续的修改会覆盖标准save()保存的数据。

内容的提问来源于stack exchange，提问作者lamthuy hang