前端状态管理V2双循环架构：从响应式原理到工程实践

1. 从V1到V2：一次架构思想的跃迁

如果你正在开发一个现代的前端应用，尤其是基于React或Vue这类响应式框架，那么“状态管理”和“副作用处理”这两个词对你来说一定不陌生。它们就像是应用中的“神经系统”和“消化系统”，一个负责感知变化并传递信号，另一个负责处理各种“外部事务”，比如数据请求、DOM操作、订阅事件。在很长一段时间里，我们处理这两者的方式，尤其是在React的生态中，是相对割裂和命令式的。直到像Vue Composition API、React Hooks，以及一些新兴的状态管理库（例如Zustand、Jotai）出现，一种更声明式、更内聚的模式开始流行，这就是所谓的“响应式编程”或“响应式状态管理”。

我们今天要深入探讨的“V1”与“V2”，并非指某个具体的库版本，而是代表了两种处理状态与副作用关系的核心架构范式。你可以把它们想象成汽车引擎的两种设计：V1是传统的自然吸气发动机，结构直观，但效率和响应性有提升空间；V2则是涡轮增压+直喷技术，通过更精巧的设计，实现了动力与效率的质变。这里的“双循环”，正是V2引擎中的那个关键的“涡轮增压”系统。理解V1的局限和V2双循环的机制，能让你从根本上把握现代前端状态管理的精髓，写出更健壮、更易维护的代码。

简单来说，V1模式通常指代一种“单向、同步、响应链路过长”的状态更新模型。状态变更直接触发副作用，副作用可能又修改状态，形成一个潜在的循环依赖或难以追踪的更新流。而V2模式的核心创新在于引入了明确的“双循环”机制：一个循环专注于状态变化的计算与派生（Computation），另一个循环则专门调度和执行副作用（Effect）。两者通过一个清晰的调度层（Scheduler）解耦，使得状态更新可预测、副作用可管理、性能优化有据可依。

从网络热词中频繁出现的v2、Effect、FiberSet等词汇，我们也能窥见业界对更精细、更可控的异步处理和资源管理机制的迫切需求。无论是容器镜像拉取(docker.io/v2)、模型API调用(/v1/chat/completions)，还是媒体资源请求(/v1/responses)，背后的系统都在追求更稳定、更高效的请求处理与错误恢复能力，这与前端中状态管理的演进逻辑是相通的。

2. V1模式：经典响应式与它的“阿喀琉斯之踵”

要理解V2为何而生，我们必须先回到V1的世界。在早期的响应式实现，或者一些简单的状态管理方案中，其核心模型可以概括为“观察者模式”的直白应用。

2.1 V1的核心运作机制

想象一个简单的计数器状态count，以及一个依赖于它的副作用：当count变化时，我们需要打印一条日志，并可能根据count的值去异步获取一些数据。

在V1模式下，流程通常是这样的：

1. 定义状态与依赖：声明一个响应式状态count = ref(0)。
2. 定义副作用：使用一个watch或effect函数，传入一个回调函数。这个回调函数内部读取了count.value。
3. 建立绑定：响应式系统会记录下这个副作用回调对count的依赖。
4. 触发更新：当count.value++被执行时，系统会立即同步地遍历所有依赖于此状态的副作用回调，并执行它们。
5. 潜在的连锁反应：副作用回调在执行时，可能会修改其他响应式状态，从而触发新一轮的副作用执行。

用一段伪代码来示意：

// 伪代码，模拟V1模式 const depsMap = new Map(); // 存储状态 -> [副作用] 的映射 let activeEffect = null; function watchEffect(fn) { activeEffect = fn; fn(); // 首次执行，收集依赖 activeEffect = null; } function trigger(target, key) { const effects = depsMap.get(target)?.get(key); effects?.forEach(effect => effect()); // 同步立即执行！ } // 使用 const state = reactive({ count: 0 }); watchEffect(() => { console.log(`Count is: ${state.count}`); // 副作用 if (state.count > 5) { state.anotherValue = 'high'; // 可能触发其他副作用 } }); state.count++; // 立即打印 “Count is: 1”

2.2 V1模式面临的典型问题

这种模式直观易懂，但在复杂的应用中，其弊端会迅速暴露：

