模块模式通过闭包实现子应用JS作用域隔离，需配合沙箱、DOM/CSS隔离及规范卸载机制才能有效防止微前端全局污染。
模块模式本身不直接解决微前端的全局污染，但它能成为子应用内部隔离的关键基础。微前端的全局污染主要来自共享环境（如 window）下的变量、函数、事件监听器、定时器、DOM 操作等冲突；而模块模式通过闭包天然的作用域封闭性，让每个子应用在加载时就能约束自身代码的“可见边界”，避免随意挂载到全局。
用 IIFE 封装子应用入口逻辑，切断隐式全局泄漏
子应用的主入口（如 bootstrap/mount/unmount）不应直接声明变量或函数，而应包裹在立即执行函数中：
- 所有内部变量（如配置、状态缓存、工具函数）默认私有，不会意外成为 window 属性
- 只显式暴露 mount、unmount 等生命周期函数，且这些函数返回值为纯对象或 Promise，不附带副作用
- 避免在顶层作用域写
var api = ...或function init() {...}—— 这类语句在非严格模式下会自动挂到 window 上
结合沙箱机制，让模块模式真正生效
模块模式单独运行在微前端中效果有限，必须配合运行时沙箱才能防止跨子应用污染：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- JS 沙箱（如 Proxy 实现的快照/代理沙箱）会拦截对 window 的读写，此时模块模式封装的私有变量更安全——因为即使子应用试图覆盖
window.utils，沙箱也能捕获并重定向 - 模块模式中暴露的公共接口（如
exportAPI）应只操作闭包内数据，不依赖或修改 window 上的任意属性 - 若子应用需注册全局事件（如
addEventListener('custom:refresh', ...)），应在 unmount 时主动清理，且事件名加前缀（如myapp:refresh），避免与其它子应用冲突
避免模块模式被绕过：禁止导出构造函数或工厂方法
有些子应用误将模块模式写成可多次实例化的形式，导致多个副本共存于同一页面，引发状态混乱：
立即学习“前端免费学习笔记（深入）”；
- 不要导出类似
createService()或new MyModule()的方式，这破坏了模块的单例语义和隔离意图 - 正确做法是返回一个固定对象，所有状态都收敛在闭包内，例如：
const AppBridge = (function() { let state = {}; return { getState() { return state; }, update(key, val) { state[key] = val; } }; })(); - 该对象在子应用生命周期内始终唯一，且无法被外部 new 或重新初始化
与 CSS 和 DOM 隔离协同，形成完整防护
模块模式只管 JS 作用域，但全局污染还包括样式和 DOM 节点泄漏：
- 模块内创建的 DOM 元素（如弹窗容器、loading 蒙层）必须挂载到子应用专属容器（如
document.getElementById('myapp-root')），而非document.body - 动态插入的 style 标签应添加 data-app-id 属性，并在 unmount 时一并移除
- 若使用 Shadow DOM，模块模式可进一步封装其内部逻辑，使组件状态与宿主完全解耦
