大家上来就是一套 React Router 或者 Vue Router。但因为现代基建的演进，这种盲目的架构崇拜正在被残酷的现实狠狠打脸。

仿佛只要你还在写传统的 HTML 多页跳转，你就是一个没见过世面的原始人😖。我们为了追求简单讲的丝滑无刷新体验把路由、鉴权、状态管理。甚至把整个后端的业务逻辑模型，生硬地搬到了脆弱的浏览器内存里。

现代化的工程，而是一个无法收拾的垃圾场。怎么说呢，

SPA 曾经横扫前端领域。而被我们鄙视的 MPA正在现代化的云原生基建下开始浮现。

SPA 的沉重代价

SPA 存在什么问题？

SPA 最大的死结，在于它极其漫长的内存生命周期。

使用者痛点一：页面切换后仍然卡顿、内存泄漏、定时器失控。

使用者痛点二：一次性下载数 MB 的 JavaScript 包导致首屏加载慢。

使用者痛点三：#白屏#、#闪烁#、还有因全局状态污染导致的不可预期错误。

在一个 MPA 里使用者从 A 页面跳到 B 页面浏览器会执行一次 . 这代表着 A 页面的所有内存泄漏、所有未清理的定时器、所有混乱的全局状态，都会在跳转的那一瞬间被垃圾回收机制（GC) 彻底清空。这是一种物理隔离.

而 S​PA?话说回来，使用者在你的程序里点了一上午的菜单。切换了 30+ 个路由，浏览器内核根本没有刷新过。

You bind a scroll listener on page A and never unbind it – it keeps firing on page B. You stash several megabytes of dirty data into Redux on page C – it pollutes page D. 因为使用者停留时间增长。页面内存使用像滚雪球一样飙升，直至浏览器悄无声息地白屏崩溃。

客户端路由和服务端路由

Pain point: 为了实现#无刷新跳转#”，我们付出了巨大的代码体量与安全风险。

// 为了一个页面跳转。在客户端写了无数防御和拆包逻辑
import { lazy,Suspense } from 'react';
import { BrowserRouter,Route,Routes。Navigate } from 'react-router-dom';const Dashboard = lazy => import);// 异步分包
function AppRouter {
// 前端被迫在本地存储里读取 Token
const token = localStorage.getItem;return (

{/* 只要是 SPA，你就永远逃不掉这恶心的白屏 Loading 圈 😖 */}
}>

 : }
/>


);老实说，}

This code looks “standard”,but it’s riddled with compromises: first screen must download a bulky router parser,auntication lives in an insecure client environment,and every lazy‑load shows that dreaded  spinner.

Pain point: The more logic you push to client。larger attack surface and slower experience.

// 路由和鉴权彻底回归服务端
// 零客户端路由代码，零状态污染，绝对安全隔离
export async function DashboardPage {
// 在服务端/边缘节点直接拦截 Cookie
const token = request.headers.get?.match/)，.;if ) {
// 最纯正、极其快速的原生 HTTP 跳转，没有任何客户端闪烁
return Response.redirect;话说回来，}
// 服务端直连获取数据
const data = await fetchDashboardData;// 直接吐出渲染好的纯净 HTML
// 浏览器接到后直接绘制，没有 JS 包裹。没有按需加载的 Loading 圈
return (

);}

Pain point solved: When routing returns to server,code size shrinks dramatically. No more messy async chunk loading。no fragile client guards. The heaviest lifting goes back to server,leaving browser to render only pure HTML.

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

Pain point: "MPA 每次跳转都要白屏". This was true a decade ago but is now an outdated myth.

• #HTTP/2+# 与 #HTTP/3# 多路复用让连接成本几乎可以忽略不计。
• #Cloudflare# 等边缘节点将 HTML 吐给客户端延迟压缩到毫秒级。
• #bfcache#与原生预加载规范（S​peculation Rules API) 能让返回历史页面瞬间呈现。
• #Modern browsers# 已经能够在几毫秒内完成完整页面渲染——比一次 JSON 请求 + React Diff 更快。

A modern MPA page’s navigation speed can be faster than a SPA that needs to fetch JSON,wait for React’s diff algorithm,and n paint. Users often can’t perceive any “white‑screen flash”.

This is *** frameworks like Astro。which champion “island architecture”,are gaining traction: y ship **kilobytes** of JavaScript by default and only hydrate interactive islands when necessary.

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

• Pain point：If you build an online design tool like Figma or a spreadsheet app with heavy real‑time interaction,you still need SPA‑style stateful client logic.
• If your product is an e‑commerce storefront,a content blog,or a B‑side admin dashboard composed mostly of tables and forms。bundling everything into a multi‑megabyte JS bundle is overkill.
• Pain point mitigation: No need to manage global client state—eliminate it entirely by letting server render each page fresh.

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

This shift from endless client‑side orchestration back to server‑driven rendering directly addresses developers’ biggest frustrations: memory leaks。long‑lasting loading spinners,security exposure of tokens,and unmanageable codebases.