Hi! 这里是 JustHappy，同样都是页面，SPA和MPA有什么不同呢？我们平时改如何选择呢？我们来聊聊吧
基本的页面结构形态
在当前的 Web 前端领域中，只存在两种最基本的页面结构形态，就是 SPA（Single Page Application） 和 MPA（Multi Page Application） 。在此基础上，我们可以构建诸如 Hybrid SPA/MPA 、PWA（Progressive Web App） 、微前端 等多种衍生页面形态。那么这两块 "砖" 各有什么特点呢？
1️⃣ MPA（Multi Page Application）多页应用
- 每次页面跳转都向服务器请求一个新的 HTML 文件，浏览器会刷新页面。
- 后端负责渲染页面（传统的服务端渲染，SSR）。
✅ 优点
- SEO 友好，搜索引擎可以直接抓取服务端输出的完整 HTML。
- 首屏渲染快，因为浏览器一拿到 HTML 就能立刻显示内容，不依赖前端 JS 渲染。
❌ 缺点
- 页面跳转会刷新整个页面，用户体验相对较差，切换不够丝滑。
- 页面之间状态和数据不共享，每次都要重新向服务器拉数据或依赖 Cookie、Session 等。
- 需要开发者在前后端模板渲染、路由、状态管理等方面投入更多人力。
2️⃣ SPA（Single Page Application）单页应用
- 整个网站只存在一个 HTML 文件，页面跳转、路由切换都由前端 JS 在浏览器内处理。
- 首次访问时，需要下载体积较大的 JS（包含路由、组件、状态管理等），后续切换仅发送 API 请求获取数据。
SPA路由方案
对于 SPA 来说，页面切换完全依赖前端路由，而不是向服务器请求新的 HTML。这就需要一种机制，让浏览器在 URL 变化时，不会刷新整个页面，而是交由前端 JS 来控制视图更新。
主要两种路由模式：Hash 模式 和 History 模式。
🔗 Hash 模式
- URL 格式：
http://example.com/#/home - 原理：利用
#（hash）后面的字符串不会被浏览器发送到服务器，浏览器提供了hashchange事件，前端只需监听这个事件即可实现路由切换。 - 优点：实现简单，兼容性好，对后端无要求，无需服务器额外配置。
- 缺点：URL 带
#，不够美观，不符合传统 URL 语义，对 SEO 几乎无效。
📜 History 模式
- URL 格式：
http://example.com/home - 原理：基于 HTML5 的
History API，通过pushState和replaceState改变浏览器地址栏中的路径，同时不触发页面刷新；前端监听popstate事件处理回退、前进等行为。 - 优点：URL 干净、语义化，和传统多页 URL 一致，更易做 SEO（需结合 SSR）。
- 缺点：刷新或直接访问某个子路由时，浏览器会向服务器请求对应路径，若后端未正确配置（如未将所有请求都指向入口
index.html），就会返回 404。
| Hash 模式 | History 模式 | |
|---|---|---|
| URL 表现 | 带 # |
干净、真实路径 |
| 浏览器支持 | 兼容性极好 | 需要支持 HTML5 |
| SEO | 基本无效 | 更友好（需 SSR） |
| 服务器配置 | 无需配置 | 需要配置重定向 |
| 实现复杂度 | 简单 | 稍复杂 |
✅ 优点
- 页面切换无需刷新整个页面，交互体验流畅，操作丝滑，前后端可以完全分离。
- 前端可以管理更多交互逻辑，做出更复杂的应用形态（例如富交互后台管理系统）。
- 可以在浏览器里做离线缓存（PWA）、局部更新、骨架屏等，用户感知更优。
❌ 缺点
- 首屏加载较慢，往往要先加载一整个应用的 JS 框架、路由、组件等，用户可能看到空白页面或 Loading。
- 对 SEO 不友好，搜索引擎需要执行 JS 才能抓取内容（需配 SSR 或预渲染）。
- 对浏览器兼容性要求较高，需谨慎处理 History 路由带来的服务端 404 等问题。
⚡ 技术演进
在 Web 开发的上古时代，几乎所有页面都是最传统的 MPA，且是前后端紧密耦合的形态，典型的技术栈就是 JSP、PHP、ASP 等动态模板引擎。那时候大家普遍采用 MVC 架构，数据渲染、路由分发都在服务端完成。
受限于当时的网络带宽和终端性能，用户体验往往是"点一下 → 白屏 → 重新加载 → 再点一下 → 再白屏"。那时前端工程化的概念几乎没有，更谈不上模块化、组件化，甚至 Ajax 都未普及。
随着浏览器能力的提升，Ajax 的普及，MVVM 框架（如 Angular、Vue、React）的出现，让单页应用（SPA）在交互型、逻辑复杂型的场景中逐渐占据主流，前后端开始分离，前端有了路由、状态管理、组件化等完善的生态，用户体验也迎来了质的飞跃。
但这并不意味着 SPA 就"取代"了 MPA。相反，SPA 和 MPA 是两块不同的"砖"，各自有适用的场景：
- 需要良好 SEO、首屏加载极快的内容型网站（如电商、门户）更适合传统的服务端渲染或混合 MPA。
- 对交互体验要求高、需要复杂状态管理的后台管理、H5 应用，更适合使用 SPA。
在实际开发中，我们更需要有清醒的技术视角：不是一味追逐潮流，而是结合业务形态、团队能力、用户需求，选择最合适的架构形态，或是灵活地把 SPA 和 MPA 拼在一起，用 Hybrid、SSR、PWA、微前端等技术栈，搭出一块块最适合自己业务的"砖墙"。
🚦不只于单一的页面形态
在现代前端中，纯 MPA 已经很少见，更多的是：
- 纯 SPA：后台管理系统、Web App。
- SPA + SSR：像 Next.js（React）/ Nuxt（Vue）这样支持服务器端渲染的混合模式，首屏快、SEO 友好。
- PWA：在 SPA 的基础上，支持离线缓存、安装到桌面。
- 微前端：在大型企业级项目里，把多个 SPA 按业务拆成多个可独立部署的"小前端"，拼接成一个"壳"。