企业为什么总想修改源代码？
在 ERP、EIP 等管理软件上线后，几乎没有两家企业的业务流程完全一致。某道工序要多个字段、某张单据的审批要加一级、某个报表口径要按集团要求调整——这些差异往往非常具体。传统做法是在源代码上直接修改，短期看似解决了问题，却埋下隐患：每当厂商发布新版本，企业要么放弃升级，要么花费大量人力把改动重新"移植"一遍，升级成本逐年攀升。
直接改源码，等于把企业的个性化"焊死"在标准程序里，版本越往后升级越难。
什么是重载机制？
FERP50 平台提供的重载机制，让实施方或客户在不修改标准程序文件的前提下，对字段、表单、界面与业务逻辑进行扩展与覆盖。它不改变"标准"本身，而是在标准之上叠加一层可管理的差异。
其原理可以用"重载自引用、指向父级"来理解：您的定制并不是把标准程序复制一份再改，而是建立一层引用父级标准、只描述差异的扩展。当标准程序随版本升级时，您这一层差异自动承接更新后的父级规则；只有您明确覆盖的部分才保持定制，其余部分天然跟随标准演进。这样既保留标准软件的持续迭代能力，又守住了企业的个性化。
- 字段重载：在标准表结构之外挂接扩展字段，不破坏原表结构。
- 表单 / 界面重载：调整录入与展示布局，不影响后台逻辑。
- 逻辑重载：对特定业务节点覆盖或增强处理规则。
重载机制与直接定制开发，差别在哪？
| 对比维度 | 直接改源码（定制开发） | FERP50 重载机制 |
|---|---|---|
| 可维护性 | 改动分散在源码中，难以盘点 | 差异集中管理，版本清晰 |
| 升级兼容 | 每次升级需人工合并，易冲突 | 差异层自动继承父级升级 |
| 长期成本 | 随版本累积，越改越贵 | 一次扩展，长期可升级 |
| 风险 | 合并出错可能导致功能异常 | 标准程序不受影响，风险可控 |
企业实际能收获什么？
对管理者而言，重载机制意味着软件既能贴合本企业的业务，又不会因为个性化而"锁死"在某一版本。对 IT 与实施团队而言，差异集中、可审计、可回归，升级从"高风险工程"变成"常规操作"。这正是平台化软件区别于纯定制开发的核心价值。
构建于 FERP50 的 EIP、ERP、PSI 及各专业应用，都共享同一套重载能力，因此个性化扩展可以在产品间平滑复用。
关于重载机制，最常见的几个问题
重载后还能正常升级吗？
可以。由于定制层只描述与标准的差异并指向父级标准，标准程序升级时，未被覆盖的部分自动沿用新版本；只需针对少数行为发生变化的节点做回归确认，无需整体重写。
重载是不是"外挂插件"，性能会变差吗？
不是。重载在平台元数据层面生效，扩展与标准程序在同一运行体系内执行，不会引入额外的远程调用或独立进程，性能影响可忽略。
所有需求都能用重载解决吗？
绝大多数流程、字段、表单与报表类差异都可以通过重载实现。极少数的底层架构级改造仍建议与厂商评估，但这类需求在企业实践中占比很低。