服务端渲染（SSR）指在服务器运行JavaScript生成完整HTML再返回浏览器，解决CSR首屏白屏、SEO差、弱网体验不佳问题；需规避浏览器API、统一数据获取、保证水合一致性，并区分SSR/SSG/ISR适用场景。
JavaScript服务端渲染（SSR）是指在服务器上运行 JavaScript 代码，生成完整的 HTML 字符串，再把这页 HTML 发送给浏览器。它不是让浏览器加载空壳页面再用 JS 拼出内容，而是直接返回“已经渲染好”的页面，用户打开就能看到内容，搜索引擎也能正常抓取。
为什么需要服务端渲染
纯前端渲染（CSR）如传统 React/Vue 单页应用，首屏要等 JS 下载、解析、执行后才画出内容，导致白屏时间长、SEO 不友好、首屏慢。SSR 把这部分工作提前到服务器做，解决了三个关键问题：
- 提升首屏加载速度：浏览器拿到的就是可直接显示的 HTML，不用等 JS 执行
- 改善 SEO：搜索引擎爬虫能直接读到完整页面结构和内容
- 更好支持低配设备或弱网环境：HTML 可先展示，JS 后续再“接管”交互
主流框架如何实现 SSR
现代前端框架大多提供官方或生态支持的 SSR 方案，核心思路一致：复用同一套组件逻辑，在 Node.js 环境中调用框架的渲染 API，输出 HTML 字符串。
-
Next.js（React）：开箱即用的 SSR 支持。写
getServerSideProps或使用app/目录下的 Server Components，页面请求时自动在服务端生成 HTML -
Nuxt（Vue）：通过
asyncData或useAsyncData在服务端预取数据，nuxt generate或nuxt dev默认启用 SSR -
SvelteKit：基于适配器（adapter）部署到 Node 环境，默认开启 SSR；
load函数在服务端运行，返回的数据注入组件上下文
SSR 的关键注意事项
SSR 不是简单把前端代码扔到 Node 里跑一遍，有几个容易踩坑的地方必须处理：
立即学习“Java免费学习笔记（深入）”；
-
避免浏览器专属 API：比如
window、document、localStorage在服务端不存在，要用typeof window !== 'undefined'或框架提供的onMounted/useEffect做条件判断 -
数据获取时机要统一：不能只在
useEffect里拉接口，得在服务端就准备好数据，再传给组件（如 Next.js 的getServerSideProps） - 样式与水合（Hydration）一致性：服务端渲染的 HTML 结构、class、内容，必须和服务端“启动”后的客户端完全一致，否则 React/Vue 会警告甚至报错
- 服务端没有 cookie/session 上下文？：Node 端需从请求头中手动提取 cookie，并传入数据请求层（如 Axios 实例），才能带上登录态去调后端接口
不等于全量服务端渲染：静态生成（SSG）与增量静态再生（ISR）
SSR 是“每次请求都渲染”，适合内容实时性高的场景（如用户个人页）。但很多页面内容变化少，更适合：
-
SSG（静态生成）：构建时就生成 HTML 文件，部署到 CDN，最快最省资源（如 Next.js 的
getStaticProps） - ISR（增量静态再生）：先静态生成，再设定过期时间，下次请求时后台悄悄更新，兼顾性能与新鲜度
选 SSR 还是 SSG，取决于数据更新频率、是否需要用户态个性化、运维复杂度等因素。
基本上就这些。SSR 是一项实用技术，不是银弹，但对重视首屏、SEO 和用户体验的项目来说，值得认真考虑并合理落地。
