在很多企业交付里，定制化最终都会走向两条老路：
- 拷贝分支交付：每客户一套代码/一套版本，碎片化严重，升级接近不可行。
- 硬改标品交付：看似快，实则把标品污染成“项目代码”，长期维护崩掉。
Oinone 在“标准化与定制化共生”的范式里明确点出这两种困境，并强调通过**“定制模块与标准代码物理隔离 + 继承体系并行演进”**去破解升级魔咒。
而 Upstream 正是把这种“物理隔离 + 继承关系”落到模块层面的关键开关： 它让你能创建一个“客户化模块”，继承“标准产品模块”，把差异收敛在客户化模块中，而不去改动标品源码，从而能在同一环境里对比差异、展示不同客户效果。
点击体验Demo
1）Upstream 到底是什么：模块层面的“继承/集成关系”
在 Oinone 的教程里，客户化模块 ce_expenses 会这样声明：
upstreams = expenses- 同时
dependencies 里也依赖 expenses
其目的被说得很直白：通过 upstreams 指定上游标品应用，保证与标品的数据与功能衔接顺畅。
并且它有一个非常现实的边界条件：Enterprise Edition 才有 upstream，Community Edition 没有。这意味着 upstream 本质上是面向“规模化交付/多客户并行演进”的工程能力。
2）Upstream ≠ Dependency：一个解决“关系”，一个解决“可用性”
很多人第一次接触会把 upstream 当成 dependency 的别名，但它们其实解决的是两件事：
Dependency：我“能不能用”上游能力
在应用中心（Apps Hub）里，依赖的解释是：依赖后就能使用被依赖应用/模块的能力，比如依赖文件模块后可用导入导出能力。 在 Module API 里也强调：如果模块继承了另一个模块的模型，或与其模型建立关联，就需要把对方放进依赖列表。
![]()
Upstream：我“以谁为标准”，并把它“整合进当前应用”
Apps Hub 对 upstream 的描述非常关键：上游模块只能选择已依赖的应用/模块；一旦被选为上游模块，上游模块会被整合到当前应用，用于特定场景的个性化需求。
你可以把它理解成一种产品线语义：
Dependency 是编译/运行层面的“引用关系”； Upstream 是交付/演进层面的“变体关系”（Variant of a standard product）。
3）Upstream 真正的“威力点”：它和“入口治理”是绑定的
很多团队用了 upstream 仍然做不出可持续交付，问题往往不在 upstream 本身，而在入口没有切到客户化模块。
Oinone 的“共生范式”给了一个非常工程化的步骤：
- 新建客户化定制模块，利用 upstream 特性
- 复制标品菜单
- 以客户化定制模块作为访问入口
- 方便对比标品与个性化差异，并用继承/扩展点/钩子开发客户化逻辑
这不是“界面层的小动作”，而是直接影响后端扩展机制是否能精准生效。
为什么？因为扩展点示例里，生效条件就是：
expression = "context.requestFromModule==\"ce_expenses\""
并且明确说明：context.requestFromModule 代表请求发起的模块。
也就是说：
- 如果用户仍然从 标品菜单 进入，请求来源模块就可能是标品模块；
- 你的客户化扩展点条件就不成立；
- 结果就是“我写了定制逻辑，但就是不生效”。
所以我更愿意把 Upstream 的方法论总结为一句话：
Upstream 不是“我能覆盖什么”，而是“我把变化导向哪里”。 入口不切换，变化就无法被稳定导流。
4）客户化模块要怎么写才“可演进”：继承 + Extpoint + Hook 的组合拳
Oinone 在“函数特性”里把个性化扩展手段分成两类：扩展点（Extpoint）与拦截器（Hook）。 这两者能力相近但工程属性不同——用对了是体系化，用错了就是隐式复杂度。
4.1 Extpoint：定点扩展，可控、可治理
关键事实有三条（都决定了你的架构是否稳）：
- Oinone 为所有函数提供默认的 Before/Override/After 扩展点命名规则。
- 扩展点实现可以用
expression 与 priority 设置生效条件与优先级；表达式里可用 context 与函数参数变量。
- 一个扩展点可以有多个实现，但最终只会按条件与优先级选择一个执行。
![]()
这三个事实组合起来意味着： Extpoint 更像“产品预留插槽”，适合承载可解释的差异——例如只在 ce_expenses 入口下弹提示，而标品入口保持沉默。
还有两个“细节级但很致命”的约束：
- 函数参数不要命名为
context，会和内置上下文冲突导致表达式异常。
- 子模型继承父模型字段/函数时，也会继承函数的扩展点。
这实际上是在告诉你：别把扩展点当补丁，把它当“可继承的变更点”来设计。
4.2 Hook：横切拦截，强但必须克制
Hook 的关键事实也有三条：
- 分前置与后置：前置处理入参，后置处理出参。
- 顺序由
priority 控制：数值越小优先级越高，越先执行。
- 拦截器数量过多会导致性能下降（文档直说“不可避免”）。 因此我的工程建议是：
否则 Hook 很容易把系统变成“你看得到代码但看不到控制流”的状态。
4.3 还有一个常被忽略的限制：生效范围
文档明确警告：默认情况下，扩展点和拦截器仅对页面发起的请求生效，Java 代码里直接调用函数不产生作用。
这会直接影响你的测试与批处理设计：
- 只做 Java 单测，可能测不到真实生效路径；
- 批处理/定时任务如果走“直接调用”，也可能绕开扩展体系。
5）设计器侧的“复制-修改-绑定”不是麻烦，而是开闭原则的制度化
Oinone 的共生范式对“新增/修改”的处理非常明确：
- 新增：可以新增页面/流程/数据可视化等
- 修改：必须先复制原有内容，再修改，最后做触发绑定
- 且强调：设计器中无法直接修改标品内容，以确保标品与定制化共生（开闭原则）
这背后其实是一套强治理逻辑：
- 标品资产是“上游事实”，必须保持可升级；
- 客户化资产是“下游差异”，必须显式可追踪；
- 所谓“复制”，本质是把隐式修改变成显式 Delta。
并且界面设计器也提供了“复制页面”能力，且复制时可更换关联模型，但新模型必须是原模型或其子模型。 这与“客户化模块里做子模型继承”是高度协同的：你复制页面→切到子模型→绑定到客户模块入口，形成完整闭环。
6）Upstream 视角下的升级策略：把升级做成“合并差异”，而不是“重做定制”
要把 upstream 用到“交付体系级”，你需要用模块生命周期思维看升级：
这也是为什么 upstream 适合规模化交付：它把复杂度从“不可控的代码漂移”变成“可审计的差异资产”。
7）一组高频踩坑点：都是“工程尺度”的坑
这些坑不是语法坑，而是会把交付体系拉回项目制的坑：
-
包路径重叠导致元数据加载问题 模块 packagePrefix 不能包含相同包路径，否则会导致元数据加载出问题。
-
模块编码不可变 模块安装后直到卸载，编码不可变更，否则系统会识别为新的元数据。
-
扩展点不生效：入口没切换到客户化模块 你写了 context.requestFromModule=="ce_expenses"，但用户从标品入口进来，条件永远不成立。
-
参数命名冲突 函数参数别叫 context。
-
Hook 滥用造成性能债 拦截器太多性能下降是“不可避免”。
8）给团队落地的一份“更像工程规范”的 Checklist
如果你要把 upstream 当作交付体系能力来推，我建议至少固化这些规则：
- 禁止改标品模块：任何客户差异必须进入客户化模块（代码/设计器资产都一样）。
- 客户化模块创建时：同时配置
dependencies 与 upstreams（先依赖、再上游）。
- 客户化模块必须成为用户入口：复制标品菜单并以客户化模块作为访问入口。
- “修改”类需求必须走 复制→修改→重新绑定，禁止直接在标品资产上改。
- Extpoint 统一使用表达式做“作用域隔离”（尤其按
requestFromModule）。
- Extpoint 条件要互斥：避免多个实现争抢同一扩展点（虽然最终只选一个执行，但会制造不可解释性）。
- Hook 需要登记与预算：每新增一个 Hook，明确拦截范围、目的、优先级、性能风险。
- 测试必须覆盖“页面发起请求”的路径，别只测 Java 直接调用。
- 包路径与模块编码在立项时就规划好，避免后期“想改名”导致元数据混乱。
- 维护一份“差异清单”：客户化模块里有哪些复制页面、哪些流程覆盖、哪些 extpoint/hook——让差异成为资产而不是传说。
最后我想说
在 Oinone 里，Upstream 的价值不在“继承本身”，而在它把客户定制从“随手改标品”升级为：
- 入口可控
- 差异可见
- 影响范围可被表达式约束
- 升级可被组织成合并差异的工程流程
。
