在大型 Vue 项目中，如何有效管理复杂的状态？散装版 vs 套装版

作者：袖梨 2026-07-09

先说结论

如果只保留一句话，我的判断是：

很多项目的问题，并不在于 ref、composable、provide/inject、Pinia、Query、localStorage 这些工具本身不好。

真正的问题在于：它们往往各自解决一段问题，最后整套状态系统却变成了散装拼接。

我这里说的“散装版”，不是在批评 Vue，也不是在否定 Vue 的灵活性，而是在批评一种极其常见的项目演化结果：

每一段状态都能工作
每一种机制都有道理
但整套系统越来越靠团队经验维持

而 Zova/Cabloy 想做的，不是“换掉 Vue”，而是把 Vue 3 之上的状态组织方式做成更明确的套装版架构：

Bean / Controller 负责状态所有权
IoC Scope 负责共享边界
Model 负责统一状态类别
Resource Owner 负责资源级查询、权限、Schema 与失效策略

如果项目只是中小规模，“散装版”完全能跑，而且往往很快。

但当项目进入多人协作、长周期演进、SSR、缓存、持久化、表单、权限、资源复用并存的阶段，“套装版”会越来越像基础设施，而不再只是编码偏好。

这也是整篇文章真正想讨论的问题：

真正的问题，不是“选哪个状态库”

很多人一谈状态管理，第一反应是：

要不要用 Pinia？
要不要再加一个 Query 层？
localStorage 怎么包一下？
SSR 怎么补 hydration？

这些问题当然重要。

但对大型项目来说，它们都还只是表面。

更深一层的问题其实是：

状态宿主：这段状态到底挂在哪个对象上？
共享边界：它是组件内共享、父子共享、应用级共享，还是系统级共享？
状态类别：它是服务端数据、内存态、本地持久化态、Cookie 态，还是异步持久化态？
缓存语义：query key 谁定义？命名空间怎么隔离？失效规则谁拥有？
生命周期：它在页面销毁、路由切换、刷新、SSR 请求之间如何存活？
资源语义：它只是一个值，还是一个资源的查询、权限、Schema、表单、动作的一部分？

如果这些问题分别由不同局部机制处理，那么项目迟早会进入一种熟悉的状态：

页面里有一部分状态
composable 里有一部分状态
store 里有一部分状态
query cache 里有一部分状态
浏览器存储里又有一部分状态

系统当然还在跑。

但越来越少的人能完整说清楚：

这才是大型项目真正会失控的地方。

因为一旦走到这一步，问题已经不再是“代码会不会写”，而是：

也就是说，大型项目真正缺的，往往不是“再多一个工具”，而是一套能让这些工具不互相打架的结构。

为什么很多大型 Vue 项目会自然长成“散装版”？

原因很简单：它的增长路径太自然了。

很多团队一开始都会这样写：

组件里先放本地状态
逻辑重复了，抽成 composable
父子传递麻烦了，用 provide/inject
页面增多了，拉一个 store
服务端数据复杂了，再加 Query
需要持久化时，再补 localStorage / cookie
SSR 来了，再补 request-scope 或 hydration 规则

这条路径每一步都合理。

问题在于，它默认是一条“局部优化优先”的增长路径，而不是“状态边界优先”的增长路径。

所以项目越大，越容易出现这些现象：

同一类状态在不同页面有不同归宿
同一类刷新逻辑散在多个 mutation 成功回调里
localStorage 只是“顺手存一下”，没有成为状态语义的一部分
所谓“全局状态”混着请求级状态和系统级状态
资源页面的权限、Schema、查询、表单、缓存失效分别散在不同层

这就是“散装版”的本质：

换句话说，散装版真正危险的地方，不是它今天不能跑，而是它把复杂度的控制权长期交给了团队记忆、代码习惯和口头约定。

前期看起来很灵活，后期却很容易进入一种典型状态：

每个局部都“像是对的”
但整体越来越难被解释、复用和修改

这就是为什么很多大型 Vue 项目不是突然崩掉，而是慢慢失去结构感。

它不是一下子写坏的，而是一点点长散的。

Zova/Cabloy 的关键变化：不是换 Vue，而是换状态组织方式

理解 Zova/Cabloy，最重要的一点不是“它和 Vue 不一样”，而是：

在常规 Vue 心智里，开发者更熟悉的是：

setup()
ref() / reactive()
computed()
useRoute()
composable
provide/inject
store

