多文件协同时应使用es模块替代script标签，通过export最小接口、iife封装老脚本、严格模式与块级作用域等手段建立清晰边界并防止全局污染。
多文件协同时避免全局变量污染，关键不是“躲”，而是建立清晰的边界和明确的通信规则。现代 JavaScript 项目中，模块系统就是为这个目的设计的天然方案。
用 ES 模块替代 script 标签加载
传统 <script src="a.js"></script> 和 <script src="b.js"></script> 会把所有顶层声明（var、function、甚至未声明赋值）直接挂到 window 上，一旦命名重复就互相覆盖。
改用模块方式：
- HTML 中写：
<script type="module" src="a.js"></script>和<script type="module" src="b.js"></script> - 或统一入口
main.js，再用import加载其他文件 - 每个
.js文件开启模块模式后，const API_URL = '...'、function helper() {...}全部只在本文件内有效，不会变成window.API_URL
导出最小接口，隐藏内部实现
模块不是“不污染”就够了，还要防止“导出即暴露”。哪怕用了模块，如果一股脑 export * 或导出大量工具函数，等于建了个新的全局命名空间。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
推荐做法：
- 只
export真正需要被其他模块调用的函数、类或常量，比如export function init()、export default class ApiClient - 配置项、缓存数据、私有工具函数全部用
const或let声明在模块顶层，不导出 - 避免在模块顶层执行副作用，如自动注册事件或修改
window，改用显式调用的初始化函数
老脚本或第三方库要封装隔离
不是所有代码都能立刻改成模块。遇到不支持 ESM 的老脚本、或 jQuery/underscore 这类默认挂全局的库，不能放任不管。
安全做法：
- 用 IIFE 包裹使用逻辑：
(function() { "use strict"; const $ = window.$; /* 你的代码 */ })(); - 引入后立即清理：若必须用
<script></script>加载 jQuery，可在加载后执行delete window.jQuery; delete window.$;，再通过局部变量引用 - 对无模块格式的老库，手动封装一层导出：
export const myLegacyLib = window.MyLib;，至少让污染可控、可追溯
严格模式 + 块级作用域作为兜底习惯
即使模块化是主力，日常编码也要养成防御性习惯：
- 不用
var，尤其不在函数外声明；let和const在块外访问直接报错，比静默挂window更安全 - 避免
with和eval，它们会动态创建绑定，绕过作用域控制 - 任何临时逻辑，哪怕只是几行调试代码，也放进
{ const temp = ...; console.log(temp); }这样的块里，不给变量逃逸机会
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
