模块化通过作用域隔离解决变量污染：顶层声明（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在模块中无实际优势，且易混淆作用域行为 - 内部工具函数、缓存对象、临时计算结果，一律不导出，保持封装性
导入时按需命名，避免命名冲突
导入不是“把另一个文件的变量全搬过来”，而是建立本地绑定：
立即学习“Java免费学习笔记（深入）”；
-
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();，确保实例唯一，但避免暴露其内部属性为可写
