应使用 globalthis 而非 window 或 self,因其是 es2020 标准化全局对象引用,在浏览器、worker、node.js 等环境均可靠指向真正全局作用域,避免沙箱禁用、嵌套 iframe 指向错误或环境缺失导致的报错或静默失败。

为什么不能直接用 window 或 self?
在 HTML 编辑器沙箱(比如 CodePen、JSFiddle、或自建的 <iframe sandbox></iframe>)中,window 可能被禁用或重定义,self 在某些嵌套 iframe 场景下会指向子上下文而非顶层全局对象。更麻烦的是,Worker 环境里连 window 都不存在,只有 self;而 Node.js(虽然不常见于编辑器沙箱)里两者都不可用。直接硬写 window.foo = bar 很容易报 Cannot set property 'foo' of undefined 或静默失败。
globalThis 是唯一可靠的跨环境全局对象入口
globalThis 是 ES2020 标准引入的标准化全局对象引用,它在浏览器、Web Worker、Node.js、甚至 Deno 中都指向各自环境真正的全局作用域对象。在沙箱 iframe 里,只要不是极端禁用(如 sandbox="allow-scripts" 但移除了 allow-same-origin),globalThis 仍可访问且行为一致。
- 它不是 polyfill —— 现代浏览器(Chrome 71+、Firefox 65+、Safari 12.1+)原生支持
- 不需要判断
typeof window !== 'undefined'这类条件分支 - 在严格模式、模块脚本、甚至
eval()作用域中,globalThis始终可用
示例:统一挂载工具函数
globalThis.$utils = {
debounce: (fn, ms) => { /* ... */ },
log: (...args) => console.log('[sandbox]', ...args)
};
沙箱 iframe 中要小心 globalThis 的实际指向
如果沙箱 iframe 启用了 sandbox="allow-scripts" 但没加 allow-same-origin,它的 globalThis 仍是该 iframe 自己的全局对象,不是父页面的 —— 这是预期行为,不是 bug。这时候你无法通过 globalThis 跨 iframe 通信,必须显式走 postMessage。
- 检查是否同源:
globalThis === window在同源 iframe 中为true,跨源时为false - 避免误以为
globalThis能绕过沙箱限制 —— 它只是提供统一访问路径,不提升权限 - 若需从父页注入变量,仍得用
iframe.contentWindow(同源)或postMessage(跨源)
兼容旧环境时怎么安全 fallback?
如果目标环境可能低于 Chrome 71(比如某些企业内网 IE/Edge Legacy),不能直接依赖 globalThis。但别手写一堆 if (typeof window !== 'undefined') ... else if (typeof global !== 'undefined') ... —— 容易漏掉 Web Worker 的 self 或 Node 的 global。
推荐用极简检测逻辑:
const safeGlobal = (function () {
if (typeof globalThis !== 'undefined') return globalThis;
if (typeof window !== 'undefined') return window;
if (typeof self !== 'undefined') return self;
if (typeof global !== 'undefined') return global;
throw new Error('No global object available');
})();
注意:这个 fallback 仅用于兼容,不是替代 globalThis 的理由。生产环境应优先要求现代运行时。
真正容易被忽略的是:即使用了 globalThis,在 <script type="module"></script> 中声明的顶层变量默认不会自动挂到全局,必须显式赋值给 globalThis —— 模块作用域隔离不会因为 globalThis 而失效。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











