shared worker 不适用于微前端子应用直接使用，因其跨页面共享特性违背隔离原则，易导致状态污染与事件冲突；应由主应用统一托管、封装通信适配器，或改用 messagechannel 中转，必要时在 worker 内按 appid 隔离存储与校验来源。
Shared Worker 本身是跨页面共享的全局资源，天然不满足微前端“子应用隔离”原则。在无界（Wujie）等基于 Proxy 沙箱或 iframe 回退的微前端方案中，直接使用 Shared Worker 容易引发状态污染、事件监听冲突、生命周期错配等问题——比如子应用 A 启动 Shared Worker 并注册了 onmessage，子应用 B 卸载后未解绑却仍接收消息；又或者多个子应用并发调用 worker.port.postMessage()，但共享的内部状态（如计数器、缓存 Map）被交叉修改，导致逻辑异常。
Shared Worker 不该被子应用直接实例化
微前端沙箱（尤其是 Proxy 沙箱）只代理 window 及其属性，而 SharedWorker 构造函数位于顶层作用域，不受沙箱拦截。子应用调用 new SharedWorker(...) 实际仍指向浏览器原生实例，所有子应用共享同一 worker 线程和内存空间，沙箱对其完全“透明”。这意味着：
- 子应用无法通过沙箱控制 Shared Worker 的创建/销毁时机
- worker 内部的全局变量（如
self.xxx）对所有子应用可见且可改 - 子应用卸载时若未主动
port.close()，端口残留可能引发后续通信失败
统一由主应用托管 Shared Worker 实例
将 Shared Worker 的生命周期收归主应用管理，子应用仅通过约定协议与其通信，是最稳妥的解法：
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- 主应用在初始化阶段创建 Shared Worker，并维护唯一
port引用 - 主应用封装一层通信适配器（如
sharedWorkerService），暴露postToWorker(message, appId)和onWorkerMessage(appId, cb)方法 - 子应用通过主应用提供的 API 发送带
appId标识的消息，worker 内部按标识分发/响应，避免混用 - 子应用卸载时，主应用自动清理该
appId对应的监听回调，不依赖子应用自行调用port.close()
用 MessageChannel 替代 Shared Worker（轻量场景）
若 Shared Worker 主要用于子应用间简单数据同步（如用户登录态广播、配置变更通知），可考虑降级为 MessageChannel + 主应用中转：
- 主应用创建一个
MessageChannel，将port1保存，port2分发给各子应用 - 子应用通过
port2.postMessage({ type: 'login', data: user })上报事件 - 主应用监听
port1，收到后做去重、过滤、广播等逻辑，再选择性转发给其他子应用 - 完全规避 Shared Worker 的线程共享与状态耦合问题，且天然支持沙箱环境
必须使用 Shared Worker 时的加固措施
当业务强依赖 Shared Worker（如离线缓存同步、长连接保活），可在 worker 脚本内主动增强隔离：
- 为每个子应用分配独立的
Map存储空间，key 为子应用唯一 ID（如注册时传入的appId） - 所有读写操作前校验
event.source?.name === appId，拒绝非法来源消息 - 在
connect事件中动态生成子应用专属端口，并记录活跃端口列表，定期清理超时未通信的端口 - worker 内禁止使用
self.xxx = ...直接挂载全局状态，全部收敛至模块级私有变量
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
