Snabbdom 默认采用自顶向下的 DOM diff 算法，当向 <table> 开头插入 <tr> 时，因子节点索引偏移导致所有后续 <tr> 被视为“位置变更”，从而强制重新创建——这并非 bug，而是其 patch 机制的固有行为。

snabbdom 默认采用自顶向下的 dom diff 算法，当向 `

` 开头插入 `` 时，因子节点索引偏移导致所有后续 `` 被视为“位置变更”，从而强制重新创建——这并非 bug，而是其 patch 机制的固有行为。

Snabbdom 的核心 patch 逻辑（见 src/init.ts 中 patchVNodes 函数）按顺序逐一对比新旧 vnode 子节点数组：它假设相同索引位置的 vnode 应映射到同一 DOM 节点。因此，当你在 <tbody> 或 <table> 开头插入一个新 <tr>，原第 0 个 <tr> 变为第 1 个，第 1 个变为第 2 个……Snabbdom 无法通过 key 之外的手段识别“位移”，于是对每个后续节点执行 updateNode → patch → 最终调用 createElm 重建整个 DOM 元素——即使其 vnode 内容完全未变。

✅ 正确解法：为每个 <tr> 显式指定唯一且稳定的 key 属性：

import { h } from 'snabbdom';

const rows = [
  { id: 'user-1', name: 'Alice' },
  { id: 'user-2', name: 'Bob' }
];

const renderTable = () => h('table', [
  h('tbody', rows.map(row => 
    h('tr', { key: row.id }, [
      h('td', row.name)
    ])
  ))
]);

只要 key 值稳定（如基于业务 ID），Snabbdom 的 updateChildren 算法就能通过 key map 快速定位对应节点，实现精准复用——无论插入头部、尾部或中间，均只更新/新增/删除必要节点，其余 <tr> 完全跳过重渲染。

⚠️ 注意事项：

• ❌ 不要使用数组索引（如 index）作为 key，否则插入首行会导致全部 key 失效；
• ✅ <tr> 必须直接作为 <tbody>（或 <table>）的子节点；若包裹在 <Fragment> 或其他非标准容器中，key 将失效；
• ? 调试建议：启用 snabbdom/modules/props 并在 vnode 上添加 data: { key: 'xxx' } 后，用浏览器 DevTools 检查实际生成 DOM 是否携带 data-key 属性，验证 key 是否生效；
• ? <thead> / <tfoot> 中的 <tr> 需单独管理 key，不可与 <tbody> 混用同一 key 空间。

总结：Snabbdom 的“首行插入引发全量重绘”本质是 key 缺失下的预期行为。赋予每个可变 <tr> 稳定 key 是唯一符合框架设计哲学的解决方案——它不修改 diff 算法，而是让算法正确识别节点身份，从而释放其增量更新能力。