svelte 在 `#each` 块中通过 key 判断元素复用性，但组件是否重渲染取决于 props 引用是否变化——传递整个对象会导致频繁更新，因 `slice()` 生成新引用；推荐按需解构传值以提升性能和可预测性。
在 Svelte 中，{#each} 块的更新行为由两个正交机制共同决定：DOM 元素的复用策略（key 控制） 和 组件实例的响应式更新（props 变更检测）。二者常被混淆，但理解其分工是优化渲染性能的关键。
✅ Key 的作用：控制 DOM 节点复用（不触发组件重初始化）
当你写 {#each things as thing (thing.id)} 时，Svelte 使用 thing.id 作为唯一标识符，在数组变更（如 slice(1)）后：
- ID 为 2 的项从索引 1 移至 0，Svelte 复用其对应的
DOM 节点； - ID 为 1 的项被移除，对应节点被卸载；
-
关键点：
组件实例本身未被销毁重建，而是继续存在——但它的 name prop 会被重新赋值。
❌ Prop 更新触发重渲染：引用变化即视为“变更”
Svelte 的响应式更新不进行深比较（deep equality），而是基于 引用相等性（===） 检测 prop 变化。你使用 things.slice(1) 时：
// 原数组：[{id:1,name:'apple'}, {id:2,name:'banana'}, ...]
// slice(1) 后：[{id:2,name:'banana'}, {id:3,name:'carrot'}, ...]
// → 新数组中每个对象都是*新引用*（即使内容相同）因此，即使 thing.id === 2 和 thing.name === 'banana' 未变，name={thing} 中的 thing 引用已不同，Svelte 认定 name prop 发生变更，进而触发 beforeUpdate/afterUpdate 生命周期，并执行 p(ctx, [dirty]) 中的更新逻辑（如 set_data(t2, t2_value)）。
这正是你观察到“每次点击都打印日志”的根本原因——不是 DOM 重建，而是组件响应了 prop 引用变更。
✅ 正确实践：按需传递原子值，避免冗余引用变更
{#each things as thing (thing.id)}
此时，若 thing.name 和 thing.id 值未变（如仅删除首项），Svelte 编译后的 p() 函数会跳过 DOM 更新：
p(ctx, [dirty]) {
if (dirty & /*name*/ 1 && t2_value !== (t2_value = /*name*/ ctx[0].name + ""))
set_data(t2, t2_value);
// ✅ 仅当 name 字符串值真正变化时才执行
}⚠️ 注意事项与进阶建议
- 对象传参并非绝对禁止：若组件需响应对象内部深层变化（配合 $: 声明式语句或 bind:this），且你明确控制引用稳定性（如用 immer 或 structuredClone），仍可接受。但需主动管理。
- 性能敏感场景：对长列表或高频更新，可结合 bind:this + 手动 $$invalidate() 精准控制，或使用 store 封装状态。
- 调试技巧：启用 Svelte DevTools，观察组件 props 面板中值旁的 → 图标——闪烁表示引用变更；或在 beforeUpdate 中打印 Object.is(oldName, newName) 验证。
归根结底，Svelte 的设计哲学是 “最小化不可见开销”：它不替你做昂贵的深比较，而是将决策权交给开发者——通过合理拆分 props、稳定数据引用，你既能获得接近原生 DOM 的性能，又能保持代码的清晰与可控。
