es modules 的模块边界由显式导出和最小化导入共同定义：文件只暴露公共接口，禁止通配符导入，通过入口文件收敛导出、工具链约束与工程规范保障边界清晰。
在组件化开发中，ES Modules 的模块边界不是靠目录结构或命名约定自动形成的，而是由 显式导出 和 最小化导入 共同定义的。边界清晰的关键在于：每个文件只暴露它真正对外负责的接口，且外部只能通过 import 明确声明所需内容来访问。
导出必须聚焦职责，不暴露实现细节
一个组件模块（如 Button.js）应只导出其公共契约，而非内部工具函数、私有状态或未封装的 DOM 操作逻辑：
- ✅ 推荐：导出组件类、渲染函数、配置类型、事件常量等稳定接口
- ❌ 避免：导出内部
validateProps工具函数、defaultStyles对象（除非明确作为可复用样式基类）、未加封装的renderInnerHTML - 示例：
export class Button { ... }
export const BUTTON_VARIANTS = ['primary', 'outline'];
export function renderButton() { ... } // 若仅被本模块使用，不应导出
导入需按需声明，禁用通配符导入组件模块
组件使用者必须清楚知道自己依赖了什么，不能靠 import * as Button from './Button.js' 模糊引用：
- ✅ 强制使用具名导入：
import { Button, BUTTON_VARIANTS } from './Button.js' - ✅ 默认导入仅用于单一主出口（如 React 函数组件本身）：
import Button from './Button.js' - ❌ 禁止
import * as Button from './Button.js'—— 它隐藏依赖、阻碍 tree-shaking、易引发命名冲突 - 工具建议：在 ESLint 中启用
no-unused-vars和import/no-unused-modules插件，自动检测未使用的导出
边界隔离靠文件粒度与 re-export 控制
模块边界天然以单个 .js 文件为单位，但可通过“入口文件”统一收敛对外接口：
- 组件库根目录下设
index.js，仅做有限 re-export：
export { Button } from './components/Button.js';
export { Icon } from './components/Icon.js';
export { internalUtils } from './utils'; // ❌ 不该出现在 index.js - 子模块之间禁止跨层直连（如
Card.js直接 import../../utils/debounce.js），应通过明确的shared/或lib/公共层中转 - 私有逻辑可放在同目录下
__internal__/或utils.js（不对外 export），确保仅本模块内可访问
构建与运行时共同强化边界意识
静态模块系统本身不阻止非法访问，需配合工程约束：
- 打包工具（如 Vite/Rollup）默认支持 ESM 静态分析，能准确识别未使用导出并剔除（tree-shaking）
- 在
package.json中设置"type": "module"，强制整个包走 ESM 规则，避免 CommonJS 混用破坏边界 - 测试文件应只 import 组件公开 API，不直接 require 内部模块 —— 这是验证边界是否真实有效的手段
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
