Vue 3.5 响应式系统优化解读

去年 9 月发布的 Vue 3.5 对响应式核心做了自 Vue 3 诞生以来最大的一次内部重构，官方数据：大规模响应式数组场景内存占用降低约 56%，复杂计算更新更高效。研究了 RFC 和源码解读，总结三个关键变化。

1. Version Counter → Double-Ended Linked List

旧实现：每次属性被访问，就创建一个 Dep（依赖集合），副作用（effect）通过版本号记录自己依赖的状态版本，触发时对比版本判断是否需要重跑。问题是 effect 要维护一张 Map 记录大量版本号，深层嵌套和多依赖场景内存开销大。

新实现：依赖关系改用双向链表结构组织 Dep 与 Subscriber，每个 effect 不再为每个依赖单独存版本计数，而是以链表节点串联，移除了大量的 Map 条目。链表节点按需创建、用完即回收，所以内存显著下降。

2. Dirty check 机制重写：linked dep tracking

computed 的缓存判定逻辑被重构。以前 computed 链（computed 依赖 computed）需要遍历整个依赖链逐级确认脏状态；新版通过脏标记沿链表精确传播——只有真正变化影响到的 computed 才重新计算，深层 computed 组合的更新效率提升明显。

3. 响应式数组的内存优化

reactive([]) 场景下，数组的索引依赖被更紧凑地表示，不再为每个索引预建独立 Dep 结构，这是"56% 内存降低"的主要来源。

对应用代码的影响

• 纯内部重构，API 零变化，应用层无感
• 升级后建议跑一遍回归，重点是：computed 链、watch 深度侦听、超大 reactive 列表
• props 解构响应式在该版本稳定（以前是实验特性）
• 新增 useTemplateRef 等 API

启发

框架级优化的常见模式在这个案例里很典型：先用朴素可维护的结构把功能做对，积累真实场景的性能数据，再针对性更换数据结构。版本号 Map 简单但费内存，链表复杂但省空间——好的架构是演进出来的，不是一开始设计出来的。