标准答案
- 拆分边界应围绕业务域和团队边界，而不是按组件或页面数量机械拆分。
- 主应用通常负责整体路由、登录态、导航、权限和公共布局，子应用负责自身业务闭环。
- 通信方式可以使用 URL、事件、共享状态或约定 API，但要避免子应用互相强依赖。
- 样式隔离、依赖版本、React 单例、公共组件库和构建产物加载都需要提前约定。
- 微前端适合多团队独立发布和渐进迁移，不适合用来解决普通组件复用问题。
题目解析
这道题要能讲出收益和成本。微前端带来的不是单纯技术升级，而是工程组织方式变化。
React 项目接入时常见风险是多份 React、样式污染、路由冲突、认证状态不一致和子应用发布不可控。
如果只是一个团队维护的中小项目，模块化和组件库通常比微前端更简单。
代码示例
下面用路由边界表达主应用挂载一个子应用入口的思路。
TSX
function AppRoutes() {
return (
<Routes>
<Route path="/dashboard/*" element={<DashboardApp />} />
<Route path="/billing/*" element={<RemoteBillingApp />} />
</Routes>
)
}常见误区
- 没有组织和发布诉求也引入微前端，导致复杂度大于收益。
- 子应用之间直接调用内部方法，形成新的强耦合。
- 忽略样式隔离和依赖共享，线上出现样式污染或多 React 实例问题。