分片处理巨量数据的核心是保障主线程响应性，通过时间切块（每块10–30ms）实现可中断、可让步、可延续；依操作类型动态控量：纯计算500–2000项，轻量DOM读取限50–100项。
用分片处理巨量数据，核心是不让单次执行耗尽主线程，保证浏览器能及时响应用户操作和渲染帧。不是让计算变快，而是让它“可中断、可让步、可延续”。
按时间切块，别按数量硬分
目标是每块执行控制在 10–30ms 内，避免触发浏览器 long task 标记。靠 performance.now() 实时监控已用时间，而不是固定每次处理 1000 条：
- 纯计算（如格式化、校验）：每轮最多跑 500–2000 项，视单条复杂度动态调整
- 含轻量 DOM 读取（如 getBoundingClientRect）：压到 50–100 项以内
- 避免写 for (let i = 0; i 这种一气呵成的循环
选对调度时机：raf / setTimeout / queueMicrotask
不同场景匹配不同调度方式：
- requestAnimationFrame：适合边算边更新 UI 的场景，比如实时进度条、滚动锚点计算、动画关键帧生成。天然对齐刷新周期，不丢帧
- setTimeout(0) 或 queueMicrotask：适合后台型任务，不要求视觉同步但必须让出主线程。比 setTimeout(0) 更及时的是 queueMicrotask，它在当前宏任务末尾、渲染前执行
- 慎用 requestIdleCallback：兼容性有限，且空闲时间不可控，适合低优先级清理类任务
配合异步迭代器做流式拉取与处理
当数据来自远端（如日志接口），用 AsyncIterator 把“拉取 + 处理”串成可控流，避免一次性加载全部：
- 实现 [Symbol.asyncIterator] 方法，每次 next() 只请求一页（如 1000 条）
- 用 for await (... of iterator) 消费，天然支持 await 中断与恢复
- 每批数据处理完再拉下一批，内存占用稳定，失败时也只需重试当前页
前端渲染阶段也要分片：虚拟滚动 + 懒加载
即使数据处理完了，一次性塞进 DOM 仍会卡顿。上万行列表必须避开全量渲染：
- 只渲染可视区域内的行，用 scrollTop / itemHeight 计算起止索引
- 用 transform: translateY 定位整体位置，不触发布局重排
- 滚动到底部再加载下一批（或预加载邻近页），配合骨架屏和 loading 状态
- 优先使用成熟库（如 react-window），而非手写滚动监听
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
