核心是利用 requestIdleCallback 在每帧绘制后空闲时段执行小块任务，通过 timeRemaining() 动态控制执行时长，设 timeout 防卡死，并降级兼容 Safari 16.4 以下；避免 setTimeout 抢占交互，DOM 操作需批处理并用 DocumentFragment 减少重排。
JS 长任务拆分防止假死，核心是把一个耗时操作切成小块，在浏览器空闲时段执行，避免主线程被长时间独占。关键不是“切多少次”，而是让出控制权，给渲染、响应用户输入留出时间。
用 requestIdleCallback 做真正的空闲调度
它会在每帧绘制完成后、下一帧开始前的空闲时间执行回调，并提供 timeRemaining() 告诉你还能安全运行多久。比 setTimeout 更可靠，不抢用户交互时机。
- 回调里每次只处理一批数据（比如 20 条订单、50 个 DOM 节点），然后检查
deadline.timeRemaining() < 1，不够就退出，等下次空闲再继续 - 必须设 timeout 选项（如 2000ms），防止任务卡住太久导致界面无响应
- Safari 16.4 之前不支持，需 fallback 到
setTimeout或MessageChannel，但注意后者不能保证空闲，仅作兼容兜底
避免用 setTimeout 简单分片的陷阱
setTimeout 只按时间排队，不管主线程是否正忙。用户正在输入或滚动时，它仍会插入执行，反而加剧卡顿。
- 不要写
setTimeout(() => processBatch(), 0)这类“伪异步”，它只是插队，不是让出 - 如果必须用 setTimeout，建议结合
performance.now()检查执行耗时，超 2ms 就主动 break，下一轮再进 - 更稳妥的做法是：先用
requestIdleCallback，降级时用MessageChannel+ 微任务队列模拟轻量空闲感知
任务粒度要匹配实际开销
不是越小越好。太碎会增加调度开销；太大又起不到释放效果。重点看单次操作的 CPU 时间，而非条数。
- 纯计算（如数组 map、JSON 解析）：单次控制在 0.5–1ms 内，可用
performance.now()实测 - 涉及 DOM 插入或样式读写：一次最多 10–30 个节点，因为 layout/paint 开销不可忽略
- React 场景下慎用
useState频繁触发重渲染，建议攒批更新，或配合useTransition标记非紧急更新
配合浏览器渲染管线做协同优化
拆分只是手段，最终目标是保障 60fps 和输入响应。要知道哪些操作会阻塞关键路径。
- 避免在长任务中读取
offsetHeight、getComputedStyle等触发强制同步布局（reflow） - DOM 批量操作优先用
DocumentFragment，最后一次性 append，减少重排重绘次数 - 对列表类场景，可结合虚拟滚动：只渲染可视区域 + 少量缓冲区，比全量拆分更治本
