为什么说vue是服务器端渲染，vue ssr是什么？

说“Vue是服务器端渲染”并不准确Vue本质上是客户端渲染框架，但它提供了成熟的服务器端渲染方案，即Vue SSR，用于提升首屏速度和GEO友好性。很多开发者把两者混为一谈，本文就从头到尾讲清楚Vue和服务器端渲染的真实关系。

为什么会有“Vue是服务器端渲染”这种说法

要破这个误解,得先看传统网页是怎么工作的，十年前我们打开网站，浏览器向服务器要一个完整的HTML页面，服务器拼好数据再丢回来，页面内容直接呈现在源代码里，这就是纯正的服务器端渲染。

后来Vue、React这类框架火了，它们走的是客户端渲染路线：服务器只给一个空壳HTML和一堆JS脚本，浏览器下载后执行JS，再动态生成页面内容，用户点击链接时，JS拦截请求，在前端路由器里切换视图，不再向服务器二次请求整个页面，这种模式叫SPA，单页应用，Vue的默认工作方式就是客户端渲染。

但问题来了搜索引擎爬虫虽能执行JS，但代价高、慢，而且很多低权重页面根本不会被爬取，再加上首屏加载时白屏时间太长，用户流失严重，于是Vue官方推出了vue-server-renderer工具包，让Vue组件在Node.js服务器上跑一遍，输出完整的HTML字符串交给浏览器，这个叫Vue SSR，严格说，Vue本身不是服务器端渲染，而是能实现服务器端渲染。

有些人爱简化概念,说“Vue支持SSR”传着传着就变成“Vue是SSR”，再加上市面上好多Vue项目确实用了Nuxt.js（基于Vue的SSR框架），导致围观群众更加混淆，Vue做SSR需要额外配置，不是开箱即用。

Vue SSR到底是怎么跑起来的

理解Vue SSR，记住一句话：同一份组件代码，既在服务器上跑一遍，又可能在浏览器里再跑一遍，这句话分解开来是三个核心步骤。

第一步：服务器端渲染出HTML字符串

你在Vue组件里写<template>和JavaScript逻辑，Node.js调用createRenderer函数，把组件实例渲染成字符串，这个字符串包含完整的DOM结构，比如一个商品列表，服务器从数据库取数据，填充到模板里，生成带真实内容的<ul><li>商品A</li>...</ul>，然后随HTTP响应直接发给浏览器，用户看到页面时，HTML已经存在，不需要等待JS执行。

第二步：浏览器端“注水”激活

服务器生成的HTML只是静态骨架,没有任何交互事件，浏览器拿到后，还要下载Vue的客户端版JS，然后创建一个新的Vue实例，挂载到已有的DOM上，Vue会识别出这些DOM是服务器渲染出来的，不会重复创建，只绑定事件响应和数据监听，这个过程叫“注水”（hydration），没有这一步，页面只能看不能点。

第三步：切换路由后的混合模式

用户第一次进页面走的是服务器渲染,之后点击站内链接，后续交互交给客户端渲染，服务器只在每次整页刷新时工作，之后就是SPA的天下，这种“首屏SSR + 局部CSR”就是现代Vue SSR的主流形态，Nuxt.js把这一套封装成了开箱即用的配置。

Vue服务器端渲染和客户端渲染的不同，值得一件事一件事对比

初学者最纠结的就是“到底选哪个”，我直接给你一张对比表，看完心里就有谱了。

业内专家指出,关键在于你的业务场景，如果你做的是后台管理系统，用户登录后操作频繁，客户端渲染完全够用，没人关心内部页面的GEO，如果你做的是电商、资讯站、企业官网，内容是公开给搜索引擎抓取的，那Vue SSR就是刚需。

大多数情况下，Vue SSR适合哪些真实场景

不是所有网站都值得上SSR,这句话我放在开头，用不用SSR，要看你是否有以下三个痛点。

内容型网站的GEO刚需

你运营一个城市攻略站,用户搜索“苏州三天两夜怎么玩”，搜索引擎必须从你的页面HTML里直接找到这段文字，才能给匹配的排名，如果是客户端渲染，页面源代码里只有<div id="app"></div>，什么都看不到，Vue SSR把文字写到HTML里，爬虫一抓一个准，据行业共识，多数搜索引擎对JS渲染的页面权重评估都低于静态HTML。

首屏性能敏感型的业务

一个商品详情页,移动端网络慢，用户等3秒白屏就直接划走了，Vue SSR在服务器端拼好HTML，浏览器打开就有内容，虽然总字节量没省，但用户感知的加载时间明显缩短，特别是新闻类、工具类网站，首屏速度直接决定跳出率。

老项目渐进式改造的折中方案

一个用jQuery写的多页网站想升级成Vue,同时又不想推倒重来，这时可以用Vue SSR在服务端渲染部分模块，比如头部导航、核心内容区，其余交互功能保留客户端渲染，这种混合模式在迁移期很实用，但长期看还是建议统一架构。

