函数式与对象式：前端架构的两种成本曲线

connor

一、先拆掉一个错误的对立

讨论 Vue/React 与 Zova 的差别时，最常见的说法是"函数式 vs 对象式"。这个说法很方便，但它把三对不同的东西混在了一起：

• 语法形式：写函数还是写类
• 状态宿主：闭包变量还是对象属性
• 架构归属：身份、作用域、生命周期由谁管理
  

只要稍微往源码里走一步，就会发现"React 是函数式的、Vue 也是函数式的、Zova 是对象式的"这个分类根本站不住。
React 的"函数"只是渲染的表达式形式。 Hooks 依赖固定的调用顺序——这意味着每个函数组件背后都必须有一个持久存在的 Fiber 节点来保存 hooks 链表。纯函数不需要身份，而 React 组件有身份、有档期、有副作用清理队列。React 是把一套对象系统藏在了函数语法之下。
Vue 的 setup() 是函数，但每个组件实例是对象。 响应式宿主是 Proxy 对象，ref 是带 getter/setter 的盒子，reactive 是代理化的对象图。Vue 从来没有假装自己是纯函数式的。
所以真正的分水岭不在于"用不用函数"，而在于：

谁拥有身份、作用域和生命周期——是闭包，还是容器管理的 bean？

这才是 Zova 与 Vue/React 默认心智模型的分界线。
二、两种模型各自的"默认答案"

这一个区别，会在系统长大之后反复显形。
三、成本曲线：先付与后付

两种模型真正的差异是成本出现的位置。
函数式风格：架构熵，后付成本

单个组件几乎没有额外成本——写个函数，声明几个 ref，结束。但 Vue 官方给了四种彼此正交的共享机制：

• props / emits
• composables
• provide / inject
• store 层（Pinia 等）
  

当系统长到几十个模块、多个团队时，这四种机制会同时存在于一个代码库里。哪个状态该用哪种机制？没有强制答案，只能靠团队约定。约定的密度会随着人数线性增长，而执行的偏差会随人数指数增长。这就是架构熵——它不在第一天出现，但从不缺席。
对象式风格：仪式感，先付成本

Zova 里每个 bean 都要声明自己的角色、作用域、生命周期。一个只服务于单个组件内部的状态，也要先回答"你是哪个 bean、住在哪个容器里"。这是先付的仪式感。
组件内部、组件之间、应用全局、系统全局——四种共享作用域，同一套 IoC 语义。provide/inject 不再是独立的子系统，而是 host / skipSelf 注入作用域的自然推论。
所以"哪个更好"是伪命题。 正确的问题是：你的系统复杂度主要落在哪一层？落在"渲染组合"上，函数式的灵活性是纯收益；落在"领域所有权、模块化、长期演进"上，对象式的统一性才能回本。
四、三件只有容器化才做得干净的事

有些事情不是"风格选择"，而是"有没有这个机制"的问题。
1. SSR 的请求作用域

SSR 里有一条硬约束：跨请求的状态必须隔离，单例模块状态会泄漏用户数据。
函数式模型里没有"请求"这个可寻址的容器。你只有两个选择：模块级单例（泄漏），或者每次请求重建整个模块图（昂贵且容易漏）。而 Zova 的 app 容器天然就是请求边界，sys 容器天然跨请求——这不是语法糖，是 SSR 的一等需求被直接建模进了架构。
2. 可被拦截的调用点

AOP、权限注入、日志、行为扩展——这些都要求"调用点"有稳定身份。纯函数调用没有身份，想拦截只能靠包装函数层层套，而包装层自身又是匿名的、不可寻址的。bean 的方法调用天然穿过容器，容器天然是拦截点。
3. 跨模块契约

函数式跨模块共享最终也会汇聚到某个全局 store key 或 context key——本质上也是字符串契约，只是没有容器替你管理它的注册、解析和生命周期。机制人人都会自己造，区别在于它是架构的一部分还是脚手架的一部分。
五、诚实地列出对象式的三个代价

如果只看到收益，那是营销不是架构。对象式有三个真实代价：
1. 装饰器 + 元数据 = 运行时魔法。 @Use() 背后是构建期转换和运行期解析的合谋。静态可读性下降，调用栈更深，排错时要多穿透一层框架。
2. 粒度被迫变粗。 当"任何东西都该是 bean"成为惯性，就会出现一个输入框也要立角色、定作用域的过度建模。对象式需要纪律来对抗自己的仪式感。
3. 与 React 演进方向的结构性冲突。 RSC 和并发渲染把状态推向可序列化的纯数据，而 bean 是不可序列化的活对象图。Zova 只能生长在 Vue 上而不是 React 上——这不是审美选择，是运行时底座决定的：Vue 的组件实例本来就是带响应式作用域的对象，天然适合作为 bean 的宿主；React 的 Fiber 底座则在往相反方向走。
六、收敛点：对象负责身份，函数负责表达

有意思的是，两个阵营都在向对方的核心地带移动。
Zova 自己就是混血：底层跑的是 Vue reactivity，$computed、$watch 是彻头彻尾的函数式 API。对象只承担身份、作用域、生命周期，不承担计算。
React 生态也在往身份化走：signals 的复兴、QueryClient 这样的外部状态容器、Zustand 这类"把状态从闭包里拿出来"的 store——本质都是承认纯闭包承载不了所有状态，需要一个可寻址的宿主。
由此可以给出一个可操作的判断标准：

一个东西如果需要被"找到、替换、跨作用域共享、随生命周期销毁"，它就是对象；否则它就该是函数。
用对象包裹纯函数，是过度设计；用闭包承载需要身份的东西，是架构债。

七、结语：不在同一个抽象层上的争论

最后回到标题的那个对比。
函数式解决的是"如何组合渲染"，对象式解决的是"如何组织一个长期存活的系统"。前者是编程范式，后者是架构范式——它们不在同一个抽象层上。拿两者的优雅程度直接对比，容易得出"FP 更先进"的结论，但这个结论是错的：React 的 hooks 恰恰是带顺序约束、带副作用、被 Fiber 调度的 effectful 闭包，离纯函数的距离并不比 class 更近。
真正值得问的问题始终是：

• 我的系统里，状态的身份属于谁？
• 状态共享机制是一套还是四套？
• SSR 的请求边界建没建模？
• 新人接手一个陌生模块，要改掉某个状态的行为：他需要在 composable、store、provide/inject 里逐一翻找状态的宿主，还是只问一句"这是哪个 bean"？
  

Zova 选择先付仪式感、后收秩序。这个选择对不对，不取决于语法的优雅程度，而取决于你的系统打算活多久、长多大。