1. 副作用执行顺序的不可控性：由于副作用是同步、立即执行的，当多个状态同时变更，或者一个副作用修改了另一个状态时，副作用的执行顺序完全取决于依赖收集的时机和实现细节，这可能导致难以调试的bug。例如，副作用A依赖于状态X和Y，副作用B只依赖于状态Y。当X和Y同时改变时，A和B的执行顺序是不确定的。
2. 无限循环的陷阱：这是V1最致命的问题。如果副作用回调内部修改了它所依赖的状态，就会立即触发自身再次执行，从而形成无限循环。

   watchEffect(() => { state.count++; // 在副作用中修改依赖的状态 -> 无限循环 });

   为了避免这种情况，开发者需要非常小心，或者依赖库提供一些蹩脚的防御机制（如设置最大递归深度）。
3. 性能损耗与冗余计算：同步执行意味着每次状态微小的变化都可能引发一大串副作用的连锁反应，即使其中一些计算是中间状态或不必要的。例如，在一个动画帧中连续修改状态10次，V1模式可能会触发10次完整的副作用计算和DOM更新，而实际上我们可能只关心最终结果。
4. 与异步渲染的冲突：在现代前端框架中，渲染往往是异步的（如React的Concurrent Mode，Vue的nextTick），旨在实现更平滑的用户体验。V1的同步副作用模型与这种异步调度机制格格不入，容易导致布局抖动（Layout Thrashing）或状态不一致。

注意：这里说的“V1”是一种架构模式的泛指，并不特指Vue 2的响应式系统。Vue 2的响应式虽然也是同步触发，但其watcher有异步队列（nextTick）来缓冲渲染副作用，这在一定程度上缓解了问题，但对于用户自定义的watch，核心的依赖触发仍是同步的。React早期的setState批量更新也是一种对同步副作用的优化，但并未从架构上彻底解决。

3. V2双循环架构：解耦的艺术

正是为了解决上述问题，V2双循环架构应运而生。它的核心思想是将状态计算（派生状态）与副作用执行分离，并引入一个统一的调度层来管理所有任务的执行时机。

3.1 何为“双循环”？

“双循环”指的是两个逻辑上独立但协同工作的处理循环：

1. 响应式计算循环（Reactive Computation Loop）：

   • 职责：专门处理纯的、同步的状态派生和计算。当原子状态（Atom）发生变化时，这个循环负责计算出所有依赖它的派生状态（Computed）的新值。这个过程应该是幂等且无副作用的。
   • 类比：就像电子表格中的公式计算。当你修改一个单元格（原子状态），Excel会重新计算所有引用这个单元格的其他单元格（派生状态），但这个过程不会去“打印”或“发送网络请求”。

2. 副作用调度循环（Effect Scheduling Loop）：

   • 职责：管理所有副作用（Effect）的调度和执行。它不直接响应状态变化，而是监听“响应式计算循环”的结果——即哪些派生状态或效应声明（Effect）需要被重新执行。然后，它将这些副作用任务放入一个队列，在合适的时机（如微任务、宏任务、动画帧空闲时）批量、异步地执行。
   • 类比：工厂的生产调度中心。计算部门（计算循环）给出了新的产品规格清单（需要执行的副作用列表），调度中心（副作用循环）根据生产线（浏览器事件循环）的忙闲情况，合理安排生产任务（执行副作用）。

3.2 核心组件：FiberSet与调度器

为了实现双循环，V2架构通常包含几个关键抽象：

• FiberSet：这不是React Fiber，而是一种通用的、用于描述可调度工作单元的数据结构。一个Fiber代表一个副作用任务或一个计算单元。它包含了任务执行的函数、优先级、依赖关系等信息。FiberSet则管理着所有Fiber的生命周期和依赖图。当状态变化时，受影响的计算Fiber会被标记为“脏”（dirty），并加入到待处理队列。
• 调度器（Scheduler）：这是整个V2架构的大脑。它持有一个或多个任务队列（通常按优先级划分，如Immediate，UserBlocking，Normal，Low）。调度器会从FiberSet中取出被标记的Fiber，根据其优先级放入相应队列，并利用浏览器的requestIdleCallback、MessageChannel或setTimeout等API，在事件循环的空闲时段执行这些队列中的任务。正是调度器实现了副作用的异步、批量执行。
• Effect与Computed的显式分离：在V2中，Effect和Computed是两种不同的声明。Computed是纯函数，只在计算循环中运行；Effect是包含副作用的函数，只会在副作用循环中被调度执行。API设计上会强制区分两者。

3.3 V2的工作流程详解

让我们用一个具体的例子，对比V1，看看V2是如何工作的：

假设我们有一个状态：userId， 一个派生状态：userProfile = computed(() => fetchUser(userId))(这里假设fetchUser是同步的，仅作演示)，以及一个副作用：effect(() => { document.title = userProfile.name; })。

场景：userId从 1 变为 2。

V1模式（简化）：

1. userId改变。
2. 立即同步执行userProfile的计算函数，fetchUser(2)被调用（假设同步，实际上可能是异步，这里突出问题）。
3. 立即同步执行effect回调，尝试设置document.title = userProfile.name。如果fetchUser是异步的，这里userProfile可能还是旧值，导致标题错误。

V2双循环模式：

1. 状态变更：userId被设置为 2。
2. 计算循环启动： a. 响应式系统标记依赖userId的userProfile计算Fiber为“脏”。 b.调度器介入：计算循环不会立即执行计算，而是通知调度器：“有计算任务需要更新”。 c. 调度器将userProfile的计算Fiber放入高优先级计算队列。 d. 在下一个微任务或同步任务块结束时，调度器执行计算队列，计算出userProfile的新值。注意：此时effect还未执行。
3. 副作用循环启动： a.userProfile值更新后，响应式系统标记依赖userProfile的effectFiber为“脏”。 b. 调度器将这个effectFiber放入普通副作用队列。 c. 调度器根据当前浏览器的空闲情况（可能是在下一个动画帧），从副作用队列中取出并执行这个effect，安全地更新document.title。

这个流程的关键在于：计算（可能包含同步的复杂运算）被优先、快速地执行完毕，而副作用被延迟、批量地执行。这带来了几个巨大优势：

• 避免无限循环：因为副作用被异步调度，在副作用执行时，当前的计算循环早已结束。即使副作用内修改了状态，那也是安排下一轮的计算和副作用，不会造成栈溢出。
• 自动批处理：在同一事件循环周期内对userId的多次修改，只会导致一次userProfile计算和一次effect执行，极大提升性能。
• 优先级调度：渲染相关的副作用（如更新DOM）可以被赋予更高的优先级，而日志、分析等副作用可以赋予较低优先级，确保用户交互的流畅性。
• 并发安全的基础：这种异步、可中断的调度模型，为未来实现类似React Concurrent Features的渲染中断/恢复打下了基础。

4. 从概念到实践：如何在代码中识别与运用V2思想

理解了理论，我们如何在具体的技术栈中看到V2双循环的身影呢？它往往不是以一个叫“V2”的库出现，而是作为一种设计理念融入现代工具中。

4.1 在React生态中的体现

• React自身（Concurrent Mode）：React Fiber架构本身就是一种先进的调度器。它将渲染工作分解为多个Fiber节点单元。useState、useReducer触发的状态更新会被创建为更新对象，放入更新队列。React调度器会协调这些更新，进行可中断的渲染。这里的“双循环”可以理解为：状态更新循环（创建更新、计算新状态）和提交循环（将计算好的变更副作用，如DOM更新，提交到浏览器）。useEffectHook的执行被明确安排在后一个循环（提交阶段之后），并且其清理和执行顺序被严格管理。
• Recoil / Jotai：这些原子化状态库完美体现了V2思想。
  • atom是原子状态。
  • selector是纯计算（对应计算循环），它派生自其他atom或selector。
  • useEffect或库提供的useAtom订阅，会触发组件重新渲染，渲染过程是同步的计算（执行函数组件），而真正的副作用（如数据获取，在selector的get函数中可能用Promise）会被库的调度机制管理，避免阻塞渲染。Jotai的useAtom内部就利用了React的调度来批量更新。

4.2 在Vue生态中的体现

• Vue 3 Reactivity +watchEffect：Vue 3的响应式系统本身是同步触发的（计算循环），但其watch和watchEffectAPI 在默认情况下，其回调的执行是被缓冲的。Vue 3的调度器（与组件渲染的scheduler关联）确保了多个状态变化在同一个“tick”中只触发一次侦听器，并且侦听器的执行时机可以通过flush: 'post'选项延迟到组件渲染之后（副作用循环）。这可以看作是一种轻量级的双循环分离。
• Vue Composables：鼓励你将响应式状态（ref、reactive）、纯计算（computed）和副作用（watch、生命周期钩子）在逻辑上组织在一起，但物理执行上通过Vue的运行时进行调度，也是一种最佳实践的体现。

4.3 在通用状态库中的体现

• MobX：早期的MobX（4及之前）更接近V1模式，reaction和autorun同步执行。MobX 6引入了reaction的fireImmediately选项和更好的事务支持，但其核心仍是同步反应。不过，通过配置或在React集成中使用useObserver，它可以借助React的调度来优化。
• Redux with Redux-Saga / Redux-Observable：Redux本身是单向数据流。Saga或Observable这些中间件，实际上创建了一个独立的“副作用循环”（Saga有自己的任务调度器，Observable基于RxJS的调度器），来监听action（状态变更意图），并管理复杂的异步流。这可以看作是一种宏观上的“双循环”架构：Redux Store更新循环 + Saga副作用循环。

5. 实战对比：用V1思维与V2思维解决同一个问题

让我们通过一个更复杂的场景来感受两种思维方式的差异：一个可搜索、可分页的用户列表。

需求：

1. 有一个搜索框，输入内容searchText。
2. 有一个分页参数page。
3. 当searchText或page变化时，需要去后端获取用户列表userList。
4. 在获取数据期间，显示加载状态isLoading。
5. 如果请求过快（如用户快速输入），应取消未完成的请求，避免陈旧数据覆盖新结果。

5.1 V1思维下的典型实现（以Vue Options API或早期React为例）

// Vue 2 Options API 风格 (V1思维) export default { data() { return { searchText: '', page: 1, userList: [], isLoading: false, currentRequest: null // 用于存储当前请求的取消令牌 }; }, watch: { // 监听搜索词和页码的变化 searchText() { this.page = 1; // 搜索词变化时重置页码 this.fetchUsers(); }, page() { this.fetchUsers(); } }, mounted() { this.fetchUsers(); }, methods: { async fetchUsers() { // 取消之前的请求 if (this.currentRequest) { this.currentRequest.cancel('Operation canceled due to new request.'); } this.isLoading = true; try { // 创建新的可取消请求 const request = axios.CancelToken.source(); this.currentRequest = request; const response = await axios.get('/api/users', { params: { search: this.searchText, page: this.page }, cancelToken: request.token }); this.userList = response.data; } catch (error) { if (!axios.isCancel(error)) { console.error('Fetch users failed:', error); } } finally { this.isLoading = false; // 如果当前请求已完成，清空引用 if (this.currentRequest && error?.message?.includes('cancel')) { this.currentRequest = null; } } } } };

V1模式的问题：

1. 逻辑分散：触发获取数据的逻辑分散在watch和mounted中。
2. 手动管理依赖：我们需要手动写watch来监听两个状态，并且还要处理searchText变化时重置page的联动逻辑。
3. 副作用与状态高度耦合：fetchUsers这个副作用方法直接修改了isLoading、userList、currentRequest等多个状态，并且包含了复杂的取消逻辑。这导致方法臃肿，难以测试。
4. 竞态条件风险：虽然我们实现了取消，但整个流程是命令式的，依赖于我们正确地维护currentRequest这个状态。在更复杂的场景下，容易出错。

5.2 V2思维下的实现（以Vue 3 Composition API + 类V2模式库为例）

这里我们使用一个假设的、具有V2双循环思想的库（灵感来自VueUse的useFetch或SolidJS的createResource）来演示：

// 使用 Composition API 与 响应式工具 (V2思维) import { ref, computed, watchEffect } from 'vue'; import { useFetch } from '@vueuse/core'; // 一个实现了良好副作用管理的工具 export function useUserList() { const searchText = ref(''); const page = ref(1); // 计算属性：派生出一个稳定的请求参数对象 // 这是“计算循环”的一部分，是纯的。 const fetchParams = computed(() => ({ search: searchText.value, page: page.value })); // 使用一个专门管理副作用的Hook // 它会自动响应 fetchParams 的变化，并处理取消、加载状态等。 const { data: userList, isLoading, error, execute } = useFetch( () => `/api/users?${new URLSearchParams(fetchParams.value)}`, { immediate: false, // 不立即执行，由 watchEffect 控制 refetch: true, // 当 fetchParams 变化时自动重新获取 // 该库内部应实现请求去抖和自动取消 } ).json(); // 一个“效应”，它描述了“当 fetchParams 变化时，应该执行 execute” // 这个 watchEffect 会被 Vue 的调度器管理，可能异步执行。 watchEffect(() => { // 这里只是触发执行，具体的副作用（网络请求）由 useFetch 管理 execute(); }); // 搜索词变化时重置页码的逻辑，也可以看作一个纯的、声明式的联动 watch(searchText, () => { page.value = 1; }); return { searchText, page, userList, isLoading, error }; }

V2模式的优势：

1. 关注点分离：
   • searchText和page是原始状态。
   • fetchParams是派生状态（计算循环），它纯粹由原始状态计算而来。
   • useFetch是一个副作用管理单元（副作用循环）。它接收一个信号（fetchParams变化或execute被调用），然后管理整个异步请求的生命周期（加载状态、数据、错误、取消）。
2. 声明式联动：watch(searchText, ...)声明了“当搜索词变化，页码重置为1”这个业务规则，清晰直观。
3. 副作用抽象：复杂的取消、去抖、错误处理逻辑被封装在useFetch内部。组件逻辑只需要关心“什么条件下需要获取数据”，而不需要关心“如何安全地获取数据”。
4. 更好的可测试性：你可以轻松地测试fetchParams的计算是否正确，也可以单独测试useFetch这个Hook（或模拟它），而不需要模拟整个组件和Axios。
5. 性能优化内置：像@vueuse/core的useFetch通常会内置防抖和自动取消功能，这是副作用调度循环带来的天然优势。

6. 深入原理：自己实现一个极简的V2双循环调度器

要真正吃透V2，最好的办法是动手实现一个微型版本。下面我们构建一个不到100行的、体现双循环核心思想的调度系统。

// mini-v2-scheduler.js // 1. 定义Fiber类型 class Fiber { constructor(task, deps = [], priority = 0) { this.task = task; // 要执行的任务函数 this.deps = new Set(deps); // 依赖的其他Fiber this.priority = priority; this._dirty = false; // 标记是否为脏，需要执行 } markDirty() { this._dirty = true; scheduler.schedule(this); } execute() { if (this._dirty) { this.task(); this._dirty = false; } } } // 2. 响应式系统核心 (简化版，模拟计算循环) const reactive = (initialValue) => { let value = initialValue; const dependents = new Set(); // 依赖此状态的Fiber集合 const getter = () => { // 当有活动的计算Fiber时，建立依赖关系 if (activeComputationFiber) { dependents.add(activeComputationFiber); activeComputationFiber.deps.add(dependents); // 双向记录，便于清理 } return value; }; const setter = (newValue) => { if (value !== newValue) { value = newValue; // 状态变化，标记所有依赖它的计算Fiber为脏 dependents.forEach(fiber => fiber.markDirty()); } }; return [getter, setter]; }; // 3. 调度器 (副作用循环的核心) class Scheduler { constructor() { this.taskQueue = []; // 简单的优先队列（简化，按优先级插入） this.isScheduled = false; } schedule(fiber) { // 将Fiber插入队列，按优先级排序（数字越小优先级越高） const index = this.taskQueue.findIndex(f => f.priority > fiber.priority); if (index === -1) { this.taskQueue.push(fiber); } else { this.taskQueue.splice(index, 0, fiber); } // 如果尚未安排刷新，则安排一个异步任务来执行队列 if (!this.isScheduled) { this.isScheduled = true; // 使用微任务模拟，实际中可能用 requestIdleCallback 等 Promise.resolve().then(() => this.flush()); } } flush() { this.isScheduled = false; const queue = this.taskQueue; this.taskQueue = []; // 清空当前队列 queue.forEach(fiber => fiber.execute()); } } const scheduler = new Scheduler(); let activeComputationFiber = null; // 4. 定义计算 (Computed) - 属于计算循环 function computed(getter) { const [get, set] = reactive(undefined); // 计算值本身也是一个响应式状态 const computeFiber = new Fiber(() => { const newValue = getter(); set(newValue); }, [], 1); // 计算任务优先级较高 // 首次计算，并收集依赖 activeComputationFiber = computeFiber; computeFiber.task(); activeComputationFiber = null; return get; // 返回一个只读的getter } // 5. 定义副作用 (Effect) - 属于副作用循环 function effect(fn, priority = 10) { const effectFiber = new Fiber(fn, [], priority); // 首次执行，也会收集依赖（如果fn内部读取了响应式状态） activeComputationFiber = effectFiber; fn(); activeComputationFiber = null; // 注意：effectFiber的依赖收集是为了当其依赖的状态变化时，能重新调度它。 // 但它本身被调度执行是在副作用循环中。 } // 6. 使用示例 console.log('=== 开始示例 ==='); const [count, setCount] = reactive(0); const double = computed(() => { console.log('计算 double'); return count() * 2; }); effect(() => { console.log('副作用：当前double值是', double()); }, 5); // 优先级5 effect(() => { console.log('低优先级副作用：计数是', count()); }, 15); // 优先级15 console.log('--- 第一次变更 ---'); setCount(5); // 触发更新 // 此时，double的计算Fiber和两个effect Fiber都被标记为dirty并加入调度队列。 // 调度器会在微任务中执行它们。 // 手动触发一下微任务，模拟事件循环 setTimeout(() => { console.log('--- 第二次变更 ---'); setCount(10); }, 0);

运行这段代码，你会看到输出顺序类似于：

=== 开始示例 === 计算 double 副作用：当前double值是 0 低优先级副作用：计数是 0 --- 第一次变更 --- 计算 double 副作用：当前double值是 10 低优先级副作用：计数是 5 --- 第二次变更 --- 计算 double 副作用：当前double值是 20 低优先级副作用：计数是 10

关键点解析：

1. 分离：computed创建的任务（计算double）和effect创建的任务，都被包装成Fiber。
2. 调度：当setCount被调用，它标记了依赖它的double计算Fiber和两个effect Fiber为dirty，并将它们交给scheduler。
3. 异步批量执行：scheduler将所有dirty的Fiber收集起来，在Promise.resolve().then()（微任务）中批量执行。这保证了在当前同步代码块执行完毕后，再统一更新。
4. 优先级：虽然我们的示例简单，但可以看到高优先级的effect（打印double）先于低优先级的effect（打印count）执行。在实际复杂的库中，优先级调度可以用于确保用户交互的响应速度。
5. 无循环风险：如果在effect中调用setCount，它只会调度新一轮的任务，而不会导致栈溢出，因为每一轮执行都是在一个干净的调用栈中由调度器发起的。

这个迷你实现省略了依赖清理、更复杂的优先级队列、错误处理、任务中断等生产级功能，但它清晰地勾勒出了V2双循环架构的骨架：响应式状态 -> 标记脏计算 -> 调度器异步执行计算和副作用。

7. 总结与选型建议

回顾V1到V2的演进，本质上是从“命令式、紧耦合”的副作用处理，走向“声明式、解耦、可调度”的架构。双循环模型不是银弹，但它为解决前端复杂状态下的可预测性、性能和开发者体验提供了坚实的理论基础。

何时选择V2思维/库？

• 应用复杂度高：状态之间存在大量派生关系，副作用繁多（数据获取、订阅、DOM操作等）。
• 对性能有要求：需要避免不必要的计算和渲染，实现细粒度更新和自动批处理。
• 追求更好的开发体验：希望代码更声明式、更易于测试和推理，减少由副作用顺序和竞态条件引发的bug。
• 考虑未来并发特性：如果你的技术栈（如React）或你期望的应用需要利用并发渲染（Concurrent Rendering）能力，那么基于可调度Fiber的V2架构几乎是必然选择。

一些具体的选型参考：

• React项目：拥抱Hooks本身就已蕴含V2思想。对于复杂状态，可选用Recoil,Jotai,Zustand（其最新版本也注重不可变和中间件调度）。useEffect+useState+Context对于中小项目足够，但需要开发者自己注意优化。
• Vue项目：Vue 3的响应式系统配合Composition API已是V2思维的优秀实践。对于复杂异步流，可以考虑VueUse等工具库提供的高阶Hook，或者使用Pinia管理状态，其action可以很好地组织异步逻辑。
• 框架无关或原生JS项目：可以考虑像MobX（需注意其默认同步）、RxJS（响应式编程的终极体现，学习曲线陡）或SolidJS这类将响应式作为一等公民的库。

最后，无论使用哪个库，理解V2双循环的思想都能让你更好地组织你的代码：尽可能将状态派生定义为纯计算（computed/selector），将副作用描述为对状态变化的反应（effect/watch），并信任底层框架或库的调度器去决定何时、以何种顺序执行它们。这会让你的应用逻辑像一台精密的钟表，各司其职，运行有序。