17370845950

服务端渲染（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 里跑一遍，有几个容易踩坑的地方必须处理：

• 避免浏览器专属 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 和用户体验的项目来说，值得认真考虑并合理落地。