服务端渲染核心是在服务器运行React组件生成完整HTML并返回浏览器，Next.js基于Node.js自动封装路由、数据获取、HTML生成与hydration。
JavaScript本身不能直接实现服务端渲染（SSR），它需要运行环境支持。Node.js提供了服务端执行JavaScript的能力，而Next.js正是基于Node.js构建的框架，它封装了SSR所需的路由、数据获取、HTML生成和 hydration 等流程，让开发者无需手动处理底层细节就能开箱即用。
服务端渲染的核心逻辑是什么？
服务端渲染本质是在服务器上运行React组件，生成完整的HTML字符串，再发送给浏览器。这不同于客户端渲染（CSR）——后者只返回一个空HTML和JS文件，所有UI由浏览器下载脚本后动态构造。
- 用户请求页面时，Node.js服务器调用React.renderToString（或现代的renderToPipeableStream）把组件转为HTML
- 同时预取所需数据（如API调用、数据库查询），确保HTML包含真实内容而非加载占位符
- 生成的HTML连同初始props、script标签一起返回，浏览器直接显示，无需等待JS加载
- JS加载后，React在客户端“接管”DOM（hydration），绑定事件并启用交互
Next.js如何自动完成SSR？
Next.js通过约定式路由和特殊函数，在构建和请求阶段自动注入SSR能力。
- 页面文件放在pages目录下（如pages/index.js），默认启用SSR；每个页面可导出getServerSideProps函数，该函数在每次请求时运行于服务端，返回的props会传入页面组件
- 框架在启动时用Node.js启动一个HTTP服务（基于Express或原生http），拦截请求、匹配路由、调用对应页面的getServerSideProps，再结合React Server Components（App Router）或传统组件渲染HTML
- 它还内置了代码分割、样式隔离、静态资源优化、API路由（pages/api）等能力，全部围绕服务端执行上下文设计
与纯Node+React手动实现SSR相比，Next.js省去了什么？
手动实现SSR需自行搭建整套基础设施，容易出错且维护成本高；Next.js把这些封装成开箱即用的规则。
立即学习“Java免费学习笔记（深入）”；
- 不用手动配置Webpack/Babel服务端打包，Next.js自动区分client/server bundle
- 无需自己写路由分发逻辑，文件路径即路由，支持动态路由（如pages/blog/[id].js）
- 不需手动管理数据获取时机和错误边界，getServerSideProps天然支持异步、重定向、返回状态码
- 自动注入hydration脚本、处理CSS-in-JS服务端提取、支持增量静态再生（ISR）等高级特性
App Router（React Server Components）带来了哪些变化？
Next.js 13+推荐的App Router模式进一步解耦渲染逻辑，允许在服务端直接使用React组件消费数据，无需通过props层层透传。
- 组件可标记为'use client'（客户端组件）或默认服务端组件，后者可在import时直接await fetch，无须生命周期钩子
- 服务端组件不会被打包进客户端JS，减小体积；数据请求发生在服务端，避免暴露密钥或重复请求
- 页面结构由嵌套布局（layout.js）、模板（template.js）、加载态（loading.js）等文件约定组织，渲染流程更声明式
