DOM更新必须先更新父节点属性（Prop）再更新子内容（Children），因为Prop决定节点身份与行为边界，是children更新的上下文前提；如class、key、事件绑定等未就位，会导致闪动、复用失效、事件丢失或无效渲染。
因为 DOM 节点的属性（Prop）决定了该节点的“身份”和“行为边界”，而子内容（Children）的更新依赖于这个边界是否稳定。先确保父节点本身已正确配置（比如 class、style、事件绑定、是否禁用等），再处理内部结构，才能避免误删、重复挂载或事件丢失等问题。
Prop 是节点的“基础配置”，必须优先就位
一个 DOM 元素能否正常显示、响应、参与布局，首先取决于它的属性：
- class / style 影响样式层叠与渲染结果，若延迟更新，可能造成闪动或错位
- id / key / ref 关系到 diff 的节点复用逻辑，不先对齐，后续 children 对比就失去锚点
- onXXX 事件 若在 children 更新后才绑定，中间触发的用户操作可能被丢弃
- disabled / hidden / contenteditable 等布尔属性，直接控制子内容是否可交互或是否参与渲染流程
Children 更新需要 Prop 提供的上下文保障
patchChildren 的执行方式（比如文本替换、节点移动、key-based 复用）都建立在父容器“状态可信”的前提下：
- 如果父节点的 display: none 属性还没设上，却提前清空了 innerHTML，浏览器仍会尝试渲染子树，造成无效计算
- 若 v-show 对应的 style 还没更新，patchChildren 却按“显示”逻辑执行，会导致 DOM 不一致
- 使用 key 进行列表 diff 时，需依赖父节点的 props 是否已反映最新 key 映射关系，否则移动/复用逻辑失效
符合真实 DOM 操作的自然顺序
浏览器本身也是“先建壳，再填瓤”：
- createElement 创建元素后，通常立即 setAttribute 或赋值 property
- 再调用 appendChild / setTextContent 填充内容
- 渲染器模拟这一过程，既降低实现复杂度，也更贴近底层行为，减少意外副作用
这不是硬性规定，而是权衡可维护性、稳定性与性能后的合理约定。Vue 和 React 的核心 renderer 都遵循这一顺序，本质是让更新流从外向内、由静到动、由配置到内容逐层收敛。