而在 Zova 里，被推到前台的是另一套组织重心：

Controller / Bean 实例作为可见状态宿主
__init__ 作为主要 wiring 点之一
IoC 容器与 Scope 作为共享模型
Model 作为统一状态层
Resource Owner 作为资源边界的前端宿主

所以对大型项目来说，Zova/Cabloy 真正带来的，不是某个新 API，而是一条新的优先级：

这不是语法偏好，而是架构中心的转移。

说得更直白一点：

在散装版里，状态往往先出现，再慢慢寻找归宿
在套装版里，状态先被放进正确边界，再决定具体实现

这一步顺序变化，看起来很小，却几乎决定了大型项目后续是越写越稳，还是越写越散。

因为大型项目一旦进入复杂阶段，真正稀缺的已经不是“会不会写一个功能”，而是能不能持续把边界写对。

第一层套装：先把“状态宿主”说清楚

在很多 Vue 项目里，状态最自然的宿主，是 setup() 里的局部变量：

 复制代码const count = ref(0);
const count2 = computed(() => `=== ${count.value} ===`);

这当然没问题。

但项目一旦变大，这种写法很容易带来一个后果：状态先以“局部声明”的方式出现，之后再逐步外溢到 composable、store、父组件或别的抽象里。

Zova 则先把“状态宿主”架构化。可见状态通常直接落在 Controller 或 Bean 实例上：

 复制代码count: number = 0;protected async __init__() {
  this.count2 = this.$computed(() => {
    return `=== ${this.count} ===`;
  });
}increment() {
  this.count++;
}

这里真正重要的，不是“少写 .value”。

而是：

状态宿主变成了框架管理的实例对象
派生状态变成了实例生命周期中的 wiring
行为和状态自然收束在同一个 owner 上

这会直接改变大型项目的阅读方式：

Vue 常问：这段状态在哪个 composable 里？
Zova 更常问：这段状态归哪个 Bean / Controller 所有？

大型项目最怕的，往往不是状态不够灵活，而是状态没有稳定归属地。

因为只要宿主不稳定，后面的共享、持久化、缓存、SSR、失效策略，几乎都会跟着漂移。

换句话说，状态一旦没有稳定宿主，后面所有“补救式抽象”都会越来越贵。

第二层套装：把共享边界做成 IoC Scope，而不是到处切换机制

很多大型 Vue 项目之所以会越写越散，不只是因为状态多，而是因为共享边界的表达方式本身就是分裂的。

同样叫“共享”，常见做法却完全不同：

组件内部共享，用本地状态或 composable
父子之间共享，用 props / emits 或 provide/inject
应用级共享，用 store
更长生命周期的共享，用模块单例、插件状态，甚至某种“隐形全局”

结果就是：

Zova 把这个问题改写成同一个 IoC 模型下的几个 Scope：

共享范围	常见 Vue 3 做法	Zova 的问题表达
component-internal	本地状态、组件内 composable	这是不是 `ctx` 范围的 Bean？
between-components	props/emits、父级 composable、`provide/inject`	这是不是 `host` / `skipSelf` 的层级注入？
app-global	store、app-level provided state	这是不是 `app` 范围的共享状态？
system-level	模块单例、长生命周期导入态	这是不是 `sys` 范围、跨请求不重建的状态？

这张表真正重要的，不是术语，而是它背后的提问方式：

一个非常紧凑的心智模型就是：

 复制代码class ControllerPage {
  @Use()
  $$localCounterState: CounterState;  @Use({ injectionScope: 'host' })
  $$hostCounterState: CounterState;  @Use({ injectionScope: 'app' })
  $$appCounterState: CounterState;  @Use({ injectionScope: 'sys' })
  $$sysCounterState: CounterState;
}

这段代码的价值，不只是“注入语法统一”。

更重要的是：

共享边界被明确表达
状态不再因为共享范围变化而被迫切换到完全不同的机制
provide/inject、应用级共享、系统级共享，不再是三套平行世界

对 SSR 来说，这种区分尤其关键。

因为很多项目里的“全局状态”，其实混着两种完全不同的东西：

请求级 / app 级状态：应该跟着一次 app 实例或一次 SSR 请求走
系统级状态：不应该跟着每次请求重建

这两种东西如果不分清，SSR 下就很容易出现污染、错位或错误共享。

