什么是SPA,SPA与MAP区别
什么是SPA,SPA与MAP区别
文章目录
- 什么是SPA,SPA与MAP区别
- 一、什么是SPA
- 二、SPA和MPA的区别
- 一、单页应用与多页应用的区别
- **二、SPA 的优缺点对比**
- 三、WPA的优缺点
- **三、SPA 实现关键技术**
- `hash` 模式
- 模式history模式
- 四、SPA 的适用场景与原因
- **适用场景:**
- **适用原因:**
- 五、题外话:如何给SPA做SEO
一、什么是SPA
SPA(single-page application),翻译过来就是单页应用SPA是一种网络应用程序或网站的模型,它通过动态重写当前页面来与用户交互,这种方法避免了页面之间切换打断用户体验在单页应用中,所有必要的代码(HTML、JavaScript和CSS)都通过单个页面的加载而检索,或者根据需要(通常是为响应用户操作)动态装载适当的资源并添加到页面页面在任何时间点都不会重新加载,也不会将控制转移到其他页面举个例子来讲就是一个杯子,早上装的牛奶,中午装的是开水,晚上装的是茶,我们发现,变的始终是杯子里的内容,而杯子始终是那个杯子。
我们熟知的JS框架如react,vue,angular,ember都属于SPA
核心特点:
- 单 HTML 文件:整个应用只有一个
index.html,通过 JavaScript 动态更新 DOM - 前端路由:通过
history API或hash实现 URL 变化与视图的映射(如/home→ 首页组件) - 异步数据加载:通过 AJAX/Fetch 与后端 API 交互,按需获取数据
- 组件化架构:将界面拆分为独立组件(如 React/Vue 组件)
二、SPA和MPA的区别
上面大家已经对单页面有所了解了,下面来讲讲多页应用MPA(MultiPage-page application),翻译过来就是多页应用在MPA中,每个页面都是一个主页面,都是独立的当我们在访问另一个页面的时候,都需要重新加载html、css、js文件,公共文件则根据需求按需加载
一、单页应用与多页应用的区别
| 单页面应用(SPA) | 多页面应用(MPA) | |
|---|---|---|
| 组成 | 一个主页面和多个页面片段 | 多个主页面 |
| 刷新方式 | 局部刷新 | 整页刷新 |
| url模式 | 哈希模式 | 历史模式 |
| SEO搜索引擎优化 | 难实现,可使用SSR方式改善 | 容易实现 |
| 数据传递 | 容易 | 通过url、cookie、localStorage等传递 |
| 页面切换 | 速度快,用户体验良好 | 切换加载资源,速度慢,用户体验差 |
| 维护成本 | 相对容易 | 相对复杂 |
二、SPA 的优缺点对比
| 优点 | 缺点 |
|---|---|
| 用户体验流畅,页面切换无需重新加载,减少等待时间,过渡动画和动态交互自然 | **SEO 优化困难**,传统 SPA 是前端渲染,初始 HTML 中无具体内容,搜索引擎爬虫难以抓取数据 |
| 前后端分离清晰,前端专注 UI / 交互,后端专注 API 接口,开发效率高 | 首次加载时间长,需要加载完整的前端框架、JS/CSS 资源和初始数据 |
| 减轻服务器压力,服务器只需返回数据,降低带宽消耗和服务器渲染压力 | 路由与状态管理复杂,需手动处理路由逻辑,复杂应用可能需要额外的状态管理库 |
| 代码维护方便,前端逻辑集中在单一页面,组件化开发便于复用和维护 | 浏览器兼容性与前进 / 后退按钮问题,依赖浏览器的 History API 或哈希,部分旧浏览器支持不佳,页面状态在刷新或后退时可能丢失 |
三、WPA的优缺点
| 维度 | 优点 | 缺点 |
|---|---|---|
| SEO 支持 | 天然友好,内容直接包含在服务器返回的 HTML 中,爬虫可直接抓取,无需额外优化。 | 无特殊劣势(本身优势),但复杂交互场景需依赖后端渲染,前端动态内容少。 |
| 首屏加载速度 | 简单页面场景下,服务器直接返回完整 HTML,首屏加载快(尤其静态内容)。 | 复杂页面需加载大量重复资源(如公共 CSS/JS),整体加载速度可能慢于 SPA。 |
| 用户体验 | 无前端路由和复杂逻辑,传统浏览器操作(前进 / 后退)体验稳定,无状态丢失风险。 | 页面跳转时整页刷新,出现 “白屏” 或闪烁,交互流畅度差(尤其频繁导航时)。 |
| 资源加载 | 每个页面独立加载资源,公共资源(如导航栏)需重复加载,浪费带宽和性能。 | 动态内容需整页刷新,无法局部更新(如表格筛选、表单提交后需重新加载)。 |
| 开发成本 | 技术栈简单,依赖传统后端模板引擎(如 EJS、PHP),学习成本低,适合快速开发。 | 页面共享部分(如头部、页脚)需重复编写或依赖后端模板继承,维护成本高。 |
| 前后端耦合 | 强耦合,页面逻辑和渲染依赖后端,前端仅作为展示层,难以独立开发和部署。 | 不利于前后端分离,前端无法复用逻辑,后端需处理页面渲染细节(如 HTML 结构)。 |
| 兼容性 | 依赖传统浏览器机制,对老旧浏览器(如 IE8)兼容性更好,无需现代 JS 特性。 | 复杂交互需额外兼容处理(如 AJAX 兼容性),但整体兼容性仍优于 SPA 的部分场景。 |
| 复杂交互支持 | 弱,动态内容需整页刷新或依赖简单 AJAX,难以实现单页内的高效交互(如路由过渡、状态管理)。 | 强依赖前端框架(如 React/Vue),需手动处理路由和状态,开发复杂度高。 |
| 代码维护 | 页面独立,资源作用域隔离,减少全局变量污染和样式冲突风险。 | 重复代码多(如公共组件),修改时需同步多个页面,一致性难以保证。 |
| 适用场景 | 静态 / 内容型网站(企业官网、博客)、兼容性要求高的项目、快速原型开发。 | 交互密集型应用(Web 邮箱、仪表盘)、前后端分离项目、移动端 Web 应用。 |
三、SPA 实现关键技术
-
前端路由
-
实现方式:
// React Router 示例 import { BrowserRouter, Route } from 'react-router-dom'; <BrowserRouter><Route path="/home" component={Home} /><Route path="/about" component={About} /> </BrowserRouter> -
原理:通过监听
popstate(history 模式)或hashchange(hash 模式)事件
-
-
数据交互
-
使用
axios或fetch进行 API 请求 -
示例:
async function loadData() {const res = await fetch('/api/users');const data = await res.json();setUsers(data); // 更新状态 }
-
-
状态管理
- 复杂应用使用 Redux/Vuex
- 简单场景可用 Context API(React)或 Provide/Inject(Vue)
hash 模式
核心通过监听url中的hash来进行路由跳转
// 定义 Router
class Router { constructor () { this.routes = {}; // 存放路由path及callback this.currentUrl = ''; // 监听路由change调用相对应的路由回调 window.addEventListener('load', this.refresh, false); window.addEventListener('hashchange', this.refresh, false); } route(path, callback){ this.routes[path] = callback; } push(path) { this.routes[path] && this.routes[path]() }
} // 使用 router
window.miniRouter = new Router();
miniRouter.route('/', () => console.log('page1'))
miniRouter.route('/page2', () => console.log('page2')) miniRouter.push('/') // page1
miniRouter.push('/page2') // page2
模式history模式
history 模式核心借用 HTML5 history api,api 提供了丰富的 router 相关属性先了解一个几个相关的api
history.pushState浏览器历史纪录添加记录history.replaceState修改浏览器历史纪录中当前纪录history.popState当history发生变化时触发
// 定义 Router
class Router { constructor () { this.routes = {}; this.listerPopState() } init(path) { history.replaceState({path: path}, null, path); this.routes[path] && this.routes[path](); } route(path, callback){ this.routes[path] = callback; } push(path) { history.pushState({path: path}, null, path); this.routes[path] && this.routes[path](); } listerPopState () { window.addEventListener('popstate' , e => { const path = e.state && e.state.path; this.routers[path] && this.routers[path]() }) }
} // 使用 Router window.miniRouter = new Router();
miniRouter.route('/', ()=> console.log('page1'))
miniRouter.route('/page2', ()=> console.log('page2')) // 跳转
miniRouter.push('/page2') // page2
四、SPA 的适用场景与原因
适用场景:
- 交互密集型应用
- 如 Web 版邮箱(Gmail)、在线文档(Google Docs)、仪表盘(数据可视化平台),需要频繁的局部更新和流畅交互。
- 移动端 Web 应用
- 移动设备屏幕小,网络环境复杂,SPA 的单页面加载和局部更新能减少流量消耗,提升体验(可进一步封装为 PWA)。
- 前后端分离项目
- 适合团队分工明确,前端专注 UI / 交互,后端专注数据处理和 API 开发。
- 非内容型网站
- 如管理后台、用户中心(无需强 SEO),更注重用户操作体验而非搜索引擎收录。
适用原因:
- 用户体验优先
- 现代用户对应用响应速度要求高,SPA 避免了整页刷新的卡顿感,接近原生应用体验。
- 技术生态成熟
- 主流框架(React/Vue/Angular)均内置 SPA 支持,配套工具链(如 Webpack/Vite)解决了打包、优化等问题。
- 前后端解耦
- 后端提供标准化 API,前端可独立开发、测试和部署,支持多端复用(如后续扩展为移动端 App)。
- 适应现代 Web 趋势
- 配合 PWA(渐进式 Web 应用)可实现离线缓存、桌面图标等功能,进一步缩小与原生应用的差距。
五、题外话:如何给SPA做SEO
下面给出基于Vue的SPA如何实现SEO的三种方式
- SSR服务端渲染
将组件或页面通过服务器生成html,再返回给浏览器,如nuxt.js
- 静态化
目前主流的静态化主要有两种:(1)一种是通过程序将动态页面抓取并保存为静态页面,这样的页面的实际存在于服务器的硬盘中(2)另外一种是通过WEB服务器的 URL Rewrite的方式,它的原理是通过web服务器内部模块按一定规则将外部的URL请求转化为内部的文件地址,一句话来说就是把外部请求的静态地址转化为实际的动态页面地址,而静态页面实际是不存在的。这两种方法都达到了实现URL静态化的效果
- 使用
Phantomjs针对爬虫处理
原理是通过Nginx配置,判断访问来源是否为爬虫,如果是则搜索引擎的爬虫请求会转发到一个node server,再通过PhantomJS来解析完整的HTML,返回给爬虫
