vue dom更新推迟到微任务末尾，通过事件循环实现异步批量更新；nexttick确保回调在更新后执行，老环境降级用settimeout。
事件循环直接决定了 Vue DOM 更新的时机和节奏。Vue 不是“立刻”更新 DOM，而是把更新任务塞进事件循环的特定队列里，等当前同步代码跑完、浏览器准备渲染前再统一执行——这个过程就是 Vue 异步更新策略的底层依据。
DOM 更新被推迟到微任务末尾
Vue 在检测到数据变化后，不会同步修改 DOM，而是把更新逻辑推入一个异步队列。这个队列的刷新时机，优先绑定在 微任务（MicroTask）末尾：比如 Promise.then、queueMicrotask 或 MutationObserver 的回调触发点。
这意味着：
- 同一轮事件循环中所有同步代码执行完后，会先清空全部微任务
- Vue 的 DOM 更新就安排在这一波微任务的最后一批里
- 此时 DOM 已完成重绘前的计算（如样式、布局），但页面尚未真正渲染
为什么不用宏任务（如 setTimeout）？
Vue 尽量避免用 setTimeout 等宏任务来触发更新，因为：
- 宏任务要等到下一轮事件循环才执行，延迟更长，用户感知卡顿
- 两次宏任务之间可能插入浏览器渲染，导致中间状态闪烁
- 无法保证与其它微任务（如组件内部 Promise 链）的执行顺序一致性
只有在不支持 Promise/MutationObserver 的老环境（如 IE），Vue 才降级使用 setTimeout。
nextTick 就是“排队等更新完成”
this.$nextTick() 并不是让 DOM 更新变快，而是让你的回调函数排在 Vue 更新 DOM 的那个微任务之后执行。所以它能拿到真实更新后的 DOM 结构和尺寸。
例如：
- 你改了
message，接着调用this.$nextTick(() => console.log(this.$el.textContent)) - 这个回调不会在赋值后立刻运行，而是在 Vue 内部把新
message渲染进 DOM 的那个微任务执行完后才触发 - 因此你读到的是刚写进去的新内容，不是旧值
批量更新靠的是“同一轮事件循环内去重”
如果你在一次 click 处理函数里连续改三次 count，Vue 不会触发三次 DOM 更新。它会在本轮事件循环中收集所有变更，合并为一次更新，并在本轮微任务末尾统一刷新。
这种机制依赖事件循环的“单次宏任务 + 全部微任务”结构：只要这些修改都在同一个同步上下文（比如一个方法体内）发生，它们就被视为“同一批”，从而被去重和合并。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
