SSR、SSG 还是 CSR：别急着选，先看这四点

每次新开一个项目，总有人问：「我们用 SSR 还是 CSR？」

这个问题没有标准答案，但我发现，只要先想清楚四件事，答案自己就冒出来了。

先把三个词说人话

• CSR（客户端渲染）：服务器先甩给你一个空壳 HTML，真正的页面靠浏览器里的 JS 现画。像是一个空房间，家具到家才摆。
• SSR（服务端渲染）：每次有人访问，服务器现场把完整 HTML 拼好再发过来。访客拿到手就是装修好的房间。
• SSG（静态生成）：提前把每个页面都生成好静态文件，访问时直接发文件。相当于把房间先布置好，谁来看都一样。

判断标准一：内容多久变一次

文章一个月不更新？那 SSG 最香——生成一次，全球 CDN 直接发，又快又省。

内容是实时的（比如股票、库存）？那得 SSR 或者 CSR，每次都现取最新数据。

判断标准二：要不要被搜索引擎收录

博客、文档、产品页，都希望被搜到。这类页面最好 SSR 或 SSG，让爬虫一打开就能看到完整文字。

如果是后台管理系统（要登录才看得到），搜不搜得到无所谓，CSR 完全没问题。

判断标准三：交互有多重

页面就是看看文章、点个链接？SSR/SSG 足够。

如果满屏都是拖拽、实时协作、复杂状态，CSR 更顺手，因为交互逻辑本来就在浏览器里。

判断标准四：团队熟不熟

这点最实在。一个你从没用过的方案，再「先进」也可能把你坑哭。选团队能 hold 住的，比选「理论上最优」的重要得多。

一张可以直接抄的速查表

一个反例

我曾经给一个几乎不改内容的站点上了 SSR。结果每次访问都要服务器现拼页面，比直接发静态文件还慢半拍。

后来改成 SSG，速度一下子上去了。有时候「更先进」的方案，反而不如「更合适」的。

小结

别一上来就纠结名词。先回答自己四个问题：内容多久变、要不要 SEO、交互多复杂、团队熟不熟。答案清楚了，选什么自然就清楚了。