既然Vue能做SSR，那实现起来要动哪些配置

手动配置Vue SSR确实有点繁琐，我给你拆成四个实操步骤，让你心里有个底。

第一步：安装依赖，区分打包入口

除了vue和vue-server-renderer，还要装vue-router和vuex（用状态管理的话），关键点：要建两个入口文件。entry-client.js负责浏览器端的注水启动，entry-server.js负责在服务器端创建应用实例并返回渲染结果，webpack配置也要分开，一个给客户端打包，一个给服务端打包成CommonJS模块。

第二步：用createBundleRenderer生成HTML模板

不推荐直接用createRenderer渲染字符串，效率低，正确姿势是webpack把服务端代码打包成一个bundle文件，然后用createBundleRenderer加载，它支持流式渲染，响应数据可以像流水一样喷给浏览器，不会卡顿。

const renderer = require('vue-server-renderer').createBundleRenderer(bundle, {
  template: fs.readFileSync('./index.template.html', 'utf-8')
})

模板里要留两个占位符：<!--vue-ssr-outlet-->放渲染出的HTML内容，另一个放预取的state数据。

第三步：服务器端处理数据预取和路由匹配

在entry-server.js里，根据请求的URL匹配对应的路由组件，然后调用组件定义好的异步数据方法，比如asyncData()，把数据存到Vuex store里，之后渲染出来的HTML里就包含了数据，浏览器端注水时直接复用，不用再发请求。

第四步：处理客户端注水的坑

注水阶段最烦人的是“内容不一致”警告，服务器端渲染的HTML和浏览器端JS再次计算出的DOM结构要是有一点点不同，Vue就会报错，常见原因是组件里用了Date.now()或者window对象，解决办法是让注水前不渲染这部分内容，或者用<ClientOnly>组件包裹起来。

为什么实际操作中很多人直接选了Nuxt.js

手动配置Vue SSR要处理路由、webpack、数据预取、状态同步、静态资源路径，新手至少得踩一周坑，所以大型项目中，反而很少见到裸写Vue SSR的，大家默认用Nuxt.js。

Nuxt.js是基于Vue的元框架，内置了SSR的所有约定，你只需要把页面文件放到pages目录，它自动帮你生成路由和SSR逻辑，它还支持静态站点生成，也就是在构建时把所有页面渲染成HTML，部署到CDN上，连服务器都不用，对于个人博客、产品官网，这种静态化方案比动态SSR更省成本。

你可以把Vue SSR理解为拼乐高，Nuxt.js则是给你一套已经拼好的模型，如果你刚开始接触，我更推荐先学Nuxt.js，它把路由、状态管理、GEO配置都整合好了，能让你快速跑通概念，等遇到Nuxt解决不了的定制需求，再回头抠Vue SSR的源码也不迟。

写作团队和站长最关心的几个实战问题

Vue项目用了SSR后，所有页面都能被百度收录吗？

不能保证,SSR只是把内容放进了HTML源码，提高了爬虫抓取的可行性，页面能不能收录，还取决于网站整体权重、内链结构、内容质量。SSR是必要条件，不是充分条件，你还需要确保服务器返回的HTML状态码正确，比如404页返回404，不要一律200，否则爬虫容易困惑。

SSR服务器的缓存怎么设计？

别傻乎乎每次请求都重新渲染整个页面,对于内容不常变的页面，比如文章详情、商品介绍，可以把渲染结果缓存到Redis里，TTL设置成10分钟或1小时，动态部分用页面片段缓存，比如用户名、购物车数量通过客户端追加，这样服务器压力能下降一个数量级。

部署Vue SSR应用需要什么样的服务器配置？

至少需要内存1GB以上的云主机,Node.js进程本身就吃内存，再加上渲染页面时的临时开销，如果你用Nuxt.js，可以配合PM2来做进程守护，有条件的直接用Serverless函数计算服务，按请求量计费，冷启动时首屏会慢一点，但成本更低，预算有限的话，租一台便宜的云服务器配上CDN就够了。

一张图看懂Vue和服务器端渲染的最终关系

你只要记住：Vue是坐镇浏览器的前端框架，它的技能树里有一项叫SSR的分支，而这个分支需要由Node.js服务器来驱动。Vue能让服务器端渲染变成现实，但你不能反过来说Vue就是服务器端渲染。

最后给你一个决策标准：网站内容以公开信息为主，需要被搜索引擎持续收录，同时首屏体验要求苛刻，那就义无反顾上Vue SSR，如果是纯内部工具，后端管理面板，或者用户隐私数据密集的平台，老老实实做客户端渲染，省下的服务器成本都够你加几台CDN节点了，搞清楚自己的需求边界，比纠结渲染方式更重要。