在团队内折腾过，实践下来发现：

之前考虑的各个子应用独立开发优势完全没有展现。因为在实际业务中，一个需求经常会出现跨子应用开发，多个子应用经常共用一些状态、数据、依赖。

反而页面性能、数据传输、依赖共享、心智负担都会成为隐性的技术债。

在最开始得到的一点点小好处，最终都会成为架构上的大麻烦。

@JefZ 使用 mono repo 的方式组织呢，这样模块联邦用起来会好一些。我们这边就是 mono repo 都在一个仓库（不过我们没有用模块联邦），团队按照模块开发自己部分，外部依赖升级统一在最外层统一完成，对于主依赖模块内部不允有不同的版本。

我一直用的 qiankun ，做的后台系统
讲讲微前端在我司的应用场景吧，先说说公司基建，我们前端有自己的工程化平台，每一个项目都能申请一个 appid ，或者多个项目分配一个 appid ，appid 的作用是分配一个二级域名，类似 xx.baidu.com/你的库名
二级域名又是区分 pre prd 等环境的，关于发布，上线，灰度都能在平台上操作，所以维护，迁移方面都不用关心，只需要修改下数据库内存储的子应用映射路径就可。
由于业务持续发展，产品迭代，不断细化，会有越来越多的内容更新，单个项目过于臃肿，于是根据功能将其划分多个子系统，基座应用主要用于承载，子系统脱离基座也能独立运行（ qiankun 自带）。
后台系统大部分是配置相关的，模块之间依赖很小，即使有数据依赖，接口层面也能解决。
...
总之，微前端 是 iframe 的替代方案，是巨石应用的拆分方案之一，关于通信方面，微服务通过 rpc 通信，前端也可以通过 tsrpc 类似通信调用，通过 store/redux 这种方案，反而增加了心智负担，后续维护的人怎么知道 xxx 方法是 a, b,c 还是基座呢？如果你能携带一些来源信息也可以，这就涉及通信方式的设计了

没看懂拆分的必要性。是因为项目体积太大，成员太多？

首先技术没有银弹
你们统一技术栈，没必要上微前端
Monorepo + pnpm ，感觉就可以了

微前端目前我用下来最大的优势就是：基本不用操心兄弟部门写的代码，连框架用啥都随他们(只要是主流框架)，他们的模块线上挂了完全不影响我们其他模块运行。实现到这种效果要求你的基座应用必须精雕细刻，文档也得详细。
微前端最适合的场景就是几个完全不搭边的团队，但开发出的产品需要放在一个系统里。