Vue SSR 中响应式系统不执行，仅客户端激活后启动；服务端需确保状态可序列化、避免跨请求共享实例、隔离环境敏感逻辑，并特殊处理 Portal/Teleport。
Vue 的响应式系统在 SSR 环境下本身不执行，也不产生副作用——它只在客户端激活（hydration）后才真正“启动”。服务端渲染时，Vue 运行在 Node.js 环境中，没有 DOM、没有浏览器 API，响应式系统（如 ref、reactive、computed）虽然可被导入和调用，但其底层依赖的 Proxy 拦截与依赖追踪机制无法生效，也不会收集任何 effect。此时组件只是“静态快照生成器”，输出的是纯 HTML 字符串。
所以关键不是“响应式系统在 SSR 下怎么工作”，而是如何避免它干扰 SSR 的一致性。
vue-component-analyzer
下载
递归分析 Vue 项目组件依赖，从入口文件生成组件层级图，支持 Vue 2/3，输出组件名、文件路径和属性。适用于分析组件结构、排查依赖或了解项目架构。
响应式状态必须可序列化且两端一致
服务端生成的 HTML 要和客户端激活时重建的 VNode 完全匹配，否则触发 hydration mismatch。这意味着： - store 或组件中的响应式数据（如 `reactive({ user: { name: 'Alice' } })`）不能含函数、Promise、Date、RegExp、Symbol 或其他非 JSON 安全值 - 服务端应显式赋值 `$state = plainObject`，而不是通过 `toRaw()` 修改或直接操作 proxy 引用 - 客户端需在 `createApp()` 前读取 `window.__INITIAL_STATE__` 并同步到 store，确保初始状态完全一致禁止跨请求共享响应式实例
Node.js 是单进程多请求模型，若在模块顶层创建全局 Pinia/Vuex 实例： - 所有用户请求将共用同一份响应式状态 - A 用户登录后，B 用户可能看到 A 的用户信息 - 正确做法是：每次 SSR 请求都新建 `createPinia()` 实例，并注入到当前 `app`；客户端复用单例，但用服务端传来的数据重置状态环境敏感逻辑必须隔离
任何依赖 `window`、`document`、`localStorage`、`Math.random()` 或 `Date.now()` 的响应式计算，都会导致服务端与客户端输出不一致： - 不要在 `setup()` 中直接调用 `useRoute()` 或 `useRouter()` 获取路由参数——应在组件内获取后 commit 到 store - 动态 key 或 class 名不要靠随机数生成，改用服务端可预测的标识（如 `route.params.id` 或预传 `props.id`） - 浏览器专属逻辑（如 resize 监听、viewport 判断）必须包裹在 `onMounted` 或 `if (typeof window !== 'undefined')` 中Portal、Teleport 等跨节点渲染需特殊处理
这类功能依赖运行时 DOM 移动，在 SSR 中无法模拟： - PortalVue 的 Wormhole 是单例，服务端缓存会污染后续请求 - Vue 原生 `不复杂但容易忽略
