应优先使用命名导出与命名空间导入实现模块化解构与隔离：通过export显式暴露具名接口，import { }精确解构，import * as创建隔离命名空间，避免混合导出以保持一致性。
要实现符合 ES6 标准的模块化解构与命名空间隔离，核心是用好 命名导出（named export） 和 命名空间导入（import * as），配合明确的作用域边界和静态声明规则。默认导出虽灵活，但不利于解构控制和命名空间清晰管理，因此不作为首选策略。
用命名导出定义可预测的公共接口
每个模块只通过 export 显式暴露需要被外部使用的变量、函数或类，且全部使用具名形式。这样既避免污染全局作用域，又让接口一目了然。
- 支持在声明时直接导出：
export const API_URL = 'https://api.example.com'; - 也支持集中导出列表：
export { API_URL, fetchUser, UserClass }; - 导出时可重命名：
export { API_URL as BASE_URL };，便于统一命名规范
用 import { } 精确解构所需成员
调用方按需提取，不加载未声明的导出项，利于 tree-shaking，也强化了依赖可见性。
- 必须用花括号匹配导出名：
import { fetchUser, BASE_URL } from './api.js'; - 可同时重命名导入：
import { fetchUser as getUser } from './api.js'; - 不能用花括号导入默认导出，也不能混用命名与默认导入（除非明确区分）
用 import * as 创建隔离的命名空间
当需要保留模块内所有命名导出的原始结构，又不想污染当前作用域时，用命名空间导入是最安全的方式。
-
import * as api from './api.js';—— 所有命名导出都挂载在api对象下 - 访问方式为
api.fetchUser()或api.BASE_URL，完全避免命名冲突 - 支持别名：
import * as userApi from './user-api.js';，增强语义可读性
避免混合导出破坏命名空间一致性
一个模块同时含 export default 和多个 export，会让导入逻辑变复杂，削弱命名空间的可控性。
- 例如
import logger, { API_URL } from './utils.js'需要跳转源码才能确认来源 - 建议将“主功能”与“工具集合”拆成两个模块：一个只用默认导出（如主配置对象），另一个全用命名导出（如工具函数库）
- ES6 模块本身已保证单例和作用域隔离，无需额外封装，关键在导出方式的一致性
