17370845950

本文深入解析 svelte `#each` 块的更新逻辑，阐明为何传递整个对象会导致不必要的组件重渲染，并给出基于键控（keyed）语义、引用比较机制和 props 设计的最佳实践。

在 Svelte 中，{#each} 块的更新行为既高效又微妙——它并非简单地“重绘整个列表”，而是依托键控（keyed）语义与细粒度的 prop 变更检测协同工作。理解其底层机制，是写出高性能、可预测组件的关键。

? 键控（key）决定 DOM 节点复用，而非组件是否更新

你为 #each 指定的 key（如 (thing.id)）仅用于 DOM 节点的映射与复用：Svelte 会根据 key 将旧节点与新数据项进行匹配，避免无谓的节点销毁与重建。但 key 不控制子组件内部是否触发更新。组件是否重运行 beforeUpdate/afterUpdate、是否重新计算响应式声明，完全取决于其 接收的 props 是否被判定为“已变更”。

? Prop 变更判定：浅层引用比较，无深等于

Svelte 对 props 的变更检测是浅层的引用比较（shallow reference check），而非深度值比较（deep equality）。这意味着：

• ✅ name={thing.name}（字符串）：若 thing.name 值未变（如仍为 'apple'），且 thing 对象本身未被替换，Svelte 判定该 prop 未变，跳过对应 的更新。
• ❌ name={thing}（对象）：即使 thing.id 和 thing.name 完全相同，只要 thing 是一个新创建的对象引用（例如 slice() 返回新数组时，其中每个元素都是原对象的引用副本，但数组本身是新引用），Svelte 就认为 name prop 已变 —— 因为 oldName !== newName（两个不同内存地址的对象）。

这正是你观察到 beforeUpdate/afterUpdate 总是被调用的根本原因：things.slice(1) 创建了一个新数组，其内部对象虽内容相同，但数组引用变了 → #each 块内每个 都接收到一个“新”的 thing 引用 → 所有子组件均被标记为需更新。

? 正确实践：精准传参 + 合理使用 key

避免不必要更新的核心原则是：让 props 的变更信号真正反映业务意图。

✅ 推荐方式：按需解构，传递原子值

{#each things as thing (thing.id)}
  
  
{/each}

此时，只要 thing.name 和 thing.id 的值不变，Svelte 就不会触发该 实例的更新周期，即使父数组被 slice、filter 或 map 重构。

⚠️ 若必须传对象：确保引用稳定

仅在以下场景考虑传整个对象，并务必保证引用不意外变更：

• 对象由 store 管理且状态不可变（如 writable({}) 配合 update）；
• 使用 Object.freeze() 或 Immutable.js 等库固化引用；
• 在 #each 外预处理，缓存对象引用（不推荐，易出错）。

? 不推荐：盲目传大对象或频繁变更对象

这不仅引发冗余更新，还降低代码可读性（调用方无法一眼看出组件依赖哪些字段），并可能因对象深层嵌套导致意外响应式失效。

? 补充说明：编译后的 p(ctx, [dirty]) 函数

你看到的编译输出 p(ctx, [dirty]) 是 Svelte 的更新函数（patch function），负责将变更同步到 DOM。其逻辑类似：

p(ctx, [dirty]) {
  // dirty & 1 表示 'name' prop 所在的位掩码被标记为脏
  // ctx[0].name 是当前 props 中的 name 值
  if (dirty & /*name*/ 1) {
    const newValue = /*name*/ ctx[0].name;
    // 若 newValue 是对象，此处比较的是引用！
    if (oldValue !== newValue) {
      // 触发 DOM 更新（如 set_data）
    }
  }
}

可见，p 函数本身不执行深比较；它信任 dirty 标志 —— 而 dirty 标志的设置，正源于前述的引用比较。

✅ 总结：三步保障高效更新

1. 始终为 #each 指定稳定、唯一、不可变的 key（如 thing.id），确保 DOM 节点正确复用；
2. 子组件 export let 的 props 应尽可能原子化（字符串、数字、布尔值），避免传递整个对象，除非有强理由且能保证引用稳定；
3. 理解 Svelte 的响应式本质：它是基于引用的、编译时静态分析的高效系统，而非运行时动态深比较 —— 设计时需顺应此范式，而非对抗它。

遵循以上原则，你的列表交互将既流畅又可预测，彻底告别“明明没改内容却疯狂重渲染”的困扰。