而 Zova 把它直接结构化到 app 与 sys 的区分里，让它不再只是团队口头经验。

这就是套装版的一个关键特征：

这一步非常重要，因为大型项目最怕的，从来不是“机制不够多”，而是机制太多，但边界没有统一语法。

第三层套装：Model 不只是请求层，也不是另一个 store

很多大型前端项目即便已经引入 store 和 query 库，状态体系依然只统一了一半。

最典型的切法通常是：

store 管客户端共享状态
query 库管服务端缓存
localStorage 工具管持久化
cookie 工具管请求相关状态
某些异步存储再各自包一层

这仍然是“散装版”思路：

每类状态都有工具
但状态类别之间缺少统一业务宿主

Zova 的 Model 把问题往前推了一步。

它不是只管 remote data，而是把几类常见状态都纳入统一的 model-state 层：

data：服务端 / query 风格状态
mem：内存状态
local：localStorage 状态
cookie：Cookie 状态
db：异步持久化状态

这件事的意义非常大。

因为它意味着：

它们语义不同，但可以处在同一个更统一的 model ownership 下。

而且这不是空洞包装。

Zova 的 Model 建立在 TanStack Query 之上，但对业务开发者暴露的是更体系化的 model 表面：

query key 带模型身份前缀
mutation key 带模型身份前缀
失效规则可以由 model 拥有
local / cookie / db 也仍然经过 model-owned keying 与 restore 语义
SSR / hydration 行为可以跟着 model 规则走

所以更准确的说法，不是“Model 是另一个 store”，而是：

这也是为什么在 Zova 里，localStorage 不只是“顺手存一下”。

更准确的理解是：

看起来只是描述方式变了，实际上变化的是项目的组织方式：

这段状态属于哪个模型
它的 key 空间怎么隔离
它的 restore 规则是什么
它的 invalidation 由谁负责
它是否参与 SSR 脱水 / 恢复语义

在散装版里，这些问题常常被拆散到多个工具链里分别回答；而在套装版里，它们更倾向于被收回到同一个 model boundary 里统一回答。

这才是大型项目真正需要的状态抽象。

说到底，真正有价值的不是“又多了一层 API”，而是终于有了一层能够统一解释这些状态差异的边界。

第四层套装：把“一个资源”的前端语义收束到 Resource Owner

很多团队即便用了 store 或 query 层，依然会在资源级复杂度上继续散掉。

比如一个典型的列表 / 表单 / 详情资源，页面通常还要分别知道这些事：

API 路径怎么拼
列表怎么查
行数据怎么查
新增/修改/删除怎么发
Schema 在哪拿
权限怎么判断
成功后失效哪些缓存
表单 provider 怎么组织

你会发现，到这里讨论的早就不只是“状态值”了。

它其实已经是一整组资源语义边界。

这也是 Zova ModelResource 最有价值的地方：

也就是说，模型可以拥有：

resource bootstrap
schema access
permissions access
form integration
query state
mutation state
cache invalidation policy

这会把很多项目里散在页面、表单、按钮、请求封装、schema 层、permission helper 层的东西，重新收回到一个稳定的资源边界里。

所以我更愿意用一句非常简洁的话概括它：

这句话的价值在于，它把“复杂状态管理”从几个响应式变量，提升成了对资源级边界的管理。

而资源级边界一旦稳定，页面、表单、权限、缓存、Schema 这些原本最容易四散的东西，也就更容易一起稳定下来。

这也是大型项目里最稀缺的能力之一：

一张表看懂：散装版 vs 套装版

维度	散装版	套装版
状态宿主	谁顺手拿着就先放哪	先确定 Bean / Controller / Model 的所有权
共享方式	composable、`provide/inject`、store 并列增长	统一纳入 IoC Scope 讨论
服务端数据	单独交给请求层或 query 层	纳入 Model 的统一状态边界
本地持久化	localStorage / cookie 各自包装	`local` / `cookie` / `db` 都是 model-state family
缓存 key	往往是人为约定的全局字符串	由 model identity 与 selector 自动参与命名空间
失效规则	页面、按钮、mutation 各自处理	由 model 拥有 invalidation policy
SSR 语义	常靠额外约定补齐	`app` / `sys`、hydrate/dehydrate 规则更结构化
代码阅读方式	先找变量和 hook，后猜边界	先看 owner、scope、model，再看实现
复杂度控制	主要靠团队自觉	更多靠框架结构把边界收住