过去这十年，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';constDashboard=lazy(()=>import('./pages/Dashboard'));// 异步分包functionAppRouter(){// 前端被迫在本地存储里读取 Tokenconsttoken=localStorage.getItem('token');return(<BrowserRouter>{/* 只要是 SPA，你就永远逃不掉这恶心的白屏 Loading 圈😖 */}<Suspensefallback={<LoadingSpinner/>}><Routes><Routepath="/dashboard"element={// 客户端路由守卫：先加载组件 -> 发现没权限 -> 再重定向token?<Dashboard/>:<Navigateto="/login"replace/>}/></Routes></Suspense></BrowserRouter>);}这段代码看似标准，实际上充满了妥协：首屏需要下载庞大的路由解析器，鉴权逻辑暴露在极其不安全的客户端，而且每次异步加载分包时，用户都必须忍受那个该死的Loading圈🤔。
而在 2026 年现代MPA（如Astro或原生RSC架构）的降维打击下，这种逻辑直接回归了 HTTP 协议的最底层：
// 路由和鉴权彻底回归服务端// 零客户端路由代码，零状态污染，绝对的安全隔离exportasyncfunctionDashboardPage({request}){// 在服务端/边缘节点直接拦截 Cookieconsttoken=request.headers.get('Cookie')?.match(/token=([^;]+)/)?.[1];if(!isValidToken(token)){// 最纯正、极其快速的原生 HTTP 302 跳转，没有任何客户端闪烁returnResponse.redirect('/login',302);}// 服务端直连获取数据constdata=awaitfetchDashboardData(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 巨兽吗？
👉不要去管理状态，因为消灭状态，才是最好的状态管理。
这一点你们怎么看😁？