微前端并非 “一定要” 用 History 模式，而是「History 模式是微前端场景下的最优选择」，Hash 模式在微前端中会面临诸多兼容性、体验和技术实现的痛点，因此主流微前端方案（如 Wujie、Qiankun、MicroApp）都优先推荐 / 适配 History 模式。

下面从「微前端的核心诉求」「History 模式的适配优势」「Hash 模式的致命痛点」三个维度，超详细解释背后的原因：

一、先明确：微前端的核心路由诉求

微前端的核心是「主应用集成多个子应用，且子应用之间 / 主 - 子应用之间路由隔离、互不干扰」，具体对路由的要求：

1. 路由隔离：主应用能通过 URL 路径（如 /vue3-app/proOrder）精准识别要加载的子应用 + 子应用路由；
2. 历史记录统一：主 / 子应用的路由跳转，能整合到浏览器的同一套历史记录中，回退 / 前进按钮正常工作；
3. 无侵入性：子应用的路由逻辑无需大幅修改，就能接入主应用；
4. 参数传递友好：主应用能通过 URL 向子应用传递参数（如你之前的 dataInfo、token），解析无歧义。

---

二、History 模式适配微前端的核心优势

1. 路由隔离：基于「路径前缀」的天然隔离，无歧义

History 模式的 URL 是「纯路径结构」（如 http://domain.com/main-app/vue3-app/proOrder），主应用可通过「路径前缀」（如 /vue3-app）快速识别要加载的子应用，路由解析逻辑清晰：

• 主应用路由规则：/vue3-app/* → 加载 Vue3 子应用；/react-app/* → 加载 React 子应用；
• 子应用路由规则：子应用内部只处理 /proOrder、/home 等相对路径，主应用通过「路由拦截」将 /vue3-app/proOrder 转发给子应用解析为 /proOrder；

这种基于「路径前缀」的隔离方式，是主流微前端框架（如 Wujie、Qiankun）的核心实现逻辑，而 History 模式的 URL 结构完美适配这种逻辑。

2. 历史记录统一：浏览器回退 / 前进正常

微前端中，主应用和子应用的路由跳转都基于 HTML5 History API：

• 主应用加载子应用时，调用 history.pushState 修改 URL 为 /vue3-app/proOrder；
• 子应用内部跳转时，框架会拦截子应用的 pushState 调用，拼接前缀后更新全局 URL；
• 所有跳转都会写入浏览器的「全局历史记录」，点击回退按钮时，能从 /vue3-app/proOrder 正常回退到主应用的 /home，体验和单应用一致。

3. 与微前端框架的路由拦截逻辑天然兼容

主流微前端框架（如 Wujie）的核心能力之一是「路由沙箱」—— 拦截子应用的 history.pushState、popstate 等 API，实现主 - 子应用的路由隔离：

• History 模式下，子应用的路由操作都是基于标准的 History API，框架只需拦截这些 API，就能实现「路由前缀拼接」「历史记录管理」；
• 框架无需对 URL 做复杂的字符串解析（如拆分 #），实现成本低、兼容性好。

4. URL 无特殊字符，参数传递 / 解析无歧义

微前端中主应用常通过 URL 向子应用传参（如你之前的 dataInfo、status），History 模式的 URL 是：http://domain.com/vue3-app/proOrder?dataInfo={...}&status=true

• 参数部分（? 后）是标准的 URL Query 格式，主 / 子应用解析无歧义；
• 第三方工具（如 Nginx、监控系统）也能正常识别 URL 结构，便于调试和运维。

---

三、Hash 模式在微前端中的致命痛点

如果强行在微前端中用 Hash 模式，会面临以下无法规避的问题：

1. 路由隔离难：Hash 嵌套导致解析混乱

主应用 Hash 模式（#/main-home）+ 子应用 Hash 模式（#/proOrder），最终 URL 会变成：http://domain.com/#/main-home#/proOrder

• 这种「Hash 嵌套」的 URL 结构，主应用无法通过简单的前缀识别子应用；
• 微前端框架需要拆分 # 后的字符串，解析成本高，且易出现解析错误（比如子应用 URL 中包含 # 本身）。

2. 历史记录混乱：回退 / 前进失效

Hash 模式的路由变化依赖 hashchange 事件，而：

• 子应用修改自身 Hash 时，不会触发主应用的 hashchange 事件，浏览器的历史记录中只会记录「主应用的 Hash 变化」；
• 点击回退按钮时，可能直接从子应用跳回主应用的初始页面，而非子应用的上一个路由（比如从 /proOrder 回退到 /home 失效）。

3. 框架适配成本高：需自定义 Hash 解析逻辑

主流微前端框架对 Hash 模式的支持极弱，原因是：

• 框架需要自定义「Hash 拆分规则」（比如约定用 #! 分隔主 / 子应用 Hash），增加接入成本；
• 不同子应用可能用不同的 Hash 前缀，导致规则不统一，易出现冲突。

4. 体验 / 兼容性问题：URL 冗余、第三方库不兼容

• URL 包含多个 #，用户体验极差（如 http://domain.com/#/vue3-app#/proOrder?status=true）；
• 部分第三方库（如地图、支付插件）会解析 URL 中的 # 作为锚点，导致和路由 Hash 冲突，功能异常。

---

四、特殊情况：微前端中也能用 Hash 模式的场景

并非所有微前端都 “完全不能用” Hash 模式，仅适用于「极简场景」：

1. 主应用是唯一的 “路由入口”，子应用无独立路由（子应用只是单个页面组件）；
2. 子应用数量极少（1-2 个），且主 / 子应用约定好 Hash 解析规则（如主应用 Hash 前缀 #main，子应用 #sub）；
3. 纯内部测试 / 演示环境，无需考虑体验和兼容性。

即使是这种场景，也需要额外配置：

• 主应用：自定义 hashchange 事件监听，拆分 Hash 字符串识别子应用；
• 子应用：禁用自身的路由历史记录监听，由主应用统一管理。

---

总结（核心关键点）

1. 不是 “必须”，而是 “最优选择”：微前端并非强制用 History 模式，但 Hash 模式会导致路由隔离、历史记录、解析逻辑等一系列问题；
2. History 模式的核心优势：路径前缀隔离清晰、历史记录统一、框架适配友好、URL 无歧义，完美匹配微前端的路由诉求；
3. Hash 模式的适用场景：仅极简微前端（无子应用路由、少量子应用），且需额外适配，不推荐生产环境使用；
4. 结合你的场景（Wujie + Vue2 主应用 + Vue3 子应用）：用 History 模式是最低成本、最稳定的选择，也是 Wujie 官方推荐的方式。

相关 Vue Router 中 Hash 模式和 History 模式 的核心区别、底层原理、使用场景及部署注意事项 可查看另一篇博客Hash 模式和 History 模式 的核心区别、底层原理、使用场景及部署注意事项