微前端中子应用的 Web Worker 必须由主应用统一创建、标识和管理，通过 appId 隔离上下文与通信，禁用 Shared Worker，确保线程安全与资源可控。
在微前端架构中，子应用的 Web Worker 不能简单地各自创建、各自管理——因为 Worker 本身不受沙箱控制，一旦多个子应用同时实例化同名或同逻辑的 Worker，极易引发线程冲突、状态污染、内存泄漏甚至主线程通信混乱。真正的隔离不是靠“不碰对方”，而是靠**统一管控 + 显式标识 + 通信契约**。
子应用 Worker 必须由主应用统一创建和分发
微前端沙箱（如 qiankun 的 ProxySandbox 或无界的 iframe 沙箱）对 Worker 构造函数完全透明：子应用调用 new Worker('./xxx.js') 仍会触发浏览器原生 Worker 实例，且该实例脱离沙箱生命周期管理。因此：
- 主应用应在初始化阶段按需创建一组专用 Worker（例如
dataWorker、imageWorker），并缓存其实例引用 - 子应用不直接 new Worker，而是通过主应用暴露的标准 API（如
getWorker('data')）获取已托管的 Worker 句柄 - 主应用负责 Worker 的销毁时机（如所有依赖子应用卸载后延迟释放），避免子应用误操作导致资源残留
通信消息必须携带 appId 和任务类型标识
多个子应用共用一个 Worker 时，Worker 内部无法天然区分消息来源。若不做隔离，A 子应用发来的解析请求可能被 B 子应用的回调处理函数接收，造成数据错乱：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 主线程发送消息时强制附加
{ appId: 'crm-subapp', type: 'PARSE_CSV', payload: ... } - Worker 收到后先校验
appId，再路由到对应子应用专属的处理函数或上下文 - 返回结果时也带上
appId和原始taskId（可由主线程生成 UUID），确保回调精准投递
避免共享状态，每个子应用使用独立上下文
Worker 全局作用域（self）是共享的，直接在顶层定义 let cache = new Map() 会导致所有子应用读写同一份内存：
- Worker 内部应按
appId维护隔离存储，例如const contexts = new Map() - 每次收到新
appId的首次消息时，自动初始化其专属上下文（含缓存、计数器、临时数组等） - 子应用卸载前，主应用主动通知 Worker 清理对应
appId的上下文：worker.postMessage({ type: 'CLEANUP', appId: 'hr-subapp' })
优先选用 Dedicated Worker，慎用 Shared Worker
Shared Worker 天然跨页面共享，与微前端“子应用隔离”原则根本冲突：
- 子应用 A 和 B 若都连接同一 Shared Worker，它们的
port事件监听器会互相干扰，port.start()调用可能覆盖彼此 - Shared Worker 的全局变量、定时器、未关闭的 WebSocket 都成为隐性耦合点
- 除非主应用严格封装一层代理层（拦截所有
port.postMessage并注入 appId），否则不建议子应用触碰 Shared Worker
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
