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 这一行，而在它上下游的状态同步与副作用管理。
