关键在于避免主线程被长时间占用：将大计算拆分为≤20ms的小块，用queuemicrotask或requestidlecallback分片执行，必要时通过web worker移出主线程，并以performance面板和inp指标验证优化效果。
避免长时间计算导致页面掉帧卡顿，关键不是让计算变快，而是不让它连续霸占主线程。浏览器每 16ms 需完成一帧渲染，一旦 JS 同步执行超过 50ms，就大概率跳过一帧——用户会明显感知卡顿、滚动不跟手、输入延迟。
把大计算切分成 ≤20ms 的小块
每次只处理一部分数据，处理完立刻让出控制权，给渲染和事件响应留出时间：
- 用 setTimeout(fn, 0) 或 queueMicrotask(fn) 拆分循环：每处理 200～500 项就暂停，下一轮再继续
- 优先选 queueMicrotask 做微任务拆分（更及时），但要注意别堆积太多微任务引发新延迟
- 对万级数组排序或遍历，别用
arr.map().filter().reduce()链式调用——避免重复遍历和闭包开销，改用单层for循环 + 条件判断
在浏览器空闲时执行非紧急计算
适合校验、日志聚合、预处理等不影响当前交互的任务：
- 用 requestIdleCallback，它会在帧渲染完成后、有空余时间时才执行，且可传入
{ timeout: 2000 }防止任务被无限搁置 - 配合
performance.now()做时间切片：在回调内循环执行，直到接近 deadline 或任务完成 - 注意兼容性：Safari 旧版不支持，需降级为
setTimeout+ 时间戳控制
把纯计算移出主线程
当逻辑完全不操作 DOM、不依赖 window/document 时，Web Worker 是最彻底的解法：
- 将 JSON 解析、加密解密、大数据聚合、图像像素处理等 CPU 密集型操作交给 Worker
- 主线程只负责发送数据和接收结果，用
postMessage通信，零阻塞 - Worker 内无法直接访问 DOM，但可配合
OffscreenCanvas处理图形任务
验证是否真解决了掉帧
不能只看代码拆了没，要盯住真实指标：
- 打开 Chrome DevTools → Performance 面板，录制典型操作（如快速滚动+点击），观察主线程火焰图是否被“打散”，长条是否消失
- 用 PerformanceObserver 监听
longtask，确认 >50ms 的任务数量下降 80% 以上 - 实测 INP（Interaction to Next Paint）：目标 P75 ≤150ms，尤其关注表单输入、下拉切换等高频交互路径
- 开启 Rendering 面板的 FPS meter，在低端设备上连续快速操作，确认帧率稳定在 50～60fps
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
