React 中的信号（三）：生命周期从未消失

生命周期从未消失

从本系列的开篇到当前的实现，一切始终围绕着数据层的生命周期展开：

数据如何被读取、失效、重新计算，以及副作用何时被触发。

这与框架自身的生命周期并不冲突。事实上，React 从未移除生命周期——它只是将其重构为两个截然不同的阶段：

• 渲染（Render）：纯粹用于计算用户界面。该阶段可能多次运行，也可能被中断或丢弃。理想情况下，此处不应发生任何副作用。
• 提交（Commit）：以单次同步步骤将变更应用到 DOM。useLayoutEffect / useEffect 的设置与清理逻辑在此阶段执行。这是唯一合法的用户界面副作用执行位置。

如果你不熟悉 useLayoutEffect 和 useEffect，请回顾 React 如何通过这些钩子管理组件挂载/卸载的时机。这一理解是基础中的基础。

React 强调，在典型用法中，用户界面对状态的依赖关系并未显式声明。当状态更新时，React 会重新运行组件的渲染函数，并利用虚拟 DOM（VDOM）比对来确定最小的 DOM 变更。子树是否更新，则取决于跳过更新（bailout）和记忆化（memoization）策略。

而信号（Signals）则采取了另一条路径：显式的依赖图。

系统明确知道谁依赖于谁，从而实现精准的更新传播。一个调度器（例如微任务批处理）控制副作用的执行时机。

这两种方法看似不同，但都严格管理着生命周期边界：

• React 通过渲染/提交边界保护副作用的执行时机。
• 信号则通过失效、重新计算和订阅边界管理数据的生命周期。

生命周期从未消失——它只是存在于不同的抽象层级之中。

本文目标

我们清晰地划分了职责：

• 与用户界面相关的副作用（DOM 测量、操作、动画）→ 由 React 处理（useLayoutEffect / useEffect）
• 数据流相关的副作用（由信号或计算值变化触发的业务逻辑）→ 由信号处理（createEffect，其生命周期由我们的适配器管理）
• 渲染必须保持纯净——在渲染过程中不得调用 signal.set() 或创建外部副作用。

时序概览：谁先运行？谁先清理？

React 的副作用清理（useEffect / useLayoutEffect）在下一次提交之前执行。

我们的信号副作用清理（onCleanup）则在同一批微任务内重新执行之前运行。

二者独立运作，互不冲突。

职责分离