ESM（ECMAScript 模块）中不存在可直接访问的 module 作用域对象；试图通过 module.bar = 1 动态挂载属性是无效且不可行的——这源于 ESM 的静态编译特性和作用域本质，正确做法是显式声明变量或利用闭包/函数自身属性（需谨慎处理异步与并发场景）。
esm（ecmascript 模块）中不存在可直接访问的 `module` 作用域对象；试图通过 `module.bar = 1` 动态挂载属性是无效且不可行的——这源于 esm 的静态编译特性和作用域本质，正确做法是显式声明变量或利用闭包/函数自身属性（需谨慎处理异步与并发场景）。
在 CommonJS 环境中，开发者习惯通过 module.exports 或直接向 module 对象赋值来实现模块级状态管理（如 module.cache = new Map()）。但 ESM 的设计哲学截然不同：它基于静态语法分析，所有导出必须在顶层声明（export 语句不可动态生成），且模块作用域本身不是运行时可访问的对象——不存在类似 module 或 exports 的隐式绑定变量。
这意味着以下写法在 ESM 中语法错误且无法运行：
export function foo() {
module.bar = 1; // ❌ ReferenceError: module is not defined
}✅ 推荐方案：清晰、安全、符合规范
1. 显式声明模块级变量（最推荐）
将共享状态作为普通顶层变量声明，并通过 export 暴露读写接口：
// math-utils.js
let bar = 1;
export function foo() {
console.log('Current bar:', bar);
}
export function setBar(value) {
bar = value;
}
export function getBar() {
return bar;
}✅ 优势：语义明确、支持 tree-shaking、便于测试与调试；
⚠️ 注意：若需多实例隔离，请避免全局模块状态，改用工厂函数。
2. 利用函数自身属性（仅限同步、单例场景）
你提到的 foo.bar = 1 在技术上可行，但存在严重限制：
export function foo() {
foo.bar = 1; // ✅ 运行时合法（函数是对象）
}然而，正如你后续发现的——在异步函数中极易引发竞态问题：
export async function foo() {
await delay(100);
foo.bar = Math.random(); // ❌ 多次调用会相互覆盖，无内存隔离
}此外，该方式违背“单一职责”原则，混淆了函数逻辑与状态存储，且 TypeScript 无法推断此类动态属性，导致类型丢失。
3. 使用闭包封装（适合私有状态）
若需隐藏状态并提供受控访问：
export const createCounter = () => {
let count = 0;
return {
increment: () => ++count,
getCount: () => count,
};
};
// 使用
const counter1 = createCounter();
counter1.increment(); // 1⚠️ 关键注意事项
- globalThis 不是替代方案：它指向全局对象（如 window 或 global），属于跨模块污染，违背模块封装性；
- 不要模拟 CJS 行为：ESM 的静态特性决定了它不支持运行时模块元数据操作；
- 构建工具不会补全 module：Babel、TypeScript 或打包器（Vite/Webpack）均不会注入 module 变量到 ESM 作用域中；
- 编辑器兼容性需求？：你引用的 projectional editor 场景，应通过 AST 解析 + 模块图分析实现，而非依赖运行时 module 对象——现代语言服务（如 TypeScript Server）已原生支持 ESM 静态结构分析。
总结
ESM 的“无 module 对象”不是缺陷，而是对可预测性与工具链友好的主动设计。放弃对动态模块作用域的执念，转而采用显式变量、闭包或依赖注入等现代模式，才能写出更健壮、可维护、可协作的模块化代码。记住：清晰的意图 > 巧妙的 hack。
