es模块天然隔离作用域，每个文件为独立作用域，变量不污染全局；通过import/export明确通信，优先按需导出、封装私有逻辑；构建工具强化边界，不支持时用iife和严格模式兜底。
JavaScript 中变量在模块作用域中避免命名空间污染，核心是让变量天然“待在自己的地盘里”——ES 模块（ESM）的默认行为就是如此：每个 .js 文件就是一个独立作用域，const、let、function 声明不会自动跑到全局去。
用 ES 模块机制作为默认防护层
现代项目应直接启用模块系统，而非手动模拟隔离：
- HTML 中用
<script type="module" src="app.js"></script>加载，脚本自动进入模块作用域 - 文件内声明的变量（如
const API_URL = 'https://api.example.com';）仅在当前文件内有效，其他文件访问不到，除非显式export - 即使两个模块都定义了
const helper = {}，它们互不干扰，不存在重名覆盖问题
导出时只暴露必要接口，不泄露实现细节
模块之间靠 import/export 明确通信，而不是共享变量名：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 避免
export const config = { ... };这类宽泛导出；优先按需导出函数或类：export function fetchUser() { ... } - 私有逻辑用未导出的变量封装，例如缓存对象、内部工具函数，外部无法 import 到
- 若需共享配置，统一导出一个命名清晰的对象：
export const AppSettings = { timeout: 5000, debug: false };，不零散暴露多个同名变量
构建工具辅助强化作用域边界
即便源码写得规范，打包过程也可能引入意外泄漏，需配合工具保障：
- 使用 Webpack 或 Vite 时，默认将每个模块包裹进函数作用域（IIFE 或箭头函数），进一步防止运行时污染
- 对第三方库，优先选 ESM 版本（如
import { debounce } from 'lodash-es'），避免旧版 UMD 入口向window挂变量 - 在
webpack.config.js中配置externals，把 jQuery 等全局库排除打包，同时禁止它污染模块内部作用域
不依赖模块时的兜底策略
若环境不支持模块（如老浏览器内联脚本），需主动补位：
- 用 IIFE 封装逻辑：
(function() { const temp = 'safe'; console.log(temp); })();，确保变量不出圈 - 启用严格模式：
"use strict";让隐式全局赋值（如漏写let直接count = 1）直接报错，不静默挂到window - 必须挂全局时，只挂一个命名空间对象：
window.MyApp = window.MyApp || {};，再往里面加属性，而非零散声明多个变量
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
