在传统 SAP 项目里，只要业务部门提出一个标准功能覆盖不了的需求，开发团队脑海里很容易出现几个熟悉的词，User Exit、Customer Exit、BAdI、Enhancement、Implicit Enhancement，甚至直接修改 SAP 标准程序。过去几十年的 ABAP 开发历史里，这套方法确实解决了大量实际问题，但当 SAP 软件开始进入持续升级、云化交付和 Clean Core 的技术环境后，曾经被认为灵活的做法逐渐暴露出另一个问题，扩展代码和 SAP 标准代码之间的边界并不稳定。SAP 升级一个标准类，客户增强可能受影响。SAP 修改一张标准表，客户程序可能跟着调整。SAP 改变一个内部函数模块的参数，原来工作正常的自定义程序可能突然出现语法错误。到了大型 S/4HANA 项目，这类技术债务尤其明显，因为一个运行了十几年甚至二十年的系统里，很可能已经积累几千乃至几万个 Z 对象，而且其中相当一部分直接依赖 SAP 内部实现。ABAP Cloud 对扩展能力的设计正是从这里切入。在 ABAP Cloud 中，Extensibility 并不是附加在编程模型外围的一组增强技术，而是整个开发模型的内建能力。SAP 官方把它描述为 ABAP Cloud 的核心组成部分，并强调云就绪开发需要在 SAP 代码与自定义代码之间建立稳定接口。ABAP Cloud 的数据模型、业务行为、服务以及应用，可以通过明确开放的扩展点进行扩展，而不是依赖修改标准对象。这件事情看起来只是开发规范变化，实际上牵涉到 SAP 软件生命周期管理方式的变化。过去我们经常思考一个问题，这个 SAP 对象能不能调用。ABAP Cloud 更关心另一个问题，这个 SAP 对象是否承诺可