微前端请求隔离靠运行时上下文控制、请求拦截封装和主应用统一治理实现，而非改写fetch；需注入带标识/鉴权的fetch实例、禁用原生fetch调用、主应用网关路由管控。
Fetch 本身不提供网络请求隔离能力，微前端中的“请求隔离”不是靠改写 fetch 实现的，而是通过运行时上下文控制 + 请求拦截封装 + 主应用统一治理来达成。关键不是替换 fetch，而是确保子应用发出去的每个请求都携带可识别身份、受主应用策略管控，并且不污染全局或越权访问。
一、为什么不能直接“隔离 fetch”
JavaScript 全局 fetch 是浏览器原生 API，无法被子应用沙箱自动代理（不像 window 属性可通过 Proxy 拦截）。qiankun 等框架的 JS 沙箱只劫持全局对象属性读写，对 fetch 调用本身无感知。若子应用直接调用 fetch('/api/user')，该请求完全绕过主应用管控——既没带子应用标识，也无法被统一鉴权、限流或重定向。
二、实际可行的三层隔离策略
1. 封装子应用专属 fetch 实例（推荐）
主应用在挂载子应用前，向其注入一个预配置的 fetch 函数，而非暴露原生 fetch：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 自动添加子应用标识头：
X-SubApp-Name: react-order - 强制 baseURL 重写：所有相对路径自动拼接主应用配置的网关地址（如
https://api.example.com/order/） - 内置 token 注入：从主应用统一状态（如 auth store）读取 access_token，避免子应用自行读取 localStorage
- 错误统一拦截：401 自动触发主应用登出流程，不交由子应用处理
2. 禁用子应用直接调用原生 fetch（沙箱加固）
在 qiankun 的沙箱激活阶段，可临时覆盖子应用作用域下的全局 fetch：
- 快照沙箱中：挂载前保存原 fetch，卸载后恢复；运行期间抛出明确错误提示
- 代理沙箱中：用 Proxy 包裹 globalThis，对 fetch 属性设 getter 抛错，引导使用注入的 fetch
3. 主应用层网关路由与策略控制
所有子应用 fetch 请求必须经由主应用可控出口：
- 要求子应用 fetch 只能发往主应用声明的白名单域名（如
^https://api\.example\.com/(order|user)/） - 主应用在 fetch 封装层做动态鉴权：检查当前子应用是否有权限调用
/order/create - 敏感接口（如支付）强制走主应用中转，子应用只传参数，不直连后端
三、避坑要点
• 子应用若用 Axios，需确保其默认实例也被主应用重置（不能只封 fetch）
• 不要依赖 document.cookie 自动携带，跨子应用登录态应由主应用统一管理并透传 token
• 避免子应用内使用 fetch(..., { credentials: 'include' }) 直连其他子应用域，易引发 CORS 或会话混乱
• 对第三方 SDK（如 Sentry、埋点脚本）发起的 fetch，需在主应用侧统一 patch，否则逃逸隔离
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
