17370845950

Next.js 将 SSR 变为默认可选模式，通过 getServerSideProps 在每次请求时服务端获取数据并注入 props，禁止浏览器 API，避免手动实现 renderToString；不可与 getStaticProps 共存，需依数据动态性选择。

Next.js 并不“简化”服务端渲染（SSR）——它把 SSR 变成了一种默认可选、开箱即用的模式，而不是需要你手动搭 Express + React.renderToString + 手写数据获取逻辑的工程。

getServerSideProps 是 Next.js 中 SSR 的核心入口

它在每次请求时运行，服务端执行，用于获取页面所需数据。返回的对象会自动注入到页面组件的 props 中。

• 只在页面文件（pages/xxx.js 或 app/xxx/page.js）中有效，不能在普通组件里用
• 函数内不能访问浏览器 API（如 window、document），否则会报错或返回空值
• 如果抛出错误或返回空对象（{}），页面会显示 500 错误页
• 在 app 目录下，对应的是 generateStaticParams + dynamic = "force-dynamic" + 组件内 fetch，但行为逻辑已不同

export async function getServerSideProps(context) {
  const res = await fetch('https://api.example.com/user');
  const user = await res.json();
  return { props: { user } };
}

为什么不用自己写 renderToString？Next.js 已封装整个流程

你不需要手动调用 React.renderToString、管理 HTML 模板、注入初始 state、处理 hydration 冲突——Next.js 在构建和运行时都做了这些：

• 自动注入 __NEXT_DATA__ 脚本标签，

  

  把服务端数据序列化后传给客户端
• 客户端 React 启动时自动读取该数据，跳过重复请求，避免闪烁或状态不一致
• 内置 Link 组件实现 SPA 式导航，同时保留 SSR 的首屏优势
• 对 CSS-in-JS（如 styled-jsx）、样式隔离、 标签等都做了服务端适配

getStaticProps 和 getServerSideProps 别混用

这是最容易踩的坑：两个函数不能共存于同一个页面文件，否则构建失败，报错信息是 Error: You can't use both getStaticProps and getServerSideProps。

• getStaticProps：构建时生成静态 HTML，适合内容不常变的页面（博客、文档）
• getServerSideProps：每次请求都执行，适合用户个性化内容（仪表盘、登录后首页）
• 判断依据不是“有没有 API 调用”，而是“数据是否随请求变化”——比如带 context.query.id 的详情页，通常就得用 getServerSideProps

SSR 的关键不在“能不能做”，而在“哪部分必须服务端执行、哪部分可以延迟 hydrate、数据如何安全跨层传递”。Next.js 把边界划得很清楚，但你得自己看清哪些 fetch 真正在服务端跑，哪些被无意提升到了客户端——后者会导致水合失败或空白内容。