避免长期占用 JavaScript 调用栈的核心是单次执行不超过16ms，需拆分长任务、移出重计算至Web Worker、杜绝强制同步布局、精简事件响应与内存引用。
避免长期占用 JavaScript 调用栈，核心是不让单次脚本执行阻塞主线程超过 16ms（即一帧时间），否则浏览器无法及时完成布局、绘制和合成，帧率就会明显下跌。关键不是“少写代码”，而是让任务可中断、可调度、不抢渲染资源。
拆分长任务，主动让出主线程
任何持续运行超 50ms 的同步逻辑（如遍历万级数组、解析大 JSON、复杂计算）都会卡住渲染。必须切成小块，在空闲时段或帧间隙执行：
- 用 requestIdleCallback 处理低优先级工作，比如日志上报、非关键状态同步、预加载准备
- 对确定需执行的中等任务（如列表数据处理），用 setTimeout 或 Promise.resolve().then() 微任务切片，每轮处理几百项后暂停
- 避免递归过深或未设终止条件的 while 循环——它们极易撑爆调用栈并阻塞渲染
把重计算移出主线程
纯数学运算、图像处理、加密解密、大型数据结构转换等，不涉及 DOM，就该交给 Web Worker：
- Worker 独立线程运行，完全不干扰页面渲染和用户交互
- 主线程只负责发送数据、接收结果；Worker 内部可自由使用 for 循环或递归，无帧率风险
- 注意传输成本：用 Transferable Objects（如 ArrayBuffer）零拷贝传递大数据，避免序列化开销
杜绝强制同步布局（Forced Synchronous Layout）
这是隐藏最深的调用栈“假性占用”——看似没跑多久，却因触发回流导致后续渲染排队等待：
- 禁止在修改样式后立刻读取 offsetTop、getBoundingClientRect()、clientWidth 等属性
- 所有读操作集中前置，所有写操作集中后置；或改用 ResizeObserver、requestAnimationFrame 延迟到下一帧再读
- 动画一律用 transform 和 opacity，它们由合成线程处理，不进入 JS 主线程布局流程
精简事件响应与内存引用
看似轻量的操作，若设计不当，会通过隐式引用持续拖慢 GC 并间接拉长任务队列：
- 滚动、输入等高频事件加 throttle（非 debounce），保证稳定节流而非丢帧
- 组件卸载时务必清除 addEventListener，尤其避免匿名函数绑定——它会让监听器无法被 removeEventListener 移除
- 慎用闭包捕获大对象（如整个 DOM 树、缓存数据），可用 WeakMap 存储关联数据，不阻止回收
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
