服务端渲染（SSR）指在服务器用 Node.js 预先执行前端框架代码生成完整 HTML 再返回浏览器，以提升 SEO、首屏速度和兼容性；需框架支持或手动实现，并处理水合与环境差异。
服务端渲染（Server-Side Rendering，简称 SSR）在 JavaScript 中，指的是用 Node.js 等运行时，在服务器上预先执行前端框架（如 React、Vue、Next.js、Nuxt）的代码，生成完整的 HTML 字符串，再把这页 HTML 发送给浏览器——而不是让浏览器先下载空壳 HTML 和 JS 文件，再由 JS 自己“画”出页面。
为什么需要 JavaScript 的服务端渲染
纯客户端渲染（CSR）的页面，初始 HTML 往往只有一小段容器（比如 <div id="root"></div>），所有内容靠 JS 运行后动态插入。这对 SEO、首屏加载速度、低配设备或禁用 JS 的环境都不友好。SSR 把“渲染”这步提前到服务端，浏览器拿到的就是带内容的 HTML，能立刻显示，也方便搜索引擎抓取。
JS 服务端渲染怎么实现
核心是让原本跑在浏览器里的 JavaScript 框架，也能在 Node.js 环境中执行，并输出 HTML 字符串。常见做法包括：
- 使用支持 SSR 的框架：如 Next.js（React）、Nuxt（Vue）、SvelteKit（Svelte），它们封装了服务端入口、数据预取、HTML 注入等细节
- 手动实现（不推荐新手）：用 ReactDOMServer.renderToString 或 Vue 3 的 renderToString，在 Express 路由中调用组件并拼接 HTML 模板
- 注意处理“水合”（hydration）：浏览器端 JS 需要接管服务端生成的 DOM，确保事件绑定和状态同步，否则会报 hydration mismatch 错误
SSR 不是万能的
它带来首屏优化的同时，也增加了服务器 CPU 开销和复杂度。比如：
立即学习“Java免费学习笔记（深入）”；
- Node.js 服务要承担渲染压力，可能需扩容或加缓存（如 Vercel/Netlify 的边缘函数或 CDN 缓存 HTML）
- 部分浏览器 API（如
window、document）在服务端不可用，代码里得做环境判断（typeof window !== 'undefined'） - 路由、状态管理、样式注入等环节都要适配服务端生命周期，开发和调试成本更高
基本上就这些。SSR 是一种权衡选择，不是所有项目都需要——内容型网站、营销页、SEO 敏感场景更适合；后台系统、内部工具通常用 CSR 更轻快。
