核心业务模块应通过“uses”声明导入行为契约而非导出可修改变量。需三步落地：契约建模（定义接口）、注入机制（provide/inject等接收实现）、安全调用（运行时校验+降级）。
在核心业务模块中定义可被第三方扩展的变量行为插槽，关键不是靠 uses 声明本身实现扩展，而是通过它显式引入并组合外部定义的“行为契约”，再配合类型系统与运行时钩子完成解耦。Vue、ArkTS 或 Rust 等现代框架中，“uses”类语法（如 Vue 的 defineComponent + useXXX 组合函数、ArkTS 的 @Builder + use 模式）本质是声明“能力依赖”，而非直接暴露变量。
明确 uses 的定位：不是导出变量，而是导入契约
uses（或类似语义的声明，如 import { useCustomBehavior } from './extensions'）不用于定义可被修改的公共变量，而是让模块声明：“我支持某种行为扩展点，并接受符合约定的实现”。例如：
- 核心订单模块不暴露
orderStatusText变量供第三方赋值，而是声明uses: ['orderStatusFormatter']； - 第三方需提供一个满足
{ format: (status: string) => string }类型的对象； - 核心模块在渲染时调用该
format方法，而非读取某个被覆盖的字段。
定义可扩展的行为插槽需三步落地
以 ArkTS 或 Vue3 组件化场景为例，实战中需同步完成：
-
契约建模：在核心模块中用接口或类型别名定义行为签名，如
interface OrderStatusHook { format(status: 'draft' | 'paid' | 'shipped'): string }； - 注入机制：通过构造参数、provide/inject 或全局注册方式接收第三方实现，避免硬编码；
- 安全调用：运行时校验传入对象是否具备必需方法，缺失时降级为默认逻辑，不中断主流程。
避免常见陷阱：变量 vs 行为的本质区别
把“可扩展变量”理解为可被第三方直接赋值的 export let customLabel = '默认' 是危险的——它破坏封装、无法类型约束、难以调试。正确路径是：
- 用函数替代变量：把
customLabel改为getCustomLabel: () => string； - 用插槽替代属性：把静态文本替换为
- 用组合函数替代全局状态：把行为逻辑封装进
useOrderExtension()，由使用者决定是否传入定制实现。
实际代码片段示意（ArkTS 风格）
核心组件声明扩展点：
// OrderCard.etsexport interface OrderExtension {
formatStatus?: (s: string) => string;
renderAction?: (order: Order) => CustomNode;
}
...
@Component
struct OrderCard {
@Prop extension?: OrderExtension;
build() {
Column() {
Text(this.extension?.formatStatus?.(this.order.status) || this.order.status)
this.extension?.renderAction?.(this.order) || Button('默认操作')
}
}
}
第三方接入只需提供对象，无需修改核心代码，也不需要运行时 patch 变量。
