JS长任务拆分需围绕主线程调度权系统控制，核心是确保单次执行≤50ms；必须同步任务（如挂载根DOM、初始化路由）、可延迟任务（如SDK加载）、可分片任务（如大数据处理）需分类处理；优先用requestIdleCallback切片，降级用setTimeout；配合虚拟滚动与DocumentFragment优化渲染。
JS 长任务拆分不是“把大循环改成小循环”就完事，而是围绕主线程调度权展开的系统性控制：核心目标是确保任意时刻主线程执行时间 ≤ 50ms，让浏览器有足够空隙处理用户输入、渲染帧和动画。关键不在“切多细”，而在“切得准、交得快、补得稳”。
识别并隔离真正必须同步的任务
启动或渲染初期，并非所有初始化都该立刻执行。需明确三类边界：
- 必须同步：挂载根 DOM 节点、初始化路由核心实例、激活状态管理器（如 Pinia store 的 setup）、解析首屏必需的最小数据结构
- 可延迟但需可控：非首屏组件预加载、第三方 SDK（埋点/监控）初始化、字体/图标资源 prefetch
- 可分片或按需：本地数据库批量写入、5 万条 JSON 索引重建、复杂 UI 状态树深度计算
用宏任务做切片锚点，而非微任务
微任务（Promise.then、queueMicrotask）不会让出渲染权，只适合批内快速衔接；真正释放主线程、触发浏览器重绘/响应的，必须靠宏任务。
- 每批处理 100–500 条数据后，调用 setTimeout(() => nextChunk(), 0) —— 这是让出控制权最直接可靠的方式
- 避免用 while + continue 一口气跑完，哪怕加了 queueMicrotask，仍是长任务
- 慎用 setInterval 做切片：它不感知当前任务是否完成，易造成节奏失控或堆积
优先使用 requestIdleCallback，但要有降级方案
这是浏览器原生支持的空闲调度机制，自动避开用户交互与动画帧，比手动 setTimeout 更智能。
- 每批渲染 20–50 条 DOM 节点，插入前用 DocumentFragment 批量操作，避免反复 layout
- 每次执行后检查 deadline.timeRemaining() > 1，有余量则继续，否则退出并等待下次空闲
- 兼容性不足时（如旧版 Safari），降级为 setTimeout(..., 0)，并设置 timeout: 2000 防止无限等待
配合虚拟滚动替代前端分页
当数据总量达万级、用户以滚动浏览为主时，“前端分页+全量渲染”本身已是反模式。
- 只维护可视区域 + 上下缓冲区（共约 30–50 个节点），滚动时通过 scrollTop 和行高动态计算起始索引
- 复用 DOM 节点，仅更新内容与 transform: translateY()，完全规避批量插入与重排开销
- 搭配骨架屏与 loading 状态反馈，视觉上保持流畅，实际内存与 CPU 占用极低
不复杂但容易忽略
