狠狠吐槽一下SSR/Next.js（六）：SSR 没有未来

开篇：我站在 2026 年回头看

现在是 2026 年 7 月。

距离 Next.js 第一次把 SSR 推上神坛，已经过去了好几年。距离我开始写这个系列的第一篇吐槽，也过去了大半年。

现在，尘埃落定。我终于可以不带情绪地说一句：

SSR，这个曾经被捧上天的"革命性技术"，正在走向消亡。

不是因为它"不好"，而是因为它"不合时宜"。

就像一个精美的马车，在汽车时代无论怎么升级——换上更软的坐垫、更轻的轮子、更快的马——它终究还是马车。

SSR 的命运，从 AI 普及的那一刻起，就已经注定了。

今天，我不吐槽了。我做一次"技术验尸"，冷静地分析 SSR 为什么没有未来。

一、历史规律：所有"中心化渲染"最终都会被淘汰

如果你把眼光放长到计算机科学的整个历史，会发现一个清晰的规律：

计算永远在向"边缘"迁移。

注意看，计算在"中心"和"边缘"之间来回摆动，但每一次"边缘化"都是更深度的边缘化。

SSR 是什么？它是把渲染计算"拉回中心"（服务器）。

这个方向，和"边缘计算"的大趋势完全相反。

• Edge Computing：把计算推到离用户最近的边缘节点
• SSR：把计算拉回离用户最远的中心服务器

你是在逆潮流而动。

而那些"顺潮流"的技术在做什么？

• Astro：默认静态（边缘缓存），按需动态
• Qwik：在边缘节点做"可恢复"渲染，而不是"重新执行"
• React Server Components（理论上）：在边缘 CDN 上预渲染
• Vite + SSG：构建时生成，永久缓存

未来的方向不是"在服务器上渲染"，而是"在离用户最近的地方，以最轻量的方式提供内容"。

SSR 的方向，错了。

二、一个残酷的事实：SSR 的"使用场景"正在消失

让我们诚实地问自己：SSR 到底解决了什么问题？

答案只有两个：

1. SEO（搜索引擎优化）
2. 首屏性能（让内容更快展示）

现在，我们来逐个分析这两个"刚需"在 2026 年的状态。

场景一：SEO —— 爬虫已经进化了

2020 年的时候，Googlebot 对 JavaScript 的支持还很弱。你不做 SSR，Google 就看不到你的内容。

2026 年呢？

• Googlebot 完整执行 JavaScript（包括 React、Vue、Angular）
• Bingbot 也支持了
• 社交媒体爬虫（Facebook、Twitter/X、LinkedIn）都在逐步升级
• 百度依然落后，但那是百度的问题，不是你的问题

更重要的是：AI 搜索引擎来了。

• ChatGPT Search：直接读取内容，不需要 SEO 元数据
• Perplexity：汇总多个源，不依赖单个页面的"关键字"
• Google AI Overviews：在搜索顶部直接给答案，用户不点链接

SEO 的价值本身在下降。用户不再"搜关键字 → 点进你的页面"，而是"问 AI → 得到答案"。

当你依赖的"优化目标"（搜索引擎排名）本身在贬值时，为了它所做的所有技术投入，都在同步贬值。

你还为了 SEO 去搞 SSR？为了一个逐渐萎缩的通道，牺牲整个架构的简洁性？

场景二：首屏性能 —— 网络和硬件已经进化了

2015 年，4G 刚普及，手机 CPU 还很弱，一个 React SPA 的 JS bundle 要 2MB，加载 5 秒。

2026 年呢？

• 5G 普及，Wi-Fi 6 普及：百兆带宽是标配
• 手机 CPU 性能翻了 5 倍：执行 100KB 的 JS 只需要几十毫秒
• HTTP/3 + 边缘 CDN：静态资源加载时间 < 200ms
• 浏览器缓存策略优化：第二次访问几乎秒开

"首屏慢"这个问题的严重性，在逐年递减。

而 SSR 带来的复杂性问题，在逐年递增。

当"网速慢"这个前提不存在了，为"慢网速"设计的 SSR，还有什么存在的必要？

你用 2026 年的网络和硬件，去解决 2016 年的问题——这叫"过度优化"。

三、SaaS 模式的终结：为什么 Serverless + SSR 是个死胡同

Vercel 的商业故事是这样的：

1. 给你一个"全栈框架"（Next.js），让你在前端项目里写后端逻辑
2. 让你把这些"全栈"代码部署到他们的 Serverless 平台（Vercel）
3. 按请求量收费，流量越大你付得越多

这个模式有一个致命问题：SSR 的请求量和成本是指数级关系，而不是线性关系。

• 你的网站 1000 个用户/天 → Vercel 账单 $50/月
• 你的网站 10000 个用户/天 → Vercel 账单$500/月（10 倍用户 → 10 倍成本）
• 你的网站 100000 个用户/天 → Vercel 账单$5000/月（又 10 倍）

SSR 的每个请求，都要消耗服务器 CPU。用户越多，服务器消耗越大。

而纯静态（SSG）或纯客户端（CSR）的架构呢？

• 1000 个用户/天 → 带宽费用 $5/月（CDN 几乎免费）
• 10000 个用户/天 → 带宽费用 $10/月（CDN 几乎免费）
• 100000 个用户/天 → 带宽费用 $20/月

差距是 250 倍。

你用 SSR，等于主动选择了"可变成本最高"的架构。你的创业公司流量一起来，Vercel 的账单先把你吃掉。

SSR 不是技术选择，是财务选择。而且，是个糟糕的财务选择。

四、2026 年的新答案是"三件套"

那 2026 年，我们不搞 SSR，搞什么？

答案是三件套：SSG + CSR + Edge API

1. SSG（静态站点生成）：构建时搞定一切

