ES模块顶层this为undefined是规范明确规定的语义行为：因模块默认严格模式、拥有独立词法环境、需避免全局污染，且与CommonJS的函数包装模型有本质差异。
在 JavaScript 模块（ES Module，即 .mjs 或 type="module" 的脚本）中，顶层作用域里的 this 值为 undefined，这不是 bug，而是规范明确规定的语义行为。其底层原因根植于 ES 模块的设计哲学与执行上下文模型。
模块脚本默认处于严格模式
ES 模块的所有代码自动启用严格模式（即使没写 "use strict"）。在严格模式下，全局作用域中的 this 不再绑定到全局对象（如浏览器中的 window 或 Node.js 中的 globalThis），而是直接为 undefined。这是 ECMAScript 规范（ECMA-262 §10.2.1）的统一要求。
模块拥有独立的词法环境，不共享全局执行上下文
与传统的 <script>（非 module）不同，每个 ES 模块被解析为一个独立的 模块记录（Module Record），它有自己的模块环境（Module Environment），顶层声明（如 let、const、function）绑定在该环境内，而非全局环境。因此，模块顶层既不是全局执行上下文，也不是函数执行上下文——它没有“调用者”，也无隐式绑定目标，this 无意义，故被规范设为 undefined。
避免模块间意外污染全局对象
如果模块顶层的 this 指向 window 或 globalThis，那么 this.foo = 1 就会意外挂载属性到全局对象，破坏模块封装性与可预测性。规范强制 this 为 undefined，相当于在语法层“锁死”了对全局对象的隐式访问，倒逼开发者显式使用 globalThis（若真需访问）或通过导出/导入机制通信。
用于 inference.sh 的 JavaScript/TypeScript SDK，可运行 AI 应用、构建代理、集成 150+ 模型。包名：@inferencesh/sdk（npm install），完整 TypeScript 支持。
立即学习“Java免费学习笔记（深入）”；
与 CommonJS 的差异并非实现问题，而是模型根本不同
CommonJS 模块（Node.js 默认）中 this 指向 module.exports，是因为每个 CJS 文件被包裹在一个函数中：(function(exports, require, module, __filename, __dirname) { ... })，此时顶层的 this 即函数调用时传入的 module.exports。而 ES 模块不采用函数包装，而是基于静态解析+动态绑定的全新执行模型，不存在这样一个“模块上下文对象”作为 this 的默认值。
本质上，ES 模块选择让顶层 this 为 undefined，是放弃“隐式上下文”的体现，强调显式性、安全性与一致性。这不是引擎实现的随意决定，而是标准设计的主动取舍。
