为什么在 2026 年，MPA（多页面应用）正在悄悄复辟？

过去这十年，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 里，一个极其普通的面相用户的页面跳转和鉴权，在代码层面往往会膨胀的很快👇：

tsx 复制代码

// 为了一个页面跳转，在客户端写了无数的防御和拆包逻辑
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 协议的最底层：

typescript 复制代码

// 路由和鉴权彻底回归服务端
// 零客户端路由代码，零状态污染，绝对的安全隔离

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 巨兽吗？

👉 不要去管理状态，因为消灭状态，才是最好的状态管理。

这一点你们怎么看😁？

为什么在 2026 年，MPA（多页面应用）正在悄悄复辟？

SPA 存在什么问题？

客户端路由和服务端路由

为什么服务端渲染 在 2026 年受欢迎？

什么时候用SPA，什么时候用 MPA ？

为什么服务端渲染在 2026 年受欢迎？