钉子的生活日记
文章目录

无界 Wujie 微前端学习笔记

适合目标：理解无界的核心设计、隔离机制、接入方式和复杂系统治理方法。
学习定位：这一份偏“兼容性、隔离性、工程稳定性”。
学习原则：先理解它为什么常被拿来替代传统 iframe 方案，再进入具体落地。

目录

  1. 无界是什么
  2. 为什么无界值得学
  3. 核心设计思路
  4. 接入流程
  5. 路由与通信
  6. 隔离与稳定性
  7. 进阶治理
  8. 常见坑位
  9. 选型建议
  10. 面试考点
  11. 一页总结

1. 无界是什么

无界 Wujie 是一个强调隔离能力、兼容性和低改造成本的微前端方案。
它常被很多团队看中的原因是：

  1. 对老系统适配友好
  2. 隔离性强
  3. 兼容多技术栈
  4. 在中后台平台场景里比较稳

从学习角度，可以把它理解成：

一个把 iframe 隔离优势和更自然应用体验结合起来的微前端方案。

2. 为什么无界值得学

2.1 它解决了传统 iframe 的哪些痛点

传统 iframe 虽然隔离强，但体验常常不好：

  1. 路由联动麻烦
  2. 通信麻烦
  3. 应用切换不够自然
  4. 开发心智负担大

无界想做的是：

  1. 尽量保留隔离优势
  2. 改善路由与通信体验
  3. 降低主子应用整合成本

2.2 适合的真实场景

  1. 多业务中后台平台
  2. 历史子系统较多
  3. 技术栈不统一
  4. 团队更看重稳定与隔离

3. 核心设计思路

3.1 强隔离思维

无界的一大亮点是隔离能力。
你可以重点理解这几类隔离：

  1. DOM 隔离
  2. JS 运行隔离
  3. 样式隔离
  4. 路由状态隔离

3.2 容器化挂载

主应用提供容器，子应用在容器内运行。
容器不仅负责显示，还负责：

  1. 加载入口
  2. 跟踪生命周期
  3. 接入通信能力
  4. 管理缓存与销毁

3.3 路由同步

无界通常会提供比较友好的路由同步能力，让主子应用切换更自然。
你要理解的是：

  1. 主应用不应该管太深的子路由
  2. 子应用需要明确自己的 base
  3. 刷新和深链访问要验证

4. 接入流程

4.1 主应用做什么

主应用通常需要：

  1. 初始化无界框架
  2. 注册子应用
  3. 配置路由前缀
  4. 提供公共能力

接入心智可以概括为：

主应用负责管边界和资源，子应用负责管自己的业务。

4.2 子应用做什么

子应用需要适配：

  1. 基础路由
  2. 挂载容器
  3. 静态资源路径
  4. 生命周期配合

4.3 接入时优先验证的点

  1. 首页能否正常加载
  2. 主应用跳转到子应用是否稳定
  3. 子应用内部跳转是否正常
  4. 刷新是否会 404
  5. 返回主应用后状态是否正确

5. 路由与通信

5.1 路由策略建议

推荐做法：

  1. 一级路由由主应用控制
  2. 子应用内部路由自己管理
  3. 路由前缀提前约定
  4. 避免 hash、history 混用失控

5.2 通信建议

无界虽然能提供通信能力，但工程上仍建议克制：

  1. 用户信息共享
  2. 权限与主题共享
  3. 事件通知共享
  4. 大型业务状态不要共享

5.3 共享状态的正确姿势

共享的是“上下文”，不是“全部业务状态”。

适合共享：

  1. 当前租户
  2. 登录用户
  3. 主题
  4. 语言
  5. 顶部筛选上下文

6. 隔离与稳定性

6.1 为什么很多团队看重无界

因为微前端最让人头疼的其实不是“能不能跑起来”，而是：

能不能长期稳定运行。

无界的价值很多时候体现在：

  1. 减少主子应用互相污染
  2. 兼容历史系统
  3. 减少复杂页面切换时的副作用

6.2 样式隔离治理

你仍然不能完全依赖框架兜底。
工程上建议：

  1. 子应用样式命名空间化
  2. 组件库主题变量清晰
  3. 避免改全局基础标签
  4. 对第三方库样式做边界审查

6.3 内存与副作用治理

微前端常见隐患：

  1. 页面卸载后监听没清理
  2. 定时器没释放
  3. 缓存页面越来越多
  4. 子应用挂载多次导致重复初始化

治理方式：

  1. 统一写生命周期清理逻辑
  2. 接入性能和内存监控
  3. 对 keep-alive 设置上限

7. 进阶治理

7.1 应用注册中心

建议维护一份统一应用元数据：

  1. 应用名称
  2. 路由前缀
  3. 访问地址
  4. 权限要求
  5. 预加载策略
  6. 监控配置

7.2 菜单与权限

推荐：

  1. 主应用控制菜单权限
  2. 子应用控制页面内部按钮权限
  3. 不要每个子应用都重复做完整登录逻辑

7.3 灰度发布

微前端真正落地后，灰度和回滚非常关键：

  1. 子应用单独灰度
  2. 子应用单独回滚
  3. 主应用只负责路由编排

7.4 监控体系

至少要覆盖：

  1. 子应用加载成功率
  2. 子应用切换耗时
  3. 静态资源失败率
  4. 运行时错误
  5. 白屏率

8. 常见坑位

8.1 路由刷新丢失

通常看：

  1. 网关配置
  2. 路由 base
  3. 主子路径映射

8.2 第三方 UI 库样式污染

建议：

  1. 限制全局样式库
  2. 对通用主题做统一封装
  3. 子应用自带 reset 要审查

8.3 主子应用重复登录

建议：

  1. 登录统一放主应用
  2. 子应用只接收 token 或 session 上下文
  3. 接口鉴权由网关统一处理

8.4 调试困难

改进建议：

  1. 本地联调端口规范化
  2. 子应用启动脚本统一
  3. 接入日志统一上报

9. 选型建议

9.1 什么时候优先考虑无界

  1. 老系统多
  2. 技术栈杂
  3. 更看重隔离与稳定性
  4. 平台型系统较复杂

9.2 什么时候不一定优先无界

  1. 你其实只是想做模块共享
  2. 团队工程体系非常统一
  3. 更偏 React 模块联邦场景

10. 面试考点

10.1 无界和 iframe 有什么关系

答题思路：

无界吸收了 iframe 隔离强的优势，但不是停留在传统 iframe 的粗糙集成层面，而是进一步处理了路由、通信、生命周期和容器化体验问题。

10.2 为什么无界在复杂中后台里常被看好

  1. 隔离强
  2. 老系统兼容友好
  3. 运行稳定性更容易治理

10.3 你们如何做主子应用职责划分

推荐回答：

主应用负责布局、鉴权、菜单、一级路由和公共能力；子应用负责业务页面、内部路由和领域逻辑。

10.4 微前端里最难治理的是什么

  1. 边界
  2. 通信
  3. 样式污染
  4. 生命周期副作用
  5. 发布和监控

11. 一页总结

11.1 无界的关键词

隔离、兼容、稳定、平台型中后台。

11.2 适合谁

  1. 历史包袱重的团队
  2. 多子系统并存的团队
  3. 更关心稳定性而不是最细粒度模块共享的团队

11.3 记忆口诀

把隔离做好，把边界定清，把主应用做薄。