JavaScript模块化是语言级机制，结合设计模式可实现高内聚（闭包封装、职责聚焦）、低耦合（依赖注入、接口抽象、事件通信），并按业务能力而非技术分层切分模块。
JavaScript 模块化本身不是设计模式，而是语言级的组织机制；但结合设计模式（如模块模式、工厂模式、观察者模式等），能自然支撑“高内聚、低耦合”的架构目标。关键不在于套用模式名称，而在于用封装控制可见性、用契约约束交互、用职责边界隔离变化。
用闭包封装私有状态，实现高内聚
内聚的本质是“职责聚焦”——一个模块只做且只做好一件事。闭包是最直接的手段：
- 把相关数据和行为包裹在立即执行函数（IIFE）或类中，内部变量和辅助函数默认不可见
- 只暴露最小必要接口，比如仅导出 add、reset，不暴露中间计算逻辑或缓存对象
- 例如计数器模块：内部维护
count和logHistory数组，但只提供increment()、get()、clear()—— 所有操作都围绕“状态管理”这一核心职责，没有混入 UI 渲染或网络请求
用明确接口+依赖注入解耦模块协作
低耦合不等于零依赖，而是让依赖可替换、可测试、不隐含：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 避免硬编码调用其他模块，比如
apiClient.post(...)→ 改为接收一个符合HttpClient接口的对象 - 用工厂或构造函数注入依赖，而非在模块内部
import具体实现（尤其在测试或微前端场景下） - 业务模块只依赖抽象（如
NotificationService），不关心它是弹窗、语音还是日志；实现由外部组装，模块自身不感知
按业务能力切分模块，而非技术分层
一个常见误区是把所有 utils 放一起、所有 helpers 归一包——这实际是巧合内聚，破坏可维护性：
立即学习“Java免费学习笔记（深入）”；
- 订单模块应包含自己的校验规则、状态机、格式化工具，哪怕和用户模块有相似逻辑，也优先复用抽象（如共享
Money类），而非共用FormatUtils - ES6 模块天然支持细粒度导出：
export { validateEmail } from './validation/email.js'，比大而全的Utils.js更易定位、更少副作用 - 每个模块的
index.js是它的门面，只聚合对外承诺的能力，隐藏内部结构（如 service + adapter + dto 的组合）
用事件或回调代替直接调用，切断隐式依赖
当两个模块需要通信但又不该互相引用时，观察者模式或发布-订阅是最轻量的解耦方式：
- 购物车模块触发
'cart:updated'事件，价格组件和库存组件各自监听，互不知晓对方存在 - 表单模块不调用验证模块，而是把验证函数作为参数传入：
form.submit(onValid, onError) - 这种“通过函数签名协商”比
import { Validator } from 'xxx'更松散，也更容易在运行时切换策略
