“单向度依赖隔离”指业务模块仅暴露稳定、收敛、无副作用的接口，隐藏实现细节与状态，杜绝反向依赖；通过命名导出纯函数、default导出封装主入口、禁导可变绑定、审慎重导出，确保调用流向清晰可控。
“单向度依赖隔离”不是标准术语，但结合上下文，它指的是一种设计意图：让业务模块只暴露**稳定、收敛、无副作用的接口**，同时隐藏内部实现细节、避免反向依赖（比如不导出可变状态、不导出供其他模块修改的私有工具函数），从而形成清晰、可控、不可逆的调用流向。
明确导出边界：只暴露契约，不暴露实现
复杂业务逻辑常包含状态管理、中间计算、副作用操作（如 API 调用、缓存读写）。导出时应剥离这些，只保留“输入→确定性输出”的纯函数或封装后的服务对象。
- ✅ 做法：用 命名导出 暴露经过抽象的业务方法，例如
export function calculateOrderTotal(items, discounts)，而非导出applyDiscount()或cacheManager - ❌ 避免：导出内部工具函数（如
export function normalizePrice(str)）、临时变量（export let currentStep = 1）或未封装的 Promise 实例 - 说明：命名导出天然支持按需引入，调用方只拿到接口签名，无法触达底层数据流或状态机
用 default 导出主入口，强制单一职责
一个业务模块通常有一个核心能力（如“订单结算服务”）。用 export default 将其封装为类或工厂函数，使导入方只能通过该入口使用，无法绕过封装直接访问子模块。
- ✅ 示例：
export default class OrderService { constructor(config) { ... } confirm() { ... } rollback() { ... } } - ✅ 工厂模式更灵活：
export default (apiClient) => new OrderService(apiClient)，把依赖注入控制权交给调用方，自身不持有外部引用 - 说明：default 导出不可重名、不可多选，天然约束模块对外只提供一种“主视角”，防止业务逻辑被零散拆解、误用
禁止导出可变绑定或未封装状态
ES 模块导出的是**实时绑定（live binding）**，若导出一个 let 变量，其他模块修改它会直接影响原模块。这对业务逻辑稳定性是重大风险。
- ✅ 安全做法：导出只读常量（
export const STATUS_CODES = { PENDING: 'pending', ... }）或不可变对象（用Object.freeze包裹） - ✅ 状态应封装在类/闭包内，仅通过方法暴露受控读写（如
getLastError()），不导出原始 state 对象 - ❌ 危险示例：
let currentUser = null; export { currentUser };—— 其他模块可随意赋值，破坏业务一致性
用重导出（re-export）聚合，但不透传内部细节
当模块需组合多个子模块能力时，可用 export { X } from './sub'，但必须确保重导出的内容仍符合隔离原则。
- ✅ 合理重导出：
export { validateAddress } from './validators';（该函数本身已无副作用、无状态） - ❌ 不合理重导出：
export { addressCache } from './cache';（暴露了可被任意清空或篡改的缓存实例） - 说明：重导出不是“转发”，而是“授权”。每一条
export from都应经过审查，确认其不破坏单向依赖约束
