应使用 globalThis 而非 window 或 self，因其是 ES2020 标准化全局对象引用，在浏览器、Worker、Node.js 等环境均可靠指向真正全局作用域，避免沙箱禁用、嵌套 iframe 指向错误或环境缺失导致的报错或静默失败。
为什么不能直接用 window 或 self？
在 HTML 编辑器沙箱（比如 CodePen、JSFiddle、或自建的 <iframe sandbox>）中，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"> 中声明的顶层变量默认不会自动挂到全局，必须显式赋值给 globalThis —— 模块作用域隔离不会因为 globalThis 而失效。
