一个后端眼中的 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。
getStaticProps 和 getServerSideProps 跑在 Node 环境里,里面写 window.location 直接报错。所有浏览器 API 都要放到组件挂载后的副作用里执行。坑二:hydration 不一致。 服务器渲染的 HTML 和客户端首次渲染对不上就报 hydration error,常见元凶是直接渲染
Date.now()、随机数,或者依赖 localStorage 的值。我的处理方式是这类内容放进 useEffect,等客户端接管后再渲染。我的选择
一句话:能静态就静态,不行加 revalidate,万不得已才 SSR。博客、文档、营销页用 SSG 或 ISR,首屏快、SEO 好、服务器零压力;需要登录态、千人千面的页面才轮到 SSR。搜索引擎对静态页面最友好,这基本是公开内容站点的默认答案。
Loading...