你的网站真的需要 SSR 吗？不要再无脑用 SSR 了！

跟风上 SSR 之前，先看看自己要付什么

这几年 SSR 几乎成了技术选型的政治正确。方案评审会上，只要有人提”我们不用 SSR，多少会有点底气不足”。可真上线之后，一批批项目陆续踩进同一个坑：SSR 的收益没吃到，部署复杂度和运维成本倒是实打实涨上来了。

SSR 不是免费的。它要求你的应用跑在一个 Node 服务上，有状态、有内存、有并发压力，还要面对缓存策略、扩缩容、进程崩溃这些新问题。静态站点时代想都不用想的事，上了 SSR 全变成日常。

新手最容易栽的坑是盲目跟风。这股风气的源头，本质是一群想把前端 Node 能力塞进后端的人，服务端渲染顺手就成了”现代化”的标配。落到自己项目上，全站 SSR 等于要养一整套 Node 服务、做缓存、管扩缩容，维护成本和运维难度成倍往上翻，不少团队就是这么被拖垮的。

这篇文章不聊概念，直接把 SSR、CSR、SSG、ISR 四种方案的账摊开，看看每种方案部署什么样、成本什么样、适合什么业务，再说说什么业务真正需要 SSR，什么场景压根没必要。

四种方案的账本

方案	渲染时机	部署形态	成本结构	短板
CSR 客户端渲染	浏览器执行 JS 后渲染	纯静态文件，CDN / 对象存储托管	接近零，托管免费或按量计费	SEO 弱，首屏慢
SSR 服务端渲染	每次请求，服务器渲染后返回	需要 Node 运行时，自建服务器或 Serverless	常驻服务成本，随流量上涨	部署复杂，运维成本高
SSG 静态生成	构建时生成全部 HTML	纯静态文件，CDN 托管	接近零	内容更新需要重新构建
ISR 增量再生成	静态为主，按需重新生成	需要平台支持（Vercel 等）或自建	低于 SSR，高于 SSG	实现机制依赖平台

CSR 和 SSG 部署的是静态文件，往 CDN 一丢就行，GitHub Pages、对象存储、任意静态托管都能跑，成本趋近于零。SSR 必须有 Node 运行时，要么自建服务器自己管，要么上 Serverless 按请求量计费，免费额度撑得住个人项目，商业化后流量涨、账单跟着涨。ISR 是中间态，按静态生成，内容变了按需重新生成，拿的是 SSG 的速度和 SEO，付的是比纯静态多一点点的动态成本。

大多数网站，其实用不着 SSR

先把最常被误以为”得上 SSR”的几类说清楚，它们恰恰是最不需要的。

后台管理系统、SaaS 仪表盘、各种内部工具，比如飞书后台、企业微信管理台、阿里云控制台，几乎清一色 CSR。原因很直白：页面在登录墙后面，搜索引擎根本进不来，SEO 毫无意义；日常打交道的是表单、表格、弹窗这些重交互，客户端渲染体验反而最好。在这种项目里硬上 SSR，收益是零，平白多出一整套 Node 服务的运维，还有 window 对象报错这类前端框架跑在服务端特有的坑。后台上 SSR，在圈内早就是过度设计的典型。

博客、文档站、技术官网、营销落地页走 SSG 就够了。VitePress 的文档、Hugo 搭的个人博客、Astro 的官网、绝大多数开源项目主页都是这么干的。这类内容改动频率低，但对 SEO 要求高，构建时生成好的静态 HTML 直接丢 CDN，速度快到没话说，还不用养任何服务。少数更新很勤的资讯博客会用 ISR 做增量更新，本质还是静态，只是内容变了再重渲染一次。

短视频和视频平台，抖音网页版、B 站网页版都是 CSR 为主，最多配合接口预取数据。视频内容本身不需要搜索引擎抓整页，用户要的是滑动流畅，客户端渲染最对路。

企业官网、产品介绍页同理，SSG 优先，极少纯 SSR。小公司用 Hugo、Astro、VitePress 打包往 CDN 一丢，大公司营销页也走 SSG，新闻板块才用 ISR。

把 SSR 留给真正的强需求

说完不用的，再看 SSR 真正站得住的地方。一句话：强后端、又有即时需求。

电商常被拿来举例，但真拆开看，电商也很少全站 SSR。商品详情页走 ISR，基础信息缓存几分钟到几小时，库存和价格由客户端实时拉接口，不用每次访问都重新渲染，服务器 CPU 压力小一大截，七成流量其实是靠缓存和 ISR 扛的。真正要 SSR 的是搜索结果页，结果实时、还带个性化，必须每次请求现生成。登录后的”我的订单””个人中心”又回到 CSR，反正不进搜索引擎。所以电商是 ISR 打底、SSR 补关键页、CSR 收尾的混合打法。

资讯、新闻、内容社区也是混合。文章得被搜索引擎收录，所以首页和文章详情用 SSR 或 ISR，掘金、懂车帝、知乎网页版都是这个路子；但创作后台强交互，SSR 毫无收益，编辑器和个人后台统统 CSR。

SSR 真正有用的地方，其实就两类：内容发布后必须立刻被看到，还要带服务端那套权限、个性化逻辑；或者业务强依赖服务端状态，比如登录态、订单、购物车。

结语

讲到这里，其实选型逻辑已经非常清晰：SSR 从来都不是一个项目的 “加分项”，它只是一项有成本、有副作用的解决方案，专门用来解决「实时内容 + SEO + 个性化」这类特定问题。

不要被 “现代化前端””大厂都在用 SSR” 这类风气裹挟，上来就给全站开启服务端渲染。大厂几乎没有全站 SSR 的案例，普遍采用的都是混合渲染设计：公开内容页优先 SSG/ISR，只有实时动态页面才启用 SSR，登录后交互页面回归 CSR。

刚刚好才是最好，不要为了”现代化”走了歪路。