是的，globalThis在浏览器、Node.js和Web Worker中均能统一访问全局对象：浏览器中等价于window，Node.js中等价于global，Web Worker中等价于self，ES2020标准确保跨环境一致性。
globalThis 在浏览器、Node.js 和 Web Worker 中是否真能统一访问全局对象
是的，globalThis 就是为这事设计的——它在所有主流 JavaScript 执行环境中都指向当前环境的全局对象。不用再写 typeof window !== 'undefined' ? window : typeof global !== 'undefined' ? global : self 这种判断链了。
但要注意：它只是“指向”全局对象，不是“创建”或“修复”全局对象。比如在严格模式下直接给 globalThis.foo = 1 确实会挂到全局，但若环境本身不支持可配置的全局属性（如某些嵌入式 JS 引擎），赋值可能静默失败。
- 浏览器中
globalThis等价于window - Node.js v12+ 中等价于
global - Web Worker 中等价于
self - Service Worker 和模块脚本中同样可用，无需额外 polyfill
哪些场景下仍不能依赖 globalThis 直接暴露全局变量
globalThis 本身是只读绑定（不可重新赋值），但它指向的对象是否允许动态添加属性，取决于环境实现和运行模式。
典型问题场景：
立即学习“前端免费学习笔记（深入）”；
- ESM 模块中，顶层
this是undefined，但globalThis仍有效；不过某些打包工具（如 Webpack 5 的output.globalObject配置错误）会覆盖其行为 - 使用
vm.Script或vm.createContext创建的沙箱环境，globalThis指向的是该上下文的全局对象，而非 Node.js 主全局 - React/Vue 等框架的 SSR 渲染函数中，若未正确设置
globalThis（比如用node --experimental-vm-modules启动），可能仍需 fallback 到global
兼容性兜底方案要不要加？怎么加才不污染代码
如果还要支持 IE 或 Node.js
推荐做法是定义一次，在入口文件顶部声明：
const globalThis = globalThis || self || window || global;
更稳妥的写法（避免某些旧环境里 self 未定义报错）：
const globalThis = (function () {
if (typeof globalThis !== 'undefined') return globalThis;
if (typeof self !== 'undefined') return self;
if (typeof window !== 'undefined') return window;
if (typeof global !== 'undefined') return global;
throw new Error('no global object available');
})();
注意：不要把这段逻辑封装成函数反复调用——V8 对 globalThis 有特殊优化，而自定义函数会失去这个优势。
用 globalThis 替换 window/global 时最容易踩的坑
最隐蔽的问题不是访问不到，而是「访问到了，但不是你想要的那个」。
- 在 iframe 中，
globalThis指向的是当前 iframe 的window，不是父页面的——这点和直接写window行为一致，但开发者常误以为它“更全局” - 使用
import.meta.url加载的模块中，globalThis正常；但若通过eval()或Function()执行字符串代码，其内部的globalThis仍指向外层环境，不是 eval 创建的新作用域 - 某些测试框架（如 Jest）的模拟环境会篡改
global，但未必同步更新globalThis的 getter，导致单元测试中行为不一致
真正需要跨环境共享状态时，光靠 globalThis 不够，还得配合明确的作用域管理，比如用 WeakMap 存实例，或用单例类封装初始化逻辑。
