Umi.js微前端部署实践：解决子应用路由直接渲染问题

问题背景

在使用Umi.js框架结合qiankun微前端架构时，开发者在部署环境中遇到了一个典型的路由控制问题：当刷新包含子应用路由的页面时，浏览器直接进入了子应用的部署项目，而不是通过主应用正常加载子应用。

核心问题分析

这种情况通常发生在Nginx配置不当的情况下，导致浏览器请求直接命中了子应用的路由规则，而非通过主应用来加载子应用。具体表现为：

1. 主应用和子应用都配置了独立的Nginx路由规则
2. 刷新页面时，Nginx直接将请求路由到子应用的静态资源
3. 子应用独立渲染，脱离了主应用的控制

解决方案

正确的Nginx配置原则

1. 主应用配置：应作为SPA(单页应用)配置，处理所有路由请求
2. 子应用配置：仅作为静态资源服务，不处理路由逻辑

具体配置示例

主应用Nginx配置应包含：

location ^~ /tenant/org1101/nntl/client/poss/hto1/ {
    try_files $uri $uri/ /tenant/org1101/plat/web/hto1/index.html;
}

子应用Nginx配置应简化为：

location /tenant/org1101/poss/web/section/ {
    alias /path/to/subapp/static/files;
}

Umi.js配置要点

1. 主应用的qiankun配置中，确保activeRule正确设置子应用激活路径
2. 子应用的历史路由base需要与主应用分配的路由前缀一致
3. 避免主应用和子应用的路由规则在Nginx层面产生冲突

深入理解

这种部署问题的本质在于微前端架构的路由控制权分配。在理想情况下：

• 主应用应完全控制路由解析
• 子应用只负责在指定路由下渲染自身内容
• Nginx只应将请求引导至主应用入口

当刷新页面时，正确的流程应该是：

1. 浏览器发送请求到Nginx
2. Nginx返回主应用的index.html
3. 主应用初始化后，根据URL加载对应的子应用
4. 子应用在主应用的上下文中渲染

最佳实践建议

1. 统一路由前缀管理，确保主应用和子应用使用一致的路由前缀
2. 简化子应用的Nginx配置，仅作为静态资源服务
3. 在生产环境部署前，充分测试路由跳转和刷新行为
4. 考虑使用统一的部署路径规划，避免路径混乱

通过以上配置和原则，可以有效解决Umi.js微前端架构中的路由控制问题，确保应用在刷新时仍能保持正确的加载流程。