我们为什么要写window.?答案

【问题标题】：Why do we write window.?我们为什么要写window.?
【发布时间】：2016-01-23 04:51:21
【问题描述】：

在向网页添加一些初始化代码时，我发现自己写了无数次window.onload = ...，突然想到。

window. 不是必需的，因为window 是当前对象。所以它是可选的！
但是没有人只写onload = ...，我想知道为什么会这样。

我的意思是，我们对编写其他内容没有任何疑虑，比如没有 window. 限定符的 alert。

window.onload = function() {
  alert('Your window has loaded');
};

而实际上，alert 与 onload 一样是 window 对象的方法。
那么，为什么会有差异？为什么像W3C 这样的正式网站也会这样做？

【问题讨论】：

它是显式，所以没有人认为你只是不小心分配给了一个全局变量。
我喜欢这个论点，因为它解释了不同之处。将某些东西分配给变量与调用函数 - 您不可能仅通过调用它来创建新函数，因此很明显该函数已经存在于某个地方。
@Bergi 你能把这个作为答案发布吗？我认为这仍然是最有说服力的论点。

标签： javascript dom-events window-object

【解决方案1】：

我看到以下原因：

减少向上搜索作用域链将略微提高性能。这在 IIFE 中也可以看到，其中 window 作为参数发送给函数，并在其中使用对窗口的本地引用。
如果在window 上全局定义的函数/成员在范围内被覆盖，那么它将无法按预期工作，因此显式引用使其引用正确的函数/成员。这对于创建与全局同名的函数/成员并且仍然能够从影子范围访问全局成员很有用。

【讨论】：

好的，但是为什么会有不同呢？为什么不是每个人都写window.alert 而不是alert，这样也会提高性能？
@MrLister 检查function onload() { // Code Here } onload = something;，这里onload 将无法按预期工作。正如Andre在回答中所解释的那样，onload不仅限于window，它还可以应用于img、iframe等，因此它被显式添加到window上。在alert 的情况下，它不是 critical 功能，即使它被覆盖也不会损害代码（与onload 不同）。

【解决方案2】：

当我们想要明确说明时，我们会写window.。基本上有两种情况可以使用它：

window 对象的属性和方法 - 属于Window interface 的所有内容。你提到的.onload监听器就是一个例子，像window.scrollY、window.status、window.parent、window.open()、window.focus()、window.removeEventListener()等等。
创建全局属性。从任何范围分配给window.myGlobalVar 是创建全局“变量”的常见 JS 习惯用法。诚然，使用var 明确声明它仍然是更好的做法。

虽然我们可以在此处“选择性地”省略 window. 部分，但这并不常见。尤其是通过赋值创建implicitly global variables 是被鄙视的，通常被视为一个错误。因此，如果您是故意这样做的，您可以使用window. 来声明您的意图。

但是，第一种情况并不总是明确定义的。当我们想要使用的属性本质上是一个静态的全局变量并且不一定与window 对象相关时，我们经常会省略window. 部分，即使它已在其上正式指定。你很少看到有人使用document、atob()、Worker、setTimeout() 或fetch() 加上window. 前缀，就像你不使用window.JSON.parse 或window.Array 作为内置对象（虽然它是有效的）。

对于其他一些属性，例如 navigator、location 或 alert()，并不总是很清楚，可能使用了 550 个没有或没有。

【讨论】：

【解决方案3】：

因为.onload 不是window 独有的。例如，它也可以用作document.onload。因此，您可以根据希望何时执行脚本来定义它。

【讨论】：

好的，但是为什么会有不同呢？为什么不是每个人都写window.alert 而不是alert，这也不是排他性的？

【解决方案4】：

window 对象默认由浏览器初始化。这是一个很好的练习显式定义窗口对象，它会影响性能，您的代码将变得易于理解。

【讨论】：