4.1 直通DOM的更新策略：细粒度绑定对照diff对账

4.1 直通 DOM 的更新策略：细粒度绑定对照 diff 对账

本节摘要：「对账」是虚拟 DOM 框架的核心动作：重新描述整个界面，与上一份描述逐节点比较，把差异提交为补丁。Solid 删掉的就是这个动作——表达式位置在编译期已被登记为绑定，信号变化时绑定函数直接写入目标节点。本节用一个"大表格里改一个单元格"的场景走完两条路径，并对照 js-framework-benchmark 的量级数字。

对账（reconciliation）这个词借自会计：期末把两本账逐条核对，找出差异。React 每次状态变化都在做这件事——组件树重跑生成新的虚拟 DOM（新账），与旧虚拟 DOM（旧账）逐节点比对，差异记为补丁队列，最后批量提交。整个流程的成立前提是"每次都重新生成完整的新账"，这保证了模型的简单：开发者永远描述完整界面，框架负责找不同。

一个场景走完两条路径

需求：一张两百行的订单表，每行十格。用户在第一行点"同意"，第一行的状态格从"待审"变成"已通过"。先走 React 路径：

1. setStatus 触发该行所在组件子树的重渲染
2. 组件函数重新执行，产出新的元素对象树
3. 协调器遍历新旧两棵描述树逐节点比对
4. 比对结果：只有一个文本节点变了
5. 提交阶段：改写那一个真实 DOM 文本节点
​

第 5 步说明 React 的 DOM 操作本身并不低效——优化十年之后，补丁提交非常精准。开销在第 2 到 4 步：重新执行组件函数、重建对象树、遍历比对，这三步的工作量与"变化的规模"无关，与"界面的规模"成正比。界面越大，为了改一个字要做的无用功越多。

Solid 路径：

1. setStatus 写入信号
2. 信号沿订阅关系找到"状态格文本"这一个绑定
3. 绑定函数执行，比对前后值，写入那个文本节点
4. 结束
​

路径里没有"重新执行组件"，没有"重建描述"，没有"遍历比对"——工作量与界面规模无关，只与"变化的粒度"有关。两百行还是两万行，改一个单元格的成本相同，这是细粒度三个字的工程含义。

图：更新路径对照——重描述对账与沿图投放

基准里的量级感

js-framework-benchmark 用增删改选交换清空这类标准操作测各框架相对原生 JavaScript 的耗时倍率。量级参照：Solid 的几何均值常年落在 1.1 前后的第一梯队，与 Svelte、Vanillajs 的差距在测量误差边缘；React（hooks 版本）通常在 1.4 到 1.6 区间。换成人话：这批标准操作跑下来，Solid 花的时间接近原生手写 DOM 操作，React 大约多出四到六成。内存维度差距类似——初始化内存与持续更新后的增量，Solid 都明显低于 React。这些数字不是让团队按小数点后一位选型用的，它们的价值是验证结构判断：省掉对账环节，基准里差距最大的操作恰恰是局部更新、行交换、批量删除这类"界面大、变化小"的场景。

⚠️ 反过来说也有代价：没有虚拟 DOM 兜底，意味着没有"反正 diff 会帮我找对"的安全网。绑定没建立（读错了上下文、解构了 props），更新就真的不会发生，而且不会报错。写 Solid 的正确姿势是理解追踪规则，而不是依赖运行时纠错——第 8 章的反模式清单会系统整理这类"静默失效"。

组件级优化动作的集体作废

理解了路径差异，React 时代的一批优化动作可以整体归档了：React.memo 防的是"父组件重渲染拖累子组件"，Solid 没有重渲染；useMemo/useCallback 稳的是引用，Solid 不靠引用触发更新；key 服务于对账时的节点匹配，Solid 的列表跟踪不经过对账。这些动作不是"没必要"，是"要解决的问题不存在"。团队的迁移培训里，把这一页放在最前面讲，能省下大量"在 Solid 里找 memo 在哪"的无效摸索。

一次真实测量：性能面板里的两条时间线

结构分析之后，给一次可复现的测量增强体感。场景：一个两百行、每行十格的表格，每行有一个"通过"按钮，点击改本行状态格。在两个框架分别实现，打开性能面板录制约十秒的连续点击。

React 时间线：每次点击产生一段约几毫秒的脚本任务，任务内部是组件函数重执行与对账，脚本耗时随表格规模线性爬升——把表格扩到五百行，同样的点击脚本耗时接近翻倍；内存图上呈现规律的锯齿，那是每轮描述树对象的新生代分配与回收。Solid 时间线：每次点击的任务短促且稳定，脚本耗时在两百行与五百行两种规模下几乎读不出差别——因为任务里只有"改一个文本节点"；内存曲线平直，没有周期性尖峰。

这组测量说明两件事。其一，框架差距不是玄学，它精确落在"随界面规模增长的那部分开销"上。其二，绝对数字要冷静：单次点击的差异是毫秒级，只有高频交互或低端设备才把它放大成体感。性能优化的决策依据应该是自己应用的测量，本节给的量级只负责告诉你差距会出现在哪里。

问题：细粒度在什么场景优势最小？

两个场景。静态为主的展示页：内容渲染一次之后几乎不更新，直改路径没有用武之地，框架差异趋近于零。极端动态的全屏动画：瓶颈在排版与合成而非脚本，此时决定帧率的是样式写法与合成层管理，换框架无感。把这两端排除后，中间的大多数业务界面——表单、表格、列表、面板——才是细粒度模型的收货区，这也和基准测试的分桶结论互相印证。

本节要点回顾

• 对账是需要供养的流程：重跑、重建、比对三步的开销与界面规模成正比。
• 直通是按图投放：绑定在编译期登记，更新成本只与变化粒度相关。
• 基准验证结构：局部更新类操作的倍率差距最大，1.1 前后对 1.4 到 1.6 是典型量级。
• 安全网换了形态：没有 diff 兜底，静默失效要靠理解规则来防。

给"描述式心智"留的桥

从 React 过来的工程师偶尔回怀念"界面永远是状态的完整函数"这条铁律——它保证了任意时刻看代码就能推知界面。Solid 并没有抛弃这条铁律，只是把它下沉了一层：每个绑定函数本身就是"状态到节点"的小型纯函数，全界面是这些小函数的拼合。读代码时推理单元从"组件"缩小到"表达式"，起初不习惯，习惯之后推理反而更省力——你不再需要区分"这段代码在挂载时执行还是更新时执行"，因为每个表达式只有一种行为。团队迁移培训里，用这个桥接说法讲心智切换，接受度普遍好于"彻底忘掉 React"式的口号。

下一章打开盒子：编译器、内核、运行时三层如何协作，把这条短路径支撑起来。