微前端中WebSocket应由主应用统一管理，按业务域而非子应用建连，通过中心化SDK实现复用、自动清理与类型化分发，并桥接沙箱状态同步，前后端协同防重复连接。
在微前端架构中管理多个 WebSocket 连接，关键不是“能不能连”，而是“谁连、何时连、连完归谁管”。直接在各子应用里 new WebSocket() 会导致连接冲突、状态覆盖、内存泄漏和卸载残留——尤其在乾坤（Qiankun）这类基于沙箱的框架下，全局变量隔离了，但 WebSocket 实例是跨沙箱存活的真实对象，必须主动管控。
按业务域划分连接，不按子应用划分
子应用只是运行时容器，不是通信边界。比如一个电商系统里，“订单状态推送”“客服聊天”“库存预警”应各自独立建连，哪怕它们同属一个子应用；反之，同一子应用内若同时打开两个客服窗口，也应复用同一个聊天连接，而非为每个窗口新建连接。
- 连接粒度对齐业务语义：每个连接对应一个明确的后端服务通道（如
wss://api.example.com/order、wss://api.example.com/chat） - 禁止“子应用 A 专属 WebSocket”这种模糊绑定，避免后续功能迁移或复用时重构成本高
- 主应用可统一注册连接配置表，子应用通过唯一标识（如
channelId: 'order-status'）申请使用，而非自行构造 URL
用中心化服务封装连接生命周期
所有 WebSocket 实例必须由主应用提供统一 SDK 管理，子应用只调用接口，不接触原生实例。推荐实现一个 WebSocketService 类，内部基于 WeakMap 绑定连接与业务上下文，并自动处理重连、心跳、消息分发。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 连接复用：相同 URL + 相同配置的请求，返回已有实例，避免重复建连
- 自动清理：子应用
unmount时，SDK 检查该应用是否还持有某连接的监听器，若无则触发close（非立即关闭，而是进入优雅退出队列） - 类型化消息分发：支持
on('order-updated', handler)，内部用 Map 存储 type → handler 映射，不同子应用可监听同一事件类型而不互相干扰
沙箱环境下的状态同步与通信隔离
乾坤的代理沙箱会拦截 window 上的属性读写，但 WebSocket 的 onmessage 回调是在全局上下文中执行的——若子应用在沙箱内修改了自身闭包中的状态，回调里访问不到最新值。需显式桥接。
立即学习“Java免费学习笔记（深入）”；
- 消息到达后，不直接更新子应用内部 state，而是通过
props或initGlobalState向子应用广播 payload - 子应用通过
onGlobalStateChange订阅变更，再决定是否触发本地渲染，确保状态流可控 - 避免在
onmessage中直接调用子应用暴露的全局函数（如window.appA.handleMsg），因其可能已被沙箱代理或卸载
连接标识与服务端协同防冲突
当用户在多个标签页打开同一微前端，或子应用被多次挂载（如路由反复进出），服务端可能收到多个重复连接。需前后端配合识别并踢旧保新。
- 前端每次 connect 前生成仅当前标签页有效的
clientId（存于sessionStorage），拼入 URL 查询参数传给服务端 - 服务端用
ConcurrentHashMap<clientId, Session>维护映射，新连接到来时先 close 旧 session - 主应用在全局监听
beforeunload，主动发送{ type: 'disconnect', clientId }通知服务端释放资源（非强制，仅优化）