• 所有"内容型"页面（博客、文档、产品页、营销页），在构建时生成 HTML
• 推送到 CDN，永久缓存
• 加载速度：世界最快（直接从 CDN 返回 HTML）
• 成本：几乎为零（CDN 带宽费几乎忽略不计）

SEO？完美。爬虫拿到完整 HTML。
首屏？完美。从 CDN 返回，延迟 50ms。

2. CSR（客户端渲染）：交互的部分交给浏览器

• 需要登录、个性化、动态交互的部分，用纯客户端渲染
• 用 Vite（或 Create React App）构建，逻辑清晰
• 数据从 Edge API 获取，JSON 格式
• AI 友好：AI 生成的代码准确率 95%+

一个页面，静态的部分是 HTML（SSG），动态的部分用 JS 增强（CSR）。

不需要 SSR，不需要水合，不需要'use client'的纠结。

3. Edge API：真正的"后端"交给边缘

• 那些"需要服务器"的逻辑（数据库查询、第三方 API 调用、鉴权）
• 部署在边缘节点（Cloudflare Workers、Vercel Edge Functions、Deno）
• 返回 JSON 给前端
• 按需付费，但每个请求的 CPU 消耗极小（只做数据聚合，不做页面渲染）

你的前端（CSR）调用 Edge API → Edge API 返回 JSON → 前端渲染界面。

前后端分离，清清楚楚。

这个"三件套"架构的特点是什么？

• 简单：SSG 是静态文件，CSR 是纯前端，Edge API 是纯后端
• AI 友好：每个部分都是"单一环境"，AI 不会困惑
• 成本低廉：CDN 缓存让 99% 的请求不消耗计算资源
• 性能卓越：CDN 永远比你的源站快
• 可维护：不用猜"这段代码跑在哪"

这不比 SSR 香一万倍？

五、React 已经在"背叛"SSR：一个信号

看一个技术有没有未来，看它的"上层"在往哪个方向走。

React 18+ 引入了Server Components，很多 Next.js 的粉丝说：“看，React 官方都在支持服务端渲染！”

但你要仔细看 React 团队的设计意图：

Server Components 的目的，不是"在服务器上渲染 UI"，而是"在服务器上生成数据，然后传输给客户端，客户端再渲染"。

它传输的是“数据描述”（一种特殊的 JSON），而不是“HTML 字符串”。

这跟 SSR 的"生成完整 HTML 字符串"有本质区别。

Server Components 的终极目标，是让"数据获取"和"UI 渲染"在逻辑上更靠近，但在执行上仍然分离。

而 SSR 是"在服务器上执行整个 UI 渲染"。

React 团队没有在"加强 SSR"，他们在“用一种更优雅的方式，让服务器做数据的事，让客户端做渲染的事”。

这种设计，和"三件套"（SSG+CSR+Edge API）的思路是吻合的，而不是和 SSR 吻合的。

连 React 自己都在从 SSR 转向"数据+渲染分离"模式。

你还抱着 SSR 不放？

六、AI 时代：SSR 的"棺材板"是被 AI 钉上的

这是这个系列最核心的论点，我再说一次：

在 AI 时代，一个技术能存活的前提是——AI 能理解它、能生成它、能调试它。

SSR 不满足这个前提。

• AI 分不清服务端/客户端代码
• AI 搞不懂版本差异
• AI 无法推理"多维执行图"
• AI 生成的测试用例跑不通
• AI Agent 频繁任务断裂

一个"AI 不友好"的技术，在 AI 时代没有未来。

这不是预测，这是逻辑推导：

1. 未来 90% 的代码将由 AI 生成（或辅助生成）
2. 如果一个框架让 AI 频繁出错，开发者就会减少使用
3. 使用量下降 → 社区萎缩 → 生态凋零 → 死亡螺旋

SSR + Next.js 已经在这个"死亡螺旋"的入口处了。

我不是说它明天就死。它还有存量用户，还有大公司的"技术债"要还。

但如果你现在开始一个新项目，你还要选 SSR？

那我只能说：祝你好运。你的竞争对手，正在用 Vite+SSG+CSR，用 AI 2 倍速开发，而你的 AI 还在帮你制造 bug。

七、最后的告别：写给 SSR 的墓志铭

SSR（1995-2026）

它曾短暂地解决了 SEO 和首屏问题，
但代价是带来了十倍于问题的复杂度。

它高喊着"全栈革命"，
实则是"关注点分离"的背叛者。

在人类开发者还在忍耐它时，
AI 第一个投了反对票。

它的棺材板，由以下几颗钉子钉死：

• 边缘计算的崛起
• 网络和硬件的进化
• Vercel 账单的飙升
• React 本身的转向
• AI 的集体困惑

安息吧，SSR。
你不是死得最惨的技术，
但你绝对是死得最"不必要"的技术。

因为你的问题，本来就不该存在。

结语：向前走，别回头

读完这七篇文章，你可能会有两种反应。

反应一：“你说得对，我早就受够了。下个项目我一定换。”

如果是这样，恭喜你。你已经从"框架迷信"中醒来了。去拥抱简单、纯粹、AI 友好的架构吧。

反应二：“你太极端了，SSR 还是有它的适用场景的。”

没错，任何技术都有"适用场景"。如果你是一家拥有 100 人前端团队、流量以亿计的超级公司，SSR 也许能给你带来 5% 的性能提升。

但对于那95% 的普通项目、普通团队、普通开发者来说——

SSR 的成本 >> 收益。

而我们大多数人，都属于那 95%。

所以，我的建议很简单：

让你的代码跑在它该跑的地方。浏览器的事，交给浏览器。服务器的事，交给服务器。AI 的事，交给 AI。

不要为了"酷"，把自己的项目和职业生涯架在火上烤。