JavaScript服务端渲染（SSR）核心是Node.js中预执行框架代码生成HTML字符串并返回，区别于CSR的客户端动态构建；关键步骤包括路由匹配、数据预取、renderToString、模板注入与hydrate；需规避浏览器API、处理样式提取及上下文传递。
JavaScript 实现服务端渲染（SSR）的核心，是让原本在浏览器中执行的 JavaScript 代码（尤其是 React、Vue 等框架应用），在 Node.js 环境中提前运行并生成 HTML 字符串，再将这个 HTML 直接返回给客户端。这和传统客户端渲染（CSR）有本质区别：CSR 是服务器只返回一个空 HTML 和 JS 文件，等浏览器下载完 JS 后才开始构建页面；而 SSR 是服务器“已经把页面画好了”，用户看到的是真实内容，不是白屏或 loading。
服务端渲染的关键实现步骤
以 React 为例，SSR 不是简单地用 ReactDOM.render()，而是使用 ReactDOMServer.renderToString() 或 renderToPipeableStream()：
- 在 Node.js 服务中（如 Express），收到请求后，根据 URL 创建对应的 React 组件（带数据预取逻辑）
- 调用
renderToString(element)得到纯 HTML 字符串 - 把 HTML 插入模板（如
<div id="root">${html}</div>），连同初始状态（如 Redux state 或 React Query 数据）一起注入到页面中 - 返回完整 HTML 响应，浏览器直接渲染，JS 加载后进行“注水”（hydration），接管交互
与传统客户端渲染（CSR）的主要差异
传统 CSR（比如 create-react-app 默认方式）和服务端渲染在用户体验、性能指标、SEO 和开发约束上表现不同：
- 首屏加载体验：CSR 首屏常出现白屏或骨架屏，依赖 JS 下载+解析+执行；SSR 首屏即见内容，TTFB（Time to First Byte）之后很快可读
- SEO 友好性：搜索引擎爬虫能直接抓取 SSR 输出的完整 HTML，无需执行 JS；CSR 页面若未被现代爬虫正确渲染，可能索引不到有效内容
- 服务端压力与复杂度：SSR 每次请求都要在服务端执行 JS 渲染逻辑，消耗 CPU 和内存，需缓存策略（如页面级缓存、流式渲染）；CSR 压力全在客户端，服务端更轻量
-
数据获取时机：CSR 在组件挂载后（
useEffect）发请求；SSR 要求在渲染前就拿到数据（如getServerSideProps或loadData函数），否则会漏内容或触发 hydration 不一致
常见 SSR 框架与简化方案
手动写 SSR 容易出错（比如全局变量污染、样式不一致、hydrate 失败）。主流方案已封装细节：
立即学习“Java免费学习笔记（深入）”；
-
Next.js：通过
getServerSideProps自动注入数据，App.getInitialProps或RootLayout支持服务端布局，开箱支持流式 SSR 和边缘运行时 -
Nuxt 3：基于 Vue 3，
useAsyncData和defineEventHandler统一处理服务端/客户端数据获取，自动剥离非 SSR 兼容逻辑 - Remix：按路由组织数据加载，强制你在 loader 中完成数据准备，天然契合 SSR 流程，错误边界和服务端异常处理更明确
需要注意的限制与陷阱
SSR 不是银弹，有些前端惯用操作在服务端不可用：
- 不能直接访问
window、document、localStorage等浏览器专属 API（需加条件判断或延迟到客户端执行） - CSS-in-JS 库（如 styled-components）需配合
ServerStyleSheet提取样式，否则服务端渲染无样式 - 第三方脚本（如埋点、广告）通常要等客户端 hydration 后再加载，避免服务端报错或重复触发
- 时间、URL、cookie 等上下文信息必须显式从 request 中提取传入组件，不能靠
location.pathname这类浏览器 API
