为何要将JavaScript的window对象封装到自调用函数中再使用？

该封装写法的核心作用 #

• 作用域隔离：自调用匿名函数（IIFE）会创建独立的函数作用域，内部声明的所有临时变量、工具函数都不会泄漏到全局命名空间。在同时依赖AngularJS、jQuery等多份第三方库的老项目中，能从根源上避免不同脚本的变量名、函数名冲突问题。
• 压缩体积优化：将window作为入参传入IIFE后取别名w，代码压缩工具可以将别名进一步压缩为单个字符，而window是JS内置的全局关键字，压缩工具无法对其做重命名优化，大量引用场景下能有效减少最终打包后的代码体积。
• 运行环境兼容：如果后续需要适配非浏览器运行环境（比如沙箱单元测试、早期同构代码的服务端模拟运行），仅需要修改IIFE传入的全局对象参数，不需要逐行改动内部所有引用全局对象的代码，可维护性更强。
• 全局引用稳定性保障：IIFE会在脚本初始化阶段就捕获当前原生window的引用，就算后续有第三方插件、恶意脚本篡改了全局作用域下的window指向，函数内部的逻辑也不会受影响，稳定性更高。

直接替换为window并去掉IIFE的弊端 #

• 失去压缩优化收益：所有的window关键字都无法被压缩，项目规模较大时会产生不必要的体积冗余。
• 提升全局污染风险：去掉IIFE后，文件顶级作用域下声明的所有变量、函数都会直接挂载到全局window上，很容易和其他第三方库、其他业务脚本的同名变量产生覆盖冲突，这类问题排查成本极高。
• 可扩展性下降：如果后续需要调整全局上下文（比如mock window属性做单元测试、适配其他运行环境），需要逐行修改所有用到window的代码，维护成本远高于仅修改IIFE的入参。
• 稳定性降低：代码逻辑完全依赖全局window的指向，一旦全局window被其他脚本篡改，业务逻辑会直接失效，没有IIFE的提前捕获作为缓冲。

如果更偏好直接写window的IDE提示体验，可以选择保留IIFE结构、仅将别名w改为window，既可以保留IIFE的作用域隔离等优势，也不会影响IDE的识别提示。

内容的提问来源于stack exchange，提问作者mochsner