过去这十年，SPA（单页应用）几乎成了前端开发的标配。无论业务场景是什么，大家上来就是一套 React Router 或者 Vue Router。但随着现代基建的演进，这种盲目的架构崇拜正在被残酷的现实狠狠打脸。
仿佛只要你还在写传统的 HTML 多页跳转，你就是一个没见过世面的原始人😖。我们为了追求所谓的丝滑无刷新体验，把路由、鉴权、状态管理，甚至把整个后端的业务逻辑模型，生硬地搬到了脆弱的浏览器内存里。
但在 2026 年的今天，当你接手了一个运行了三年、塞满了 500 个页面的巨型 SPA 项目时，你会发现这根本不是什么现代化的工程，而是一个无法收拾的垃圾场。
SPA 曾经横扫前端领域, 而被我们鄙视的 MPA（多页应用），正在现代化的云原生基建下，开始浮现。
SPA 存在什么问题？
SPA 最大的死结，在于它极其漫长的内存生命周期。
在一个 MPA 里，用户从 A 页面跳到 B 页面，浏览器会执行一次 （Hard Reload）。这意味着 A 页面的所有内存泄漏、所有未清理的定时器、所有混乱的全局状态，都会在跳转的那一瞬间被垃圾回收机制（GC）彻底清空。这是一种 物理隔离。
而 SPA 呢？
用户在你的系统里点了一上午的菜单，切换了 50 个路由，浏览器的内核根本没有刷新过。
你在 A 页面给 window 绑定的滚动事件没有解绑，它就会在 B 页面继续疯狂触发；你在 C 页面塞进 Redux 里的几兆脏数据，会一路污染到 D 页面。随着用户停留的时间越来越长，页面的内存占用会像滚雪球一样飙升，直到浏览器悄无声息地白屏崩溃。
为了解决这些原本不该存在的问题，前端工程师不得不发明出各种花里胡哨的生命周期钩子、路由守卫和状态清理逻辑，强行给原本就不堪重负的客户端又套上一层沉重的枷锁。
客户端路由和服务端路由
为了实现 无刷新跳转，我们到底付出了多大的代价？
在传统 SPA 里，一个极其普通的面相用户的页面跳转和鉴权，在代码层面往往会膨胀的很快👇：
// 为了一个页面跳转，在客户端写了无数的防御和拆包逻辑
import { lazy, Suspense } from 'react';
import { BrowserRouter, Route, Routes, Navigate } from 'react-router-dom';
const Dashboard = lazy(() => import('./pages/Dashboard')); // 异步分包
function AppRouter() {
// 前端被迫在本地存储里读取 Token
const token = localStorage.getItem('token');
return (
<BrowserRouter>
{/* 只要是 SPA，你就永远逃不掉这恶心的白屏 Loading 圈😖 */}
<Suspense fallback={<LoadingSpinner />}>
<Routes>
<Route
path="/dashboard"
element={
// 客户端路由守卫：先加载组件 -> 发现没权限 -> 再重定向
token ? <Dashboard /> : <Navigate to="/login" replace />
}
/>
</Routes>
</Suspense>
</BrowserRouter>
);
}
这段代码看似标准，实际上充满了妥协：首屏需要下载庞大的路由解析器，鉴权逻辑暴露在极其不安全的客户端，而且每次异步加载分包时，用户都必须忍受那个该死的 Loading 圈🤔。
而在 2026 年现代 MPA（如 Astro 或原生 RSC 架构）的降维打击下，这种逻辑直接回归了 HTTP 协议的最底层：
// 路由和鉴权彻底回归服务端
// 零客户端路由代码，零状态污染，绝对的安全隔离
export async function DashboardPage({ request }) {
// 在服务端/边缘节点直接拦截 Cookie
const token = request.headers.get('Cookie')?.match(/token=([^;]+)/)?.[1];
if (!isValidToken(token)) {
// 最纯正、极其快速的原生 HTTP 302 跳转，没有任何客户端闪烁
return Response.redirect('/login', 302);
}
// 服务端直连获取数据
const data = await fetchDashboardData(token);
// 直接吐出渲染好的纯净 HTML
// 浏览器接到后直接绘制，没有 JS 包裹，没有按需加载的 Loading 圈
return (
<html>
<body>
<DashboardView data={data} />
</body>
</html>
);
}
发现了吗？当路由回归服务端，代码量直接少了一半。你不需要再去处理乱七八糟的异步加载，不需要在客户端做脆弱的路由守卫。把最重的东西交回给服务器，让浏览器只做最纯粹的渲染。
为什么服务端渲染 在 2026 年受欢迎？
有人可能会反驳：MPA 每次跳转都要白屏，体验太差了！
这句话在 10 年前是对的，但在今天就是彻底的刻舟求剑🫡。
随着 HTTP/3 协议的普及，多路复用和连接复用已经极其成熟；随着 Cloudflare 等边缘节点把 HTML 吐给客户端的延迟压缩到了 30 毫秒以内；随着现代浏览器引入了 bfcache（往返缓存）和原生的预加载规范（Speculation Rules API）。
今天的一个现代化 MPA 页面，点击跳转的速度甚至比你那个还要去请求 JSON、再等待 React 执行 Diff 算法的 SPA 还要快。你肉眼根本察觉不到所谓的页面白屏闪烁。
于是，像 Astro 这样的孤岛架构框架应运而生。它们打出的旗号就是：默认就是多页应用，默认 0 KB 的客户端 JavaScript。只有在页面某个具体的组件（比如一个点赞按钮）需要交互时，才局部注入 JS。
什么时候用SPA，什么时候用 MPA ？
如果你的业务是类似于 Figma 的在线设计工具、或者是极度重度交互的在线表格，你依然需要 SPA 来维持复杂内存状态的高频流转。
但如果你的业务是电商独立站、内容博客、甚至是很大一部分由图表和表单组成的 B 端后台管理系统，你真的需要把整个站点打包成一个几兆大小的 JS 巨兽吗？
👉 不要去管理状态，因为消灭状态，才是最好的状态管理。
这一点你们怎么看😁？
