17370845950

JavaScript性能优化需针对性使用技术：批量DOM操作用DocumentFragment或HTML字符串；节流防抖按场景选，注意leading/trailing配置；闭包泄漏用WeakMap或显式移除监听器；requestIdleCallback用于非关键异步任务，不可替代rAF或同步逻辑。

JavaScript性能优化不是加个use strict就变快，也不是盲目压缩代码——它是在真实卡顿、内存上涨、滚动掉帧发生时，你手上有几把能立刻用的“扳手”。

怎么批量操作DOM才不触发1000次重排？

每次appendChild、innerHTML赋值或读取offsetTop，都可能强制浏览器同步计算布局（Reflow），高频操作会让主线程直接卡死。

• ✅ 正确做法：用document.createDocumentFragment()在内存中攒好所有节点，最后一次性挂载
• ✅ 替代方案：先拼接HTML字符串（如list.innerHTML = htmlString），比逐个createElement快，但要注意XSS风险
• ⚠️ 常见坑：在循环里反复调用document.query

  

  Selector——查一次缓存起来，别每次重走DOM树
• ⚠️ 更隐蔽的坑：读写混用，比如先读el.offsetHeight，再设el.style.width，浏览器会立刻回流——读完再写，批量读、批量写

节流和防抖到底该用哪个？

不是所有高频事件都适合debounce；选错会导致交互失灵或响应延迟。

• throttle：适合持续触发的场景，比如scroll、mousemove——保证每200ms最多执行一次，不丢事件
• debounce：适合“等用户停下来再干活”的场景，比如搜索框输入、resize——最后一次输入后等300ms再发请求
• ⚠️ 关键细节：_.throttle默认不触发首尾调用，得手动加{ leading: true, trailing: true }，否则滚动一开始和结束都收不到回调
• ⚠️ 兼容性注意：IE不支持requestIdleCallback，但throttle/debounce纯JS实现无依赖，可直接落地

闭包真慢吗？为什么它常被当成“内存泄漏元凶”？

闭包本身不拖慢执行，但它容易“悄悄留住不该留的东西”，比如一个10MB的数组或整个document.body。

• 常见泄漏模式：el.addEventListener('click', () => doSomething(bigData))——箭头函数捕获了bigData，而el长期存在，bigData就永远无法GC
• ✅ 解法一：用WeakMap存私有数据，键是DOM元素，值是关联状态，元素被移除后自动释放
• ✅ 解法二：事件监听器用命名函数+removeEventListener配对清理，别用匿名函数
• ⚠️ 检测方法：Chrome DevTools → Memory → “Heap Snapshot”，对比操作前后，搜Detached或大对象引用链

requestIdleCallback 是什么？能替代 setTimeout 吗？

它不是“另一个定时器”，而是浏览器明确告诉你：“现在主线程空闲，你可以干点不着急的事”。

• 适合场景：日志上报、非关键UI更新、预加载下一页数据——这些事晚100ms执行完全不影响体验
• ✅ 优势：会被浏览器中断（比如用户突然开始滚动），不会阻塞交互；自带优先级调度
• ⚠️ 不适合：动画帧逻辑（用requestAnimationFrame）、必须立即执行的校验逻辑
• ⚠️ 兼容性：IE全系不支持，需降级为setTimeout(fn, 0)或轻量polyfill；但别在核心路径里用它做兜底，只用于锦上添花

真正卡顿的根源往往藏在“看起来没问题”的地方：比如一个没清理的resize监听器，或缓存了整个dataset对象的闭包。优化不是堆技巧，而是养成用Performance面板录一下、用Memory截个快照的习惯——问题在哪，扳手就往哪拧。