作用域链顶端是当前执行环境的全局对象而非固定为window，它在浏览器中为window、node.js中为global、worker中为self、es模块中可能为undefined；globalthis是跨环境统一访问该全局对象的标准只读属性。
作用域链的顶端不是“一定是 window”，而是当前执行环境的全局对象——在浏览器主窗口里它恰好是 window，但在 Node.js、Web Worker 或模块环境下，它可能是 global、self，甚至 undefined（比如 ES 模块顶层）。所谓“顶端”，指的是变量查找失败时最终停靠的位置，这个位置由运行时环境决定，不是语言本身硬编码为 window。
为什么老教程总说“作用域链顶端是 window”
因为早期 JavaScript 几乎只在浏览器中运行，window 就是事实上的全局对象，所有未声明直接赋值的变量、var 声明的顶层变量，都会变成 window 的属性。开发者习惯用 window.xxx 访问全局变量，久而久之就误以为这是 JS 语言的规定。
- 非模块脚本（如
<script></script>直接引入）中，var a = 1确实让window.a === 1 - 但同一页面中
<script type="module"></script>里的var a = 1，不会挂到window上，window.a是undefined - Node.js 模块中，顶层
var b = 2也不会成为global.b，而是模块私有
globalThis 怎么做到跨环境统一访问
globalThis 不是“替换”或“覆盖”了 window，而是标准定义的一个**只读属性**，它在任何合规的 JavaScript 环境中都返回当前上下文真正的全局对象引用：
- 浏览器主线程 →
globalThis === window - Web Worker / Service Worker →
globalThis === self - Node.js（v12+）→
globalThis === global - ES 模块顶层 →
globalThis仍可访问，但this是undefined
它解决的是“怎么安全拿到全局对象”这个问题，而不是“怎么让所有环境都有 window”。写 globalThis.setTimeout 或 globalThis.fetch 可以避免 ReferenceError: window is not defined。
什么时候该用 globalThis，而不是 window 或 global
当你写的代码需要跑在多种环境（比如一个通用工具库、跨平台组件、Worker 通信逻辑），且需要读写全局属性或调用全局 API 时：
- 想挂载一个全局配置：
globalThis.MY_CONFIG = { debug: true } - 检测是否支持某 API：
if (globalThis.AbortController) { ... } - 在 Worker 和主线程复用同一份工具函数，又涉及
setTimeout或atob
如果明确只跑在浏览器页面（且不涉及 iframe 或 Worker），用 window 依然清晰直接；但如果目标是可移植性，globalThis 是唯一推荐方式。
注意：globalThis ≠ 全局作用域的“入口”
它只是个访问器，不能改变作用域规则。比如：
- 模块中
globalThis.foo = 1确实会挂到全局，但foo在模块内仍不可直接访问（没import或没声明） -
let bar = 2在模块顶层，不会出现在globalThis.bar中，哪怕你手动赋值也不行 - 作用域链查找变量时，仍按词法作用域逐级向上，最后查到
globalThis所指的对象——但这个对象本身不参与变量声明过程
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
