17370845950

SSR是服务端执行同构JS生成HTML字符串而非塞入document；核心区别在于首次HTML是否由服务端产出；需规避window等浏览器API、用服务端友好数据获取方案；首屏更快因减少白屏时间，但增服务端开销；典型错误“window is not defined”须环境隔离而非try-catch。

JavaScript 的服务端渲染（SSR）不是把 document 对象塞进 Node.js，而是用同构 JavaScript 在服务端执行组件逻辑、生成 HTML 字符串，再发给浏览器。它和传统客户端渲染（CSR）最根本的区别在于「首次 HTML 是否由服务端产出」。

SSR 是怎么跑起来的？关键在同构和可序列化

服务端没有 window、document 或 DOM API，所以 SSR 要求框架或代码本身能区分运行环境。比如 React 的 renderToString()、Vue 的 renderToString() 都只依赖虚拟 DOM 数据，不触碰真实 DOM。

• 必须避免在组件顶层或 useEffect/mounted 中直接操作 localStorage、location 或调用浏览器专属 API
• 路由需使用服务端友好的方案，如 Next.js 的 getServerSideProps、Nuxt 的 asyncData
• 数据获取不能只靠客户端 fetch，得在服务端提前拉取并注入到初始 HTML 或状态中

为什么首屏更快？但不是所有场景都适合 SSR

SSR 提速的核心是减少「白屏时间」：浏览器收到的不是空壳 index.html，而是带内容的完整 HTML，可立即渲染文本和静态结构。这对 SEO、低配设备、弱网用户明显友好。

• 但 SSR 会增加服务端 CPU 开销和响应延迟，Node.js 进程可能成为瓶颈
• 如果页面高度交互、依赖大量客户端状态（如实时协作编辑），SSR 带来的 HTML 可能很快被客户端接管重绘，收益变小
• 静态内容多、SEO 敏感（如博客、商品页）——适合 SSR；后台系统、仪表盘——通常 CSR 更稳

常见报错：ReferenceError: window is not defined 怎么修？

这是 SSR 最典型的错误，说明某段代码在服务端执行时试图访问浏览器全局对象。不能靠 try-catch 挡，得从源头隔离。

function MyComponent() {
  // ❌ 错误：顶层就执行
  const isBrowser = typeof window !== 'undefined';

  // ✅ 正确：只在 useEffect 或 onMounted 里用
  useEffect(() => {
    if (typeof window !== 'undefined') {
      console.log(window.innerWidth);
    }
  }, []);

  return hello;
}

• 第三方库未适配 SSR 时，可用动态导入绕过：Next.js 中 dynamic(() => import('xxx'), { ssr: false })
• 检查 package.json 的 exports 字段，有些包已提供 import / require 分离入口，优先用 ESM 版本
• Webpack 或 Vite 构建时，target: 'node' 和 target: 'web' 必须分清，别让浏览器代码打进服务端 bundle

SSR 看似只是“把渲染挪到服务器”，实际牵扯构建流程、数据流设计、错误边界、缓存策略甚至 CDN 配置。很多项目卡在“能跑”和“跑稳”之间，问题往往不出在 renderToString 这一行，而在它上下游的状态同步与副作用管理。