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。
立即学习“Java免费学习笔记（深入）”；
-
getStaticProps：构建时生成静态 HTML，适合内容不常变的页面（博客、文档） -
getServerSideProps：每次请求都执行，适合用户个性化内容（仪表盘、登录后首页） - 判断依据不是“有没有 API 调用”，而是“数据是否随请求变化”——比如带
context.query.id的详情页，通常就得用getServerSideProps
SSR 的关键不在“能不能做”，而在“哪部分必须服务端执行、哪部分可以延迟 hydrate、数据如何安全跨层传递”。Next.js 把边界划得很清楚，但你得自己看清哪些 fetch 真正在服务端跑，哪些被无意提升到了客户端——后者会导致水合失败或空白内容。
