Managed Package Types & Apex Versioning

咱们今天来聊聊 Salesforce 里托管包的三种类型，以及怎么在 Apex 里根据包的版本做不同的事情。你可能听说过 1GP、2GP 还有 Unlocked 包，但别担心，我用最简单的话给你讲清楚。 首先，1GP，全称是第一代托管包，其实就是咱们在 AppExchange 上最常见的那种传统包。它跟组织绑定得比较紧，开发流程大多是直接在打包组织里点点改改。这个方式已经很多年了，稳定但不够灵活。 接着是 2GP，第二代托管包。它是从源代码驱动的，就是说你的代码放在版本控制系统里，比如 Git，然后 Salesforce 根据你源码的版本来创建包版本。它的一个很大改进是命名空间的可见性控制更精细，而且允许你构建模块化的包，把功能拆分开来，更适合现代开发流程。你可能会同时维护同一个包的不同主要版本，让订阅者可以选择升级到什么版本。 最后是 Unlocked 包，这个其实主要不是给 AppExchange 上架用的，而是用于企业内部，尤其是想在多个 org 间共享组件，但又不想走很重的 AppExchange 审核流程。Unlocked 包也是从源代码创建的，但它没有命名空间，或者可以使用一个没有发布到 AppExchange 的命名空间，很适合内部开发和分发。 现在关键来了：无论你是作为包的开发者，还是作为使用包的订阅者写 Apex 代码，都需要有能力知道“我当前运行的代码是属于哪个版本的包”。因为你的逻辑可能需要根据包版本来走不同的分支。这时候，System.requestVersion() 方法就派上用场了。 System.requestVersion() 返回一个 Version 对象，它描述的是当前正在执行的代码所属的包版本。注意，它不是订阅者安装的包的版本，而是具体正在调用的那部分代码所在的包版本。比如，你的扩展包或者订阅者代码调用了托管包里某个类的方法，那个方法里调用的 System.requestVersion() 返回的就是托管包自己的版本。 然后你可以用 Version 对象的 compareTo 方法来做比较。假设你作为包开发者，想对 2.0 版本以上的包启用一套新逻辑，而对旧版本保持兼容，你就可以这样写： ```apex if (System.requestVersion().compareTo(new Version(2, 0)) >= 0) { // 执行新版本的逻辑 } else { // 执行旧版本的逻辑 } ``` compareTo 方法会返回一个整数：如果当前版本比传入的版本大，返回正数；相等返回 0；小的话返回负数。所以 >=0 就代表当前版本大于等于 2.0。 还有个重要概念：请求上下文。System.requestVersion() 返回的版本在整个请求的调用链里是保持一致的，哪怕你的方法内部调用了同一个包里的其他方法，这个版本号也不会变。但它只持续到当前请求结束，下一个请求就会重新根据实际调用的包确定。 简单总结一下：1GP 是传统打包，2GP 是现代源码驱动且更适合模块化，Unlocked 包用于内部共享。你需要用 System.requestVersion() 拿到当前执行代码的包版本，然后通过 compareTo 来编写版本兼容条件。好啦，今天的知识点就这么些，下回咱们来动手写写代码试试看。