esmodule 本身不提供运行时依赖隔离，微前端需通过架构层实现模块隔离：容器统一管控加载、预注册包版本、动态 import 配合沙箱、externals/alias 构建处理、import map + module federation + wrapper 分层方案。
ESModule 本身不提供运行时依赖隔离能力，多版本共存的微服务前端（如微前端）中，模块隔离需靠架构层设计而非 ESModule 语法本身实现。
模块加载器需由容器应用统一管控
子应用不能直接通过 import 加载可能冲突的第三方包（如不同版本的 React、Lodash），而应通过容器应用预加载并注入全局沙箱或按需代理。例如：
- 主应用在加载子应用前，用 SystemJS 或自研 loader 预注册特定版本的包（
System.set('react', System.define('react', ...))） - 子应用改写 import 路径为逻辑名（如
import React from 'react'），实际解析由 loader 映射到对应版本 URL 或已缓存模块 - 避免子应用使用
import _ from 'lodash'，改用容器提供的window.$lodasht_v4或通过 defineExpose 暴露的工具函数
构建时做 externals 和别名处理
Webpack/Vite 构建阶段就要切断对易冲突包的打包依赖：
- 将 React、Vue、Axios 等基础库设为 externals，不打入子应用 bundle
- Vite 中配置
resolve.alias将lodash映射到/@shared/lodash-4.17.21.js等带版本号的入口 - 子应用 package.json 的 peerDependencies 明确声明所依赖的版本范围，由主应用保证满足
运行时模块作用域需靠沙箱 + 动态 import
静态 import 在解析时即绑定，无法动态切换版本；必须用 dynamic import() 配合上下文控制：
- 子应用内部不写
import { debounce } from 'lodash'，而是封装一个loadLodash(version)函数，返回 Promiseimport(`https://cdn.com/lodash-${version}.min.js`) - 配合 Proxy 沙箱，拦截
globalThis.lodash访问，按当前子应用 ID 返回对应版本实例 - 关键：所有跨子应用调用必须走明确定义的接口契约（如
bridge.call('utils:debounce', ...)），不暴露原始模块引用
推荐组合方案：Import Map + Module Federation + Runtime Wrapper
现代微前端可分层解决：
- 底层：用 Import Map 声明各子应用的模块映射表（支持不同版本同名包）
-
中层：用 Webpack Module Federation 共享 runtime 和基础组件，但限制只共享
types和hooks，不共享实现类库 -
上层：每个子应用包裹一层轻量 wrapper，重写
import.meta.url、劫持fetch对模块请求加版本前缀或租户标识
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
