如何使用Master-Worker模型精细控制微前端沙箱内全局网关的安全隔离阈值-Nginx-PHP中文网

master-worker模型不用于控制“全局网关安全隔离阈值”，因网关属后端层，前端需由主应用统一管控子应用请求，通过标准api注入、策略校验与worker辅助分流，并在沙箱中设“请求守门员”而非模拟网关。

如何使用master-worker模型精细控制微前端沙箱内全局网关的安全隔离阈值

Master-Worker 模型在微前端中不直接用于控制“全局网关的安全隔离阈值”，因为该模型本身不是微前端沙箱的标准组件，也不存在所谓“全局网关”这一原生概念——网关（如 API 网关）属于后端流量层，运行在服务端，与前端沙箱无直接耦合。所谓“沙箱内全局网关”，实际是开发中对前端统一请求代理层（如封装的 axios 实例、fetch 拦截器、或透传至后端网关的请求中间件）的误称。真正需要精细控制的是：子应用发出的网络请求如何被主应用统一约束、审计与路由分发，而非在沙箱里“部署一个网关”。

主应用作为 Master 统一接管请求入口

子应用不应直接调用 fetch 或 axios，而应通过主应用暴露的标准通信接口发起请求。主应用作为 Master，负责所有出站请求的策略执行：

所有子应用调用 microApp.request({ url: '/api/user' })，该方法由主应用注入并托管
主应用在内部校验 appId、接口白名单、请求头签名、超时阈值，并决定是否转发、降级或拦截
真实请求由主应用使用原生 fetch 或封装的 client 发起，子应用无法绕过该管控链路

Worker 层做协议解析与策略分流

若需更高性能或解耦逻辑，可将请求预处理下沉到独立 Worker（非 Shared Worker），作为策略执行单元：

PigX UI 前端开发

PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。

下载

主应用创建 DedicatedWorker（每个子应用独享或按场景复用），加载策略脚本
Worker 接收结构化请求指令（含 appId、path、method、metadata），执行路径匹配、权限码校验、熔断计数等轻量逻辑
Worker 不发起真实网络请求，仅返回“允许/拒绝/重定向到备用地址”决策，主应用再执行最终 fetch
避免在 Worker 中操作 DOM 或依赖 window，确保纯计算、无副作用

沙箱内不设“网关”，只设“请求守门员”

Proxy 沙箱（如 qiankun 的 ProxySandbox）不也不应尝试劫持 window.fetch 或重写 XMLHttpRequest.prototype.open 来模拟网关——这既破坏沙箱最小侵入原则，又易被 eval、with 或动态 import 绕过。正确做法是：

在 fakeWindow 上定义只读属性 fetch，抛出明确错误，强制子应用使用主应用提供的 request API
利用 setter 对关键配置项（如 window.API_BASE_URL）做审计：赋值时记录来源 appId、校验域名前缀、拒绝非法协议（如 file://）
将子应用生命周期与请求会话绑定：子应用 unload 时，自动清理其关联的请求队列与 pending promise 引用