fragment patch逻辑更复杂，根本原因在于它无真实dom节点却需精确维护子节点物理顺序与边界，迫使渲染器以兄弟锚点替代父容器定位，动态推导anchor并解耦子节点生命周期，导致transition-group动画和ref绑定受限。

Fragment 节点的 Patch 逻辑更复杂，根本原因在于它不对应任何真实 DOM 元素，却要精确维护多个子节点在页面中的物理顺序、插入位置和更新边界——这打破了“一个 vnode 对应一个 el”的传统映射关系，迫使渲染器重新设计整套协调机制。

没有父容器锚点，移动操作失去参照系

普通元素 patch 时，移动节点可直接调用 parentNode.insertBefore(el, refNode)，依赖父容器定位。但 Fragment 没有 el、没有 parentNode，所有子节点的插入和移动必须靠“兄弟锚点”驱动：

• 每个子节点的插入位置，由它在新顺序中“前一个兄弟节点”的 DOM 元素决定（即 anchor）
• 首个子节点的 anchor 是 null，需回退到 Fragment 的父级上下文（如父组件的 nextSibling）来确定起始位置
• 这个 anchor 不是静态属性，而是在 diff 过程中通过 最长递增子序列（LIS）算法动态推导出来的，确保移动顺序满足拓扑约束，避免中间状态错乱

子节点生命周期与 Fragment 实例解耦

Fragment 自身不可挂载、不可卸载、不参与属性或文本更新，但它必须精准同步子节点的状态：

• process 函数跳过所有 hostPatchProp、hostSetElementText 等操作，只做三件事：patch 子节点、更新 anchor、更新 endAnchor
• 当子节点从空数组变为非空时，需按序逐个 patch 并设置 anchor；从非空变为空时，需遍历 unmount 所有旧子节点
• anchor 和 endAnchor 不是 DOM 节点，而是指向子节点链表首尾的引用，且需在每次 patch 后显式维护，否则后续插入会失位

Diff 策略无法复用标准双端对比

常规元素的子节点 diff 使用双端+key 映射，依赖父容器统一管理插入/移动范围。Fragment 则面临额外约束：

• 新增节点不能简单 append 到父容器末尾，必须插在指定 anchor 之后，否则会破坏兄弟顺序
• 删除节点不能仅靠 unmount，还需清理其前后 anchor 关系，防止残留引用导致后续 patch 锚点错位
• 重排序场景下，节点复用与移动必须严格按新索引顺序执行，否则因无容器隔离，一个节点插错位置会影响后续所有兄弟节点的相对位置

对上层能力形成天然限制

这种底层协调方式虽高效，但也让某些高级功能难以直接支持：

• transition-group 动画受限：动画依赖节点的插入/移除钩子，但 Fragment 子节点的 mount/unmount 不经过 Fragment 自身，导致 enter/leave 钩子无法统一触发
• ref 绑定语义模糊：模板中写 <template><div ref="a"></div> <p ref="b"></p></template>，ref 指向的是子节点，但 Fragment 实例没有 el 可代理，无法提供统一 ref 容器
• 第三方 DOM 库兼容风险：依赖组件有唯一根节点的库（如某些表单校验、无障碍工具），可能无法正确识别 Fragment 组件的 DOM 边界