JavaScript模块化核心是控制代码可见性与访问边界：通过封装限制内部实现细节，仅暴露明确接口；遵循最小暴露原则规范导出；用JSDoc、TypeScript和Object.freeze强化接口契约；依赖必须显式import声明。
JavaScript模块化的核心在于控制代码的可见性与访问边界：封装内部实现细节，只通过明确接口对外提供能力。
封装性：限制内部变量和函数的作用域
模块天然具备作用域隔离能力。使用 ES6 模块（import/export） 或 IIFE（立即执行函数） 可避免污染全局命名空间。内部声明的变量、函数、类默认不可被外部访问，除非显式暴露。
例如，在一个模块文件 mathUtils.js 中：
// 内部辅助函数，不对外暴露
function roundToTwo(num) { return Math.round(num * 100) / 100; }
// 仅导出需要被调用的函数
export function add(a, b) { return roundToTwo(a + b); }
export function multiply(a, b) { return roundToTwo(a * b); }
立即学习“Java免费学习笔记（深入）”；
外部无法访问 roundToTwo，它只是内部实现细节，体现了良好的封装性。
接口暴露规范：明确导出内容，避免“全量导出”
应遵循“最小暴露原则”——只导出使用者真正需要的标识符。不推荐使用 export * 或默认导出大量未加约束的对象。
- 优先使用具名导出（export function / const / class），便于按需引入和静态分析
- 慎用默认导出（export default），仅当模块有唯一主入口时适用（如一个组件、一个工具类实例）
- 避免在模块末尾集中写 export { a, b, c, d }，而应在定义处就近导出，提升可读性和维护性
类型与文档协同增强接口契约
暴露的接口不仅是语法可见，更应具备语义清晰性。可通过以下方式强化契约表达：
- 为导出函数添加 JSDoc 注释，说明参数、返回值、异常场景
- 配合 TypeScript 定义精确类型（如 export function fetchUser(id: string): Promise
） - 对导出对象的属性做只读或冻结处理（如 export const CONFIG = Object.freeze({ API_URL: '...' })），防止外部误修改
跨模块依赖应显式声明，不隐式耦合
模块间通信必须通过 import 声明依赖，禁止通过全局变量、事件总线或直接操作其他模块内部状态来“绕过接口”。例如：
- ✅ 正确：在 apiClient.js 中 import { getToken } from './auth.js'，再调用 getToken()
- ❌ 错误：在 apiClient.js 中直接访问 window.__authToken 或修改 authModule.token
这种显式依赖关系让模块边界清晰，也利于 tree-shaking 和单元测试模拟。
