服务端渲染（SSR）指服务器在响应请求时动态生成含真实内容的完整HTML并返回浏览器，由服务器完成首次渲染，浏览器再通过hydrate激活交互能力。
服务端渲染（SSR）在 JavaScript 中，是指页面的 HTML 结构由服务器在响应请求时动态生成并直接返回给浏览器，而不是让浏览器下载空壳 HTML 后再靠 JS 拼出内容。核心区别在于“谁负责首次渲染”——SSR 是服务器，客户端渲染（CSR）是浏览器。
服务端渲染如何工作
以 Node.js + React（或 Vue、Next.js、Nuxt 等框架）为例：用户访问 /product/123，Node 服务收到请求后，会：
- 调用框架的渲染函数（如 renderToString 或 renderToPipeableStream），传入当前 URL 对应的组件和数据
- 组件在服务端执行（包括 useEffect 不触发，但 getServerSideProps 或 async setup 可获取数据）
- 生成包含真实内容的完整 HTML 字符串（带 hydration 所需的 data- 属性和 script 标签）
- 将 HTML 响应发给浏览器，用户几乎立刻看到内容
- 浏览器加载 JS 后，“激活”（hydrate）DOM，使页面具备交互能力
与客户端渲染的关键差异
不是快慢问题，而是职责和时机不同：
- 首屏内容可见时间：SSR 页面打开即见内容（无需等 JS 下载执行）；CSR 首屏常是白屏或 loading，直到 JS 加载、解析、挂载完成
-
SEO 友好性：搜索引擎爬虫能直接抓取 SSR 返回的完整 HTML；CSR 返回的初始 HTML 通常只有
<div id="root"></div>，不利于索引 - 网络与设备压力：SSR 把渲染压力放在服务器，适合内容型站点；CSR 把计算交给用户设备，适合复杂交互应用，但对低端手机或弱网更不友好
- 数据获取时机：SSR 在服务端就可请求 API 并注入 props；CSR 必须等 JS 运行后才发起请求，多一次往返延迟
实际开发中怎么选
没有绝对优劣，看场景：
立即学习“Java免费学习笔记（深入）”；
- 营销页、博客、电商列表页 → 优先 SSR（或静态生成 SSG）
- 后台系统、画图工具、实时协作编辑器 → CSR 更自然，状态管理集中，交互响应更可控
- 混合方案常见：用 Next.js 的 getServerSideProps 做部分页面 SSR，getStaticProps 做预渲染，SWR 在 CSR 阶段增量更新
- 注意 SSR 不等于“不用 JS”——它仍需客户端 JS 来 hydrate 和后续交互，只是起点不同
一个容易忽略的细节
SSR 渲染时无法访问浏览器专属 API（window、document、localStorage），否则会报错。常见写法是：
- 用 typeof window !== 'undefined' 做运行环境判断
- 把依赖 DOM 的逻辑移到 useEffect（只在客户端执行）
- 框架如 Next.js 提供 dynamic 函数按需加载 CSR 组件
