JavaScript全局变量self行为与MDN描述不符的问题及相关技术疑问

关于全局self变量的疑问解答 #

我最近也碰到过类似的全局self变量踩坑情况，结合你的实际测试和问题，来逐一拆解：

问题1：MDN的描述是否不准确，或是近期出现了导致self不再只读的Bug？

MDN的描述其实是准确的，但这里有个容易混淆的细节：Window.prototype.self是一个只读的访问器属性，也就是说你直接执行window.self = 'something'在严格模式下会报错，非严格模式下也不会生效。但你用var self = 'Something'在全局作用域声明时，本质是给window对象添加了一个可写的自有属性，这个自有属性的优先级高于原型链上的Window.prototype.self，所以会覆盖掉原本指向window的self。这并不是浏览器的Bug，而是JS变量声明和原型链属性查找的规则导致的。

问题2：使用var self修改全局变量的结果是否符合预期？这是否因为self是保留关键字？这种情况极易引发混淆？

首先，self并不是ECMAScript的保留关键字，所以用var self声明是完全合法的语法。这个结果其实符合JS的全局变量规则：在全局作用域用var声明的变量会自动成为window对象的可枚举属性，并且会覆盖原型链上同名的属性（哪怕原型上的属性是只读的）。

这种情况确实非常容易引发混淆——因为浏览器环境下默认self指向window是一个广泛的约定，开发者和工具都会默认依赖这个行为，突然被覆盖后，依赖self的代码就会出现各种莫名其妙的错误（比如你遇到的.push()调用失败）。

问题3：修改self是否属于不良实践？我曾了解到若在局部作用域内修改self是可行的，但实际情况是任何位置修改self都会影响全局空间。由于Webpack等库默认假设self指向Window对象，是否应该避免修改self？是否还有其他库存在同样的假设，修改self可能引发各类问题？

毫无疑问，全局修改self属于严重的不良实践，原因如下：

• 全局变量本身就应该尽量避免，而self是浏览器环境下有特殊用途的全局标识符，修改它会污染全局命名空间；
• 大量前端工具、库（比如Webpack的动态导入逻辑、部分异步加载库、甚至一些浏览器API的polyfill）都会默认假设self指向window，修改后会直接破坏这些依赖，导致难以排查的兼容性问题；
• 你提到的局部作用域修改self是完全不同的场景——比如在函数内部声明var self = this;，这是局部变量，不会污染全局，反而是处理this绑定问题的常见写法，和全局修改self没有冲突。

除了Webpack之外，像一些模块化加载器、PWA相关的工具（比如Service Worker相关的代码也会用到self）、甚至一些UI框架的内部实现，都可能依赖self指向window的约定，全局修改self会给这些代码埋下隐患。

另外，你通过修改Webpack配置将globalObject设为'window'的解决方案非常合理，这样Webpack会直接使用window而非self来进行模块加载的逻辑，彻底规避了self被覆盖的风险。

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