Appearance
AJAX 与前后端分离：SPA 的诞生
最后更新：2026-08-19
本主题要回答的问题
- AJAX 到底"新"在哪？为什么 2005 年之前浏览器做不到局部更新？
- 前后端分离的架构分界线画在哪？它解决了什么、又制造了什么新问题？
- 单页应用（SPA）的"首屏慢、SEO 差"是怎么被它的架构决定的？
一、AJAX：页面第一次可以"不刷新"更新
AJAX（Asynchronous JavaScript And XML）不是一门新技术，而是 2005 年 Jesse James Garrett 给一组已有技术的组合起的名字：
| 组成 | 作用 | 早已存在？ |
|---|---|---|
| XMLHttpRequest（XHR） | 浏览器发起异步 HTTP 请求 | 1999 年 IE5 就有（ActiveXObject） |
| DOM 操作 | 更新页面局部内容 | 是 |
| JavaScript | 编排以上逻辑 | 是 |
| CSS | 局部样式 | 是 |
真正的引爆点是 Gmail（2004）与 Google Maps（2005）：它们把"整页刷新"的体验彻底换掉，用户第一次感受到"网页像桌面软件"。随后 jQuery 把 $.ajax() 封装成一行代码，AJAX 迅速成为标配。
二、前后端分离：架构分界线
AJAX 普及后，一个自然的架构分化出现了：
| 关注点 | 前端 | 后端 |
|---|---|---|
| 渲染 | 负责 HTML/CSS/JS 与页面交互 | 不再产出页面，只产出数据 |
| 数据 | 通过 API 拉取，前端自己拼 UI | 只负责业务逻辑 + 数据存储 |
| 部署 | 静态资源服务器 / CDN | 独立 API 服务 |
| 技术栈 | JS 生态任意发挥 | 与前端解耦（Java/Go/Python…） |
收益：前端后端可独立开发、独立部署、独立扩容；同一套 API 可服务 Web/App/小程序多个端。
代价：出现"接口契约"问题——字段变了、接口拆了，前后端各自不知情。由此诞生了 API 文档工具（Swagger/OpenAPI）、类型生成（OpenAPI → TypeScript）、以及后来的 BFF（Backend for Frontend）层。
三、SPA：把"应用"搬进浏览器
前后端分离的极致形态是单页应用（SPA）：整个站点只有一个 HTML 入口（index.html），JS 通过前端路由（hash 或 history API）切换"页面"，所有视图在浏览器里渲染。
SPA 的得与失：
| 优点 | 缺点 |
|---|---|
| 切换快：不整页刷新，只换局部 | 首屏慢：要先下载完整 JS bundle 才能渲染 |
| 交互流畅：像原生应用 | SEO 差：爬虫看到的是空壳 #root |
| 后端轻松：静态托管即可 | 状态管理复杂：客户端状态需要框架治理 |
| 离线/缓存友好：静态资源 CDN 化 | 前端工程复杂度爆炸：路由/状态/构建全要自己管 |
四、SPA 留下的遗产与它的修正
SPA 的"首屏慢 + SEO 差"两个硬伤，直接催生了时代五的两条修正路线：
- SSR：在服务器上把 SPA 先渲染一遍出 HTML，浏览器拿到首屏再"水合"成交互应用；
- SSG：如果内容是构建期已知的（文档、博客），干脆构建时一次性生成静态 HTML。
所以今天没有"纯 SPA 天下"了，而是 SPA / SSR / SSG 按场景混用——这正对应演进总纲里"渲染位置摆动"的规律。
一句话总结
AJAX 让页面第一次能"局部更新"，前后端分离让"渲染"与"数据"成为两条独立的流水线，SPA 则把整条渲染流水线搬进了浏览器——它换来极致交互，却付出了首屏慢、SEO 差的代价；这两个代价，恰好定义了下一代技术（SSR/SSG）的作业面。