Vue SSR 与 CSR 的核心差异在于渲染主体、时机及产物使用方式：SSR 由服务端提前生成完整 HTML 并返回，客户端仅 hydration 复用 DOM；CSR 则完全依赖浏览器执行 JS 动态生成内容。
Vue.js 的渲染机制在 SSR 和 CSR 下最核心的差异，不是“能不能渲染”，而是“谁来渲染、什么时候渲染、渲染完怎么用”。这直接影响首屏速度、SEO 效果、服务器压力和交互响应方式。
HTML 生成时机与内容完整性
CSR 模式下，服务器只返回一个极简的 HTML 骨架（比如只有 <div id="app"></div>），所有真实内容都靠浏览器下载并执行 JavaScript 后动态生成。用户看到白屏或 loading 的时间，取决于 JS 加载、解析、执行和 API 请求完成的总耗时。
SSR 模式下，Node.js 服务在收到请求那一刻，就调用 Vue 的服务端渲染逻辑（如 renderToString），把组件树结合数据直接转成带内容的完整 HTML 字符串，一次性返回给浏览器。用户几乎立即看到可读内容，LCP（最大内容绘制）时间大幅缩短。
客户端“激活”过程（Hydration）
SSR 返回的 HTML 是静态的——它能展示，但不能响应点击或输入。Vue 必须在客户端执行“水合”（hydration）：用客户端 Vue 实例接管已存在的 DOM，复用其结构，绑定事件监听器，建立响应式系统。
立即学习“前端免费学习笔记（深入）”；
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
- hydration 不会重新创建 DOM，而是“复用”服务端生成的节点，因此性能开销远小于 CSR 的 mount 流程
- 若服务端与客户端渲染结果不一致（例如用了
document或window等浏览器专属 API），hydration 会失败并触发警告甚至降级为重新挂载 - hydration 完成后，页面才真正具备交互能力，后续路由跳转、状态更新等行为与 CSR 完全一致
数据获取与生命周期执行环境
CSR 中，onMounted、created 等钩子只在浏览器中运行，适合调用 fetch、操作 DOM、监听窗口事件等。
SSR 中，部分逻辑需在服务端提前执行：
- 数据预取通常放在
setup或专门的asyncData/fetch钩子中，由服务端调用并注入到页面上下文 -
onMounted在服务端不会执行（没有 DOM），只在客户端激活后触发；而onServerPrefetch（Nuxt）或useFetch（Vite SSR）等机制专为服务端数据准备设计 - 所有依赖浏览器 API 的代码必须做环境判断（
if (typeof window !== 'undefined')），否则服务端会报错
构建与部署逻辑分离
CSR 项目打包产物是纯静态资源（HTML + JS + CSS），可直接托管在 CDN 或 Nginx 上，无需 Node.js 服务。
SSR 项目需同时构建两套产物：
- 客户端包（用于 hydration 和后续交互）
- 服务端 bundle（供 Node.js 运行时执行渲染逻辑）
- 通常还需配合入口服务器（如 Express/Vite SSR 模式）或托管平台（如 Vercel、Cloudflare Workers）支持服务端执行
这种双构建流程增加了配置复杂度，也对错误边界、缓存策略、热更新调试提出更高要求。
