高性能UI渲染的核心思路在于：一次性渲染大量DOM元素会导致主线程阻塞，用户体验严重下降。解决这一问题的朴素方法是将大任务拆分为多个小批次，分批提交给浏览器，让浏览器在每轮渲染间隙能够处理用户点击、滚动等交互。下图直观展示了这种分批执行策略的节奏感：
简言之，就是将原本一次性完成的渲染工作拆解成若干小批次，使浏览器每完成一个小批次就有机会刷新样式、响应事件。这样主线程不会长时间被占用，页面保持流畅响应。
使用 setTimeout 分批插入 DOM
这是最轻量且通用的方案。关键不在于延迟的具体毫秒数，而是通过 setTimeout(fn, 0) 将渲染任务推入下一个宏任务队列，让当前帧提前释放出来。
- 每次仅生成并插入固定数量的元素（例如20到50条），过多仍会导致阻塞。
- 配合 DocumentFragment 批量暂存节点，最后一次性挂载到真实DOM上，显著减少重排次数。
- 递归调用时直接使用
setTimeout(fn, 0)，不设置具体时间值，完全交给事件循环调度。
使用 requestAnimationFrame 控制渲染节奏
若涉及动画或滚动场景，requestAnimationFrame 更为合适。它能与屏幕刷新率同步（大约每16.7ms一帧），视觉表现更顺滑，不会像 setTimeout 那样可能出现偏移。
- 在
requestAnimationFrame回调中执行单批次渲染。 - 配合节流逻辑：若上一批刚完成且距离下一帧还有余量则继续，否则等待下一帧再处理。
- 比
setTimeout更精确，但需注意回调中不能执行耗时计算，否则会导致该帧卡顿。
结合状态管理控制渲染进度
最忌讳的是“一口气完成”或“中间卡住”。必须清晰规划起始、分片、结束的逻辑。
- 维护好 当前索引 和 总条数，每次只推进固定偏移量。
- 渲染前检查是否已被终止（例如用户切换页面或取消操作），避免无效工作。
- 可加入加载提示，如每完成一批后更新进度条或显示“已加载 X / 总条数”。
避开常见陷阱
分片本身并不等同于性能提升，错误的方法反而会加重负担。以下陷阱需特别留意：
- 不要在循环中直接
appendChild到真实DOM——每次操作都会触发重排，分片反而更慢。 - 批次大小不宜过大（例如一次插入100条），20到50是比较平衡的区间。
- 不要用
setInterval简单轮询，它不关心上一轮渲染是否完成，容易造成任务堆积。 - 若数据量极大（如50万条以上），建议配合虚拟滚动，仅渲染可视区域——分片加虚拟滚动才是完整方案。
