长任务分时调度的核心是将大任务切片并穿插在浏览器空闲或低优先级时段执行，关键在于精准把握“何时切、切多大、如何收尾”，而非单纯增加切片次数。
长任务分时调度的核心，是把原本一口气干完的活，切成小块，穿插在浏览器空闲或低优先级时段执行，从而避免主线程被独占。关键不是“切多少次”，而是“什么时候切、切多大、怎么收尾”。
选对调度时机：按任务性质匹配 API
不同场景下，浏览器提供的调度机制效果差异很大：
-
非紧急后台任务（如日志上报、缓存清理、非首屏数据预处理）：优先用
requestIdleCallback，它能感知浏览器真实空闲时间；务必加{ timeout: 2000 }，防止用户切走页面后任务永久挂起 -
与视觉强相关操作（如拖拽实时计算、滚动中动态加载）：改用
requestAnimationFrame，确保逻辑和屏幕刷新节奏一致，不丢帧 -
纯计算、无 DOM 依赖（如 CSV 解析、加密、路径规划）：直接扔进
Web Worker，彻底解放主线程，不参与事件循环调度 -
兼容性要求高或需精确控制延迟：用
setTimeout(fn, 0)或Promise.resolve().then()，虽不如 IdleCallback 智能，但稳定可靠
动态控制切片大小：别硬写固定数字
每批处理 100 条，在高端机上可能只花 3ms，浪费空闲；在低端机上却超 8ms，反而引发卡顿。真实做法是让粒度“会呼吸”：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 冷启动时参考
navigator.deviceMemory和navigator.hardwareConcurrency设初始值（例如 2GB 内存 → 初始批大小设为 30） - 每轮执行前后用
performance.now()打点，若连续两次耗时 >2ms，自动将批大小乘以 0.7 - 监听
document.visibilityState === 'hidden'或滚动事件高频触发时，临时压到原粒度的 1/3，避免抢占交互资源 - 始终设硬边界：最小不小于 10 条，最大不超过 200 条，防震荡、防退化
配合轻量级防御措施：拆完还得护住主线程
只拆任务不够，很多卡顿来自隐性开销：
立即学习“Java免费学习笔记（深入）”；
- 避免在分片循环里反复读取
offsetHeight、getBoundingClientRect()等触发回流的属性；统一缓存一次结果再用 - DOM 批量更新优先用
DocumentFragment或拼好字符串一次性赋给innerHTML，别在每片里都appendChild - 高频事件（如
scroll、resize）加节流，防止调度器还没开始干活，新任务又塞了一堆进来 - 生产环境关掉
console.log，尤其别在分片逻辑里打印大型对象，序列化过程本身就会阻塞主线程
验证是否真有效：别靠感觉，看指标
优化后必须用数据确认效果：
- 打开 Chrome DevTools → Performance 面板，录制操作，看红色长任务标记是否减少、总阻塞时间（TBT）是否下降
- 用
PerformanceObserver监听longtask类型，代码中捕获并上报实际耗时分布 - 关注输入延迟（Input Delay）和 FPS 曲线，尤其在低端设备模拟下测试——卡顿往往最先出现在那里
