Flutter微前端架构中导航路由实现及耦合性问题咨询

问题1：是否应创建一个所有mf_feature_*及主应用都依赖的通用mf_navigation_router包？ #

可以创建，但并非强制选项。如果跨微前端导航逻辑复杂、需要统一全局路由规则和导航行为（比如统一转场动画、权限校验），通用路由包能帮你集中管理这些逻辑，避免重复代码。但如果各微前端耦合度极低、内部导航完全独立，也可以跳过通用包，让主应用直接承担路由协调角色。

问题2：使用通用路由包是否会导致mf_feature_*与mf_navigation_router包强耦合，如何规避？ #

确实存在强耦合风险，可通过以下方式规避：

• 抽象接口隔离：在通用路由包中仅定义抽象导航协议，比如创建AbstractNavigationService抽象类，只声明navigateTo()、pop()等核心方法，不包含具体路由实现。微前端仅依赖这个抽象接口，而非具体路由逻辑。
• 依赖注入解耦：由主应用或容器层提供具体的路由实现类，通过依赖注入工具（比如GetIt、Provider）将实现注入给微前端。微前端只调用接口方法，完全不关心底层用的是原生路由还是第三方路由库。
• 事件驱动导航：采用事件总线机制，微前端不需要依赖路由包，只需发送导航事件（比如NavigateToMf2Event），主应用监听事件后负责执行实际跳转操作，彻底切断微前端与路由包的直接依赖。

问题3：微前端架构中是否有更优的导航处理方式？ #

有几种更贴合微前端“独立、解耦”特性的方案：

• 主应用作为路由中枢：微前端内部使用私有路由处理自身页面跳转，跨微前端导航时向主应用发送跳转请求，由主应用负责切换对应的微前端容器或页面。这种方式让微前端保持高度独立，主应用仅承担协调角色。
• 路由契约化：提前与所有微前端约定路由名称（比如/mf_feature_1/detail、/mf_feature_2/list），但不需要依赖同一个路由包，而是通过字符串常量传递路由信息。主应用维护全局路由映射表，收到跳转请求时匹配对应微前端并完成导航。
• 结合Navigator 2.0/GoRouter实现懒加载：利用Flutter的Navigator 2.0或GoRouter的动态路由能力，主应用在需要跳转至某微前端时，才按需加载该微前端的路由组件，真正实现微前端的独立部署和按需加载。

内容的提问来源于stack exchange，提问作者Roy Krueger