ssr通过服务器端生成含完整业务内容的html解决spa爬虫无法执行js导致收录率低的问题，提升seo与首屏性能。
单页应用（SPA）的HTML源码里通常只有空挂载节点，比如 <div id="app"></div>，真实内容靠JavaScript运行后动态生成。搜索引擎爬虫不执行JS或执行延迟，导致页面被当成“空白页”跳过，收录率极低。服务端渲染（SSR）能从根本上解决这个问题——让服务器在响应请求时，直接输出含完整业务内容的HTML。
SSR怎么让爬虫真正“看见”内容
传统SPA返回的是骨架HTML+JS bundle，爬虫拿到后无法执行JS，也就看不到列表、标题、描述等关键信息。SSR则在用户或爬虫发起请求时，由服务器完成三件事：拉取数据、填充模板、生成带内容的完整HTML字符串，再把这串HTML发给浏览器。爬虫收到的就是可直接解析的静态内容，无需等待JS执行。
- 搜索引擎首次抓取就能提取标题、正文、链接等语义信息，大幅提升收录和排名权重
- 首屏内容直出，FCP（首次内容绘制）时间显著缩短，用户打开更快
- 避免了“爬虫等JS执行→排队数天→最终只索引默认标题”的典型失效链路
主流框架中启用SSR的关键动作
不是所有前端项目都能开箱即用SSR，需依赖支持同构渲染的框架并做针对性配置：
-
Next.js（React）：pages目录下文件默认启用SSR；
getServerSideProps函数用于每次请求时服务端获取数据并注入页面 -
Nuxt.js（Vue）：开启
ssr: true，在asyncData或fetch钩子中调用API，框架自动将数据序列化进HTML -
SvelteKit：通过
load函数在服务端预取数据，配合export const ssr = true确保渲染发生在服务端 - 自建Node.js服务：可用Express + 模板引擎（如EJS、Pug），手动拼接HTML，但需自行处理路由匹配、数据获取与水合逻辑
SSR落地必须注意的几个硬性细节
配置不对，SSR可能白忙一场，甚至引发白屏或重复请求：
- 确保客户端JS执行时不做重复数据请求——可在入口判断
if (window.__NUXT__ || window.__NEXT_DATA__)存在就跳过初始API调用 - 服务端路由必须全覆盖：Nginx/Apache要配置fallback，所有前端路由都指向同一入口HTML，否则刷新页面会404
- 动态路由如
/post/123需在构建或运行时明确声明，不能只写/post/[id]通配符而期望SSR自动推导 - meta标签（title、description）必须在服务端动态注入，不能仅靠
document.title = xxx在客户端改——爬虫看不到后者
SSR不是万能解，得看场景选对路
SSR适合内容稳定、SEO强依赖、首屏体验敏感的场景，比如新闻站、电商商品页、企业官网。但它会增加服务器压力，代码需兼顾服务端与浏览器环境（同构限制），开发调试也更复杂。如果只是后台管理系统或用户登录后才看的内容，CSR反而更轻量。对内容更新极快又无需SEO的页面，预渲染（Prerendering）可能是更省资源的选择。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
