<p>在很多企业交付里，定制化最终都会走向两条老路：</p> - 拷贝分支交付：每客户一套代码/一套版本，碎片化严重，升级接近不可行。
- 硬改标品交付：看似快，实则把标品污染成“项目代码”，长期维护崩掉。
Oinone 在“标准化与定制化共生”的范式里明确点出这两种困境，并强调通过**“定制模块与标准代码物理隔离 + 继承体系并行演进”**去破解升级魔咒。
而 Upstream 正是把这种“物理隔离 + 继承关系”落到模块层面的关键开关： 它让你能创建一个“客户化模块”，继承“标准产品模块”，把差异收敛在客户化模块中，而不去改动标品源码，从而能在同一环境里对比差异、展示不同客户效果。
点击体验Demo
| 演示环境 | 相关视频 |
|---|---|
| ⚡ 直达演示环境
☕ 账号：admin ☕ 密码：admin |
🎬 1. [数式Oinone] #产品化演示# 后端研发与无代码辅助
🎬 2. [数式Oinone] #产品化演示# 前端开发 🎬 3. [数式Oinone] #个性化二开# 后端逻辑 🎬 4. [数式Oinone] #个性化二开# 前端交互 🎬 5. [数式Oinone] #个性化二开# 无代码模式 |
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控制：数值越小优先级越高，越先执行。 - 拦截器数量过多会导致性能下降（文档直说“不可避免”）。 因此我的工程建议是：
-
Extpoint 优先：用“定点扩展 + 条件表达式”表达业务差异；
-
Hook 用在两类场景更健康：
- 横切能力（审计、统一日志、风控打点）
- 平台缺少扩展点、但你又必须在多处函数上保持一致行为时
