模块化通过作用域隔离解决变量污染：顶层声明（let/const/var）仅在本模块有效，隐式全局赋值报错；通信须显式export/import，按需导出、命名导入、避免mutable共享，状态交由专用模块管理。

模块化开发中，变量声明不再暴露到全局，而是天然被封装在独立作用域里——这是模块化解决变量污染的核心机制。

模块顶层声明即私有变量

在 ES6 模块（.mjs 或 type="module" 的 script）中，所有用 let、const 或 var 在顶层声明的变量，都只在当前模块内有效：

• let count = 0; 和 const API_URL = "https://api.example.com"; 不会挂到 window 上，外部无法直接访问
• 即使不加任何关键字，直接写 message = "hello"; 也不会创建隐式全局变量，而是抛出 ReferenceError（模块默认启用严格模式）
• 模块之间通信必须显式通过 export / import

导出变量要明确意图

不是所有变量都需要导出。导出前先问：这个值是否真需要被其他模块依赖？

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 用 export const MAX_RETRY = 3; 导出配置常量，语义清晰且不可变
• 用 export let currentUser; 谨慎导出可变状态，容易引发意外修改
• 避免 export var tempFlag = false; —— var 在模块中无实际优势，且易混淆作用域行为
• 内部工具函数、缓存对象、临时计算结果，一律不导出，保持封装性

导入时按需命名，避免命名冲突

导入不是“把另一个文件的变量全搬过来”，而是建立本地绑定：

• import { apiTimeout, retryDelay } from "./config.js"; —— 只引入需要的项
• import * as config from "./config.js"; —— 若需全部，用命名空间方式，调用时写 config.apiTimeout，避免平铺污染本地作用域
• import { apiTimeout as TIMEOUT } from "./config.js"; —— 重命名可消除命名冲突，也提升可读性

跨模块共享状态的替代方案

不要为了“让多个模块访问同一个变量”而滥用全局或导出 mutable 对象：

• 状态管理交给专门模块，如 store.js 提供 getState() 和 updateState() 方法，而非直接导出 let state = {}
• 配置类数据优先用 export 常量，运行时动态值尽量通过函数返回或事件通知传递
• 确实需要单例对象时，用 export default new Service();，确保实例唯一，但避免暴露其内部属性为可写

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南