一张销售订单页面里，业务部门增加了一个很具体的要求，订单项目除了物料、数量、净值，还要记录客户包装等级。这个字段既不是临时备注，也不能只停留在浏览器页面里。它需要写入数据库，参与查询，通过 OData 服务传到前端，在 SAP Fiori 页面上显示，还可能进入报表、打印表单和对外接口。

若按照早期传统开发思路处理，开发人员很容易直接打开 SAP 交付的表、结构、程序或视图，在标准对象里增加字段。短期看起来很快，系统升级时却会立刻陷入麻烦。标准对象发生修改后，补丁安装、版本升级和功能包更新都可能触发调整工作。原来只想增加一个业务字段，没曾想最后背上了一整套修改比较、冲突分析和回归测试。

ABAP 平台提供的 Field Extensibility，正是用来解决这类问题。它允许我们把自定义字段和自定义逻辑附着到已经交付的开发对象上，而不是直接改写原对象。扩展基础设施负责把新增元素带入相关技术层，从 ABAP Dictionary、数据库结构、CDS 数据模型，一直延伸到 SAP Gateway、OData 服务和 Fiori UI。对于支持扩展的 SAP Fiori 应用，字段扩展能力可以围绕某个业务上下文创建客户字段，系统还会生成或调整相应的软件工件。

这里真正重要的并不是页面上多出了一个输入框，而是同一项业务信息在整条应用链路里拥有统一、稳定并且可升级的表达。

Field Extensibility 不是简单的页面加字段

很多项目刚接触字段扩展时，容易把它理解成 Fiori 页面适配。我们在页面编辑模式里增加一个控件，给它绑定一个属性，似乎工作就完成了。可是 UI 字段只有在后端数据模型已经提供对应属性时才有业务价