Apex Callouts in Read-Only Mode

同学们，今天咱们来聊聊 Salesforce 里一个非常容易踩坑的细节： ，在只读模式下调用外部服务，。 你看啊，当 Salesforce 组织进入只读模式的时候，系统其实并不会阻止 Apex 向外部服务发请求。这个 callout 会正常执行，你也能正常收到响应，比如接收到一个第三方系统的状态更新。 问题就出在得到响应之后——咱们通常会在同一个事务里，紧接着执行一些写操作，像更新记录、创建日志等等。但因为这时候 Salesforce 正处于，只读模式，，所有的 DML 写操作都会被系统直接拦下来，报错回滚。 这就造成了典型的不一致：，外部调用做完了，响应也拿到了，但后续保存结果的步骤却失败了，——程序流程一下就断了，轻则数据对不上，重则业务流程整个卡住。 那怎么避免这种不正确的程序行为呢？ 很简单，咱们在对外部服务发起调用之前，可以先检查一下当前是否处于只读模式。用到一个系统方法： `System.getApplicationReadWriteMode()` 它会返回一个枚举值，告诉我们当前是读写模式还是只读模式。 如果返回值等于 `ApplicationReadWriteMode.READ_ONLY`，那说明当前环境不允许写操作，咱们就应该，直接跳过这次 callout，，等维护结束之后再说。这样就不会出现“调成功了却存不上”的尴尬局面，整个程序流程就安全了。 你可能会问，好端端的怎么突然就只读模式了？ 其实 Salesforce 在计划内的维护活动期间就会自动切到只读模式，比如，计划的站点切换，、，实例刷新，这类操作。这些维护通常发生在凌晨或者提前通知的窗口，咱们应用里加上这个检查，就能在这些时段自动保护业务逻辑，避免莫名其妙的错误。 所以记住啦： 在 Apex 里做外部 callout 时，花一行代码调用 `System.getApplicationReadWriteMode()`，如果读到的状态是只读，就礼貌地绕过这次调用，不要硬来。这样写出来的程序才足够健壮，不会因为维护窗口而“翻车”。 好，这点就讲完了，大家在实际开发的时候可以对照着试一下，有问题随时讨论。