一、引言：前端渲染的核心矛盾与范式变革
前端开发中，最让人头大的莫过于 “状态变了，UI 却没更” 或者 “状态只改了一点点，UI 却全家老小齐上阵重新渲染”。说白了，框架的终极目标就是把 “状态变化” 和 “UI 更新” 精准绑定，既不遗漏也不浪费。
以前我们还在琢磨 “怎么防止无用渲染”，现在信号驱动直接把思路拔高到 “只触发有用渲染”—— 这波变革可不是小打小闹。
今天咱不聊选型、不堆术语，就像拆解 flex 属性那样，把状态驱动和信号驱动的底层逻辑扒得明明白白，看看从状态更新到 UI 变化，这俩货到底走了啥不一样的路子。
二、状态驱动渲染：组件级全量渲染的工作流（以 React 为例）
状态驱动这玩意儿，说通俗点就是 “状态在哪定义，就从哪炸开花式渲染”，典型代表就是 React Hooks 和 Vue 2。咱以 React 为例，一步步看看它是怎么干活的：
1. 核心定义：广撒网式的渲染逻辑
状态驱动就像公司发通知，不管你是不是相关人，先把通知群发给整个部门，再让大家自己判断要不要执行 —— 组件里的状态一变，就触发整个组件及其所有子组件重新渲染，最后靠虚拟 DOM Diff 筛选出有用的更新。
2. 具体执行全流程
先上一段简单代码，咱跟着代码走流程：
现在点击按钮改 count，React 的操作流程是这样的：
- 步骤 1：
useState初始化时，会把 count 状态绑定到当前组件的 Fiber 节点上（你可以理解为给组件办了张身份证，状态就存在身份证里）。 - 步骤 2：点击按钮触发
setCount，React 一看 “身份证” 对应的组件状态变了，就给这个 Fiber 节点打个 “脏标记”—— 相当于给组件贴了张 “需要重新渲染” 的便利贴。 - 步骤 3：React 的调度器看到便利贴，就把这个 “脏组件”（Parent）加入渲染队列，等时机到了就触发重渲染。
- 步骤 4：从 Parent 开始，不管子组件需不需要，递归遍历所有子组件（ChildA 和 ChildB），给每个组件都生成一棵新的虚拟 DOM 树 —— 这一步就像公司发通知，不管你要不要，先把文件发你邮箱。
- 步骤 5：React 拿着新的虚拟 DOM 树和旧的对比（也就是 Diff），发现 “ChildA 的虚拟 DOM 没变化，ChildB 的虚拟 DOM 里 count 变了”，筛选出只有 ChildB 需要更新的 “补丁”。
- 步骤 6：最后把这个 “补丁” 应用到真实 DOM 上，只有 ChildB 的 UI 更新了，ChildA 虽然参与了遍历和 Diff，但最终没变化。
3. 固有痛点：冗余渲染的根源
你看，明明 ChildA 和 count 没啥关系，却还是被迫参与了 “生成虚拟 DOM” 和 “Diff 对比” 这俩步骤 —— 这就是状态驱动的核心痛点：冗余渲染。就像公司发无关通知，你虽然不用执行，但还是得花时间看一眼判断要不要做，纯属浪费精力。
也正因为这个痛点，React 才需要React.memo、useCallback这些 “补丁工具” 来优化。
三、信号驱动渲染：细粒度精准更新的工作流（以 Preact Signals 为例）
信号驱动就不一样了，它是 “状态谁用了，就只通知谁”，精准打击不浪费，典型代表是 Solid.js、Preact Signals 和 Vue 3。咱用 Preact Signals 举例，看看它的骚操作：
1. 核心定义：精准 @相关人的渲染逻辑
信号驱动相当于公司发通知，直接 @具体负责人，其他人连通知都看不到 —— 状态被包装成 “信号”，只有用到这个信号的组件才会被通知更新，其他组件完全无感。
2. 具体执行全流程
还是刚才的场景，用 Preact Signals 改写代码：
点击按钮改 count，信号驱动的流程是这样的：
- 步骤 1：
useSignal创建信号时，会生成一个 “数据容器 + 依赖列表” 的组合体 —— 相当于给 count 装了个智能盒子，盒子里除了存着 0 这个值，还能记着 “谁用过我”。 - 步骤 2：组件首次渲染时，ChildB 读取了
count.value，智能盒子立刻把 ChildB 记到依赖列表里 —— 这就是 “订阅”，相当于 ChildB 告诉盒子：“我用着你呢，变了记得叫我”。而 ChildA 没读 count，所以不会被记录。 - 步骤 3：点击按钮让
count.value++，智能盒子里的数据立刻更新成 1。 - 步骤 4：智能盒子遍历依赖列表，发现只有 ChildB 订阅了，就只给 ChildB 发 “更新通知”—— 其他组件连消息都收不到。
- 步骤 5：只有 ChildB 收到通知，重新渲染并直接更新对应的真实 DOM 节点，全程没有虚拟 DOM 全量 Diff，也没有遍历其他组件。
- 步骤 6：ChildA 完全没参与任何流程，控制台里 “ChildA 渲染了” 只会在首次渲染时打印一次，之后再也不会触发 —— 这就是零冗余渲染。
3. 核心优势：零冗余渲染的底层原因
信号驱动之所以能做到无冗余，核心就是 “订阅 - 通知” 模型：只通知用到状态的组件，而且直接操作真实 DOM，跳过了 “全量生成虚拟 DOM” 和 “Diff 对比” 这俩耗时步骤。就像快递直接送到收件人手里，不用先送到小区门口再挨个通知取件，效率自然高.
四、两种范式的关键差异对比
| 对比维度 | 状态驱动（React） | 信号驱动（Preact Signals） |
|---|---|---|
| 渲染触发逻辑 | 状态创建处→整棵子树（广撒网） | 状态使用处→仅订阅组件（精准打击） |
| 依赖管理方式 | 无自动依赖，需手动标记（memo 等） | 自动依赖追踪（订阅 - 通知模型） |
| 核心中间层 | 虚拟 DOM（必须 Diff 筛选更新） | 无 / 弱依赖虚拟 DOM（直接操作 DOM） |
| 执行开销来源 | 子树遍历 + Diff 计算（浪费在筛选上） | 依赖列表维护（开销可忽略） |
| 典型框架 | React、Vue 2 | Solid.js、Preact Signals、Vue 3 |
再用通俗比喻总结下：
- 状态驱动：班级通知，老师在群里发消息，全班同学都得看一眼，判断是不是跟自己有关；
- 信号驱动：私人微信，老师只把消息发给需要的同学，其他人完全不知道有这回事。
五、总结：两种范式的本质区别
状态驱动是 “先全量触发，再筛选有用更新”，就像筛沙子，先把所有沙子都倒出来，再把没用的筛掉，难免浪费力气；
信号驱动是 “只触发有用更新，跳过所有冗余步骤”，就像精准挖矿，直接冲着金矿去，不做无用功。
看到这可能有人会问：既然信号驱动这么牛，那虚拟 DOM 还有存在的必要吗？是不是以后都不用学 React 的优化手段了？
别急，下一篇咱就聊聊这个话题 —— 信号驱动时代，虚拟 DOM 真的过时了吗？它那些不可替代的价值，信号驱动还真学不来～
