一个后端眼中的 Next.js 与 SSR

Words: 806Read Time: 3 minLast edited: 2026-8-4

用后端的思维理解 SSR

写 .NET 的对「服务端渲染」其实不陌生:Razor 模板在服务器上把数据填进 HTML,浏览器拿到的就是完整页面。Next.js 的 SSR 本质上也是这么回事,只不过模板换成了 React 组件——服务器端先渲染出 HTML 发给浏览器,再由 React 在客户端「接管」(hydrate),接管之后页面才有交互能力。
想通这一层,剩下要搞清楚的只有一件事:这个 HTML 在什么时候生成。Next.js 的 Pages Router 给了三种答案。

SSG:构建时一次生成

getStaticProps 在构建时执行,页面生成静态 HTML,之后所有请求拿到的都是同一份文件,可以直接丢 CDN:
对应后端的场景,就像把不常变的页面直接做成静态文件缓存。我的博客文章页就是 SSG:内容几天才更新一次,没必要每次请求都跑一遍渲染。

SSR:每个请求现场渲染

getServerSideProps 每次请求都在服务器上执行,数据永远是最新的:
这就像 Razor 页面每次请求现查库现渲染。适合个性化内容、强实时数据——代价是每个请求都要占用服务器算力,慢查询直接拖慢首屏。

ISR:两者之间的折中

ISR(增量静态再生)是 Next.js 比较妙的设计:页面还是静态的,但设一个过期时间,过期后的第一个请求触发后台重新生成:
相当于给静态页加了一个缓存失效策略,既保留了 CDN 的速度,又保证内容最多落后一个周期。

踩过的坑

坑一:服务端没有 window。 getStaticPropsgetServerSideProps 跑在 Node 环境里,里面写 window.location 直接报错。所有浏览器 API 都要放到组件挂载后的副作用里执行。
坑二:hydration 不一致。 服务器渲染的 HTML 和客户端首次渲染对不上就报 hydration error,常见元凶是直接渲染 Date.now()、随机数,或者依赖 localStorage 的值。我的处理方式是这类内容放进 useEffect,等客户端接管后再渲染。

我的选择

一句话:能静态就静态,不行加 revalidate,万不得已才 SSR。博客、文档、营销页用 SSG 或 ISR,首屏快、SEO 好、服务器零压力;需要登录态、千人千面的页面才轮到 SSR。搜索引擎对静态页面最友好,这基本是公开内容站点的默认答案。
Loading...
© 2024 - 2026 ihuadz
中文