关键在于建立“时间—任务—用户反馈”闭环：50ms为卡顿红线，16ms帧预算，100ms响应阈值；通过Performance面板定位Long Task、CPU占用与Layout/Paint异常；按任务类型选用requestIdleCallback、setTimeout、requestAnimationFrame或Web Worker；动态切片+DocumentFragment+属性缓存+contain隔离等配套优化，并以INP验证真实体验。
学JS长任务拆分、主线程保护与流畅度提升，关键不是记住所有API，而是建立“时间—任务—用户反馈”的闭环判断力：50ms是卡顿红线，16ms是帧预算，100ms是响应心理阈值。所有技术手段都服务于让主线程在该渲染时能渲染、该响应时能响应。
从Performance面板开始，只优化真瓶颈
打开Chrome DevTools → Performance，录制一次典型交互（如点击加载列表、切换Tab）。重点看三处：
- 标红的[Long Task]：持续＞50ms的脚本块，必须拆
- Scripting区域是否连续占满CPU：说明计算密集，优先考虑Web Worker或预计算
- Layout / Paint频繁跳动：问题常不在JS执行时长，而在DOM操作方式（比如循环中读取offsetHeight）
别被“看起来慢”的代码误导——单次插入200个节点不慢，但若每个节点都带内联样式+强制layout计算，就会触发多次重排。此时应优化DOM操作模式，而非单纯切片。
按任务类型选调度机制，不硬套API
不同任务性质决定调度策略，混用反而更卡：
-
DOM渲染类（列表、日历、表格）：用requestIdleCallback + DocumentFragment批量插入，每批控制在20–50条，靠
deadline.timeRemaining() > 1动态中断 - 数据处理类（日志过滤、JSON解析、数组计算）：用setTimeout(, 0)分片，每轮处理100–500条；CPU密集型（如Excel解析）直接移交Web Worker
- 动画/滚动强关联类（拖拽实时计算、滚动位置映射）：改用requestAnimationFrame，天然对齐刷新周期
-
启动初始化类（SDK加载、缓存重建）：必须同步的留主线程，其余全丢给requestIdleCallback，并设
{ timeout: 2000 }防无限等待
切片不能固定，要随设备和空闲动态校准
固定每批50条，在低端机上可能超8ms，在高端机上又浪费空闲时间。真实做法是：
- 冷启动参考
navigator.deviceMemory和navigator.hardwareConcurrency设初始批大小（如2GB内存→初始30条） - 每轮用
performance.now()打点，若连续两次耗时＞2ms，自动将批大小×0.7 - 监听
document.visibilityState === 'hidden'或滚动高频时，临时收紧粒度（如降为原1/3） - 始终设硬边界：最小不小于10条，最大不超过200条
配套轻量级优化，缺一不可
只拆任务不够，很多卡顿来自隐性开销：
- 所有DOM插入统一走
DocumentFragment，避免反复触发layout - 禁止在循环中读写
offsetHeight、getBoundingClientRect()等触发重排的属性；位置计算尽量预生成并缓存 - 按钮、拖拽等事件监听器，等节点进入视口后再用
IntersectionObserver初始化 - 用
contain: layout style paint隔离复杂组件，防止样式/布局影响全局
验证效果时，不只看FPS，更要关注INP（Interaction to Next Paint）指标——它直接反映用户真实操作延迟。
