JavaScript性能优化关键是识别并解决主线程卡顿、内存泄漏和页面掉帧问题，包括批量DOM操作、合理使用节流防抖、避免闭包内存泄漏，以及用requestIdleCallback让出主线程。
JavaScript性能优化不是堆砌技巧，而是识别并切断那些让主线程卡住、内存涨不下去、页面掉帧的“真凶”。真正有效的优化，往往藏在你每天写的几行代码里——比如一次 DOM 查询、一个没清理的定时器、或者滚动事件里直接跑了个排序。
怎么批量操作DOM才不触发100次重排？
浏览器每修改一次元素几何属性（width、top、offsetHeight），就可能强制同步计算整个布局（Reflow），这是最贵的操作之一。连续改100次 el.style.left，等于让浏览器算100遍布局。
- ✅ 用
DocumentFragment：先把节点建在内存里，最后一次性挂载 - ✅ 用
innerHTML或cssText批量写入样式，别逐个设style.color、style.fontSize - ✅ 读写分离：先集中读完所有
getBoundingClientRect()、offsetTop等值，再统一写样式 - ❌ 避免“读-改-读-改”循环：比如在
for里一边读el.offsetWidth一边改el.style.marginLeft
节流和防抖到底该用哪个？
高频事件（scroll、mousemove、input）不加控制，会持续抢占主线程，导致页面冻结或动画掉帧。但选错策略反而会丢操作或响应迟钝。
-
throttle：适合持续触发的场景，比如滚动监听位置、鼠标移动画布。保证每delay毫秒最多执行一次，首尾调用要保留（记得配{leading: true, trailing: true}） -
debounce：适合“等用户停下来再干活”的场景，比如搜索框发请求、resize后重新计算栅格。最后一次触发后等待delay毫秒才执行 - ⚠️ 常见坑：Lodash 的
_.throttle默认不触发尾调用；自己手写时忘记绑定this或透传参数
闭包和事件监听器怎么不偷偷吃内存？
闭包本身不慢，但它会让被引用的对象无法被垃圾回收。一个绑在 window 上的 scroll 回调，如果内部函数捕获了整个 document.querySelector('#huge-list')，那这个列表节点就永远删不掉。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- ✅ 把事件处理逻辑抽成独立命名函数，方便在卸载时用
removeEventListener清理 - ✅ 用
WeakMap存私有数据，键是 DOM 节点，值不会阻止节点被回收 - ✅ 定时器、
IntersectionObserver、ResizeObserver用完必须.disconnect()或clearTimeout - ❌ 避免在回调里直接写箭头函数并引用大对象：
el.addEventListener('click', () => doWork(bigData))
哪些任务可以“让出主线程”？
不是所有逻辑都非得立刻跑。日志上报、非关键状态更新、预加载资源……这些完全可以等浏览器空闲时再做，避免打断用户交互或动画帧。
- ✅ 用
requestIdleCallback：只在主线程空闲时调用，且可被中断，适合耗时但不紧急的任务 - ✅ 降级方案：IE 不支持，可用
setTimeout(fn, 0)或Promise.resolve().then()模拟 - ✅ 计算密集型操作（如大数据过滤、JSON 解析）拆成小块，每块后调用
requestIdleCallback继续 - ⚠️ 注意：它不保证执行时间，也不适合动画或用户可见反馈类逻辑
真正卡顿的根源，常常不在算法多复杂，而在你没意识到某次 offsetTop 读取触发了全页重排，或某个忘了 removeEventListener 的监听器正把整棵树钉在内存里。优化的第一步，是打开 Chrome 的 Performance 面板录一段操作——看到哪条长任务横在那里，就从那里开始切。
