JavaScript性能优化应先用DevTools Performance面板定位瓶颈：Scripting高说明长任务阻塞，Rendering高提示强制布局或重绘，Memory增长快则需查内存泄漏；避免强制同步布局，批量DOM操作，慎用第三方库。
JavaScript 性能优化不是靠堆技巧，而是优先识别瓶颈再针对性处理。盲目加 memoize、提前用 requestIdleCallback 或重写循环为 for，往往收效甚微甚至引入 bug。
如何快速定位真实性能瓶颈
别猜，用浏览器 DevTools 的 Performance 面板录制用户典型操作（比如点击按钮后列表渲染）。重点关注 Scripting 和 Rendering 时间占比：
- 若
Scripting占比高且主线程长时间阻塞 → 检查长任务（如未分片的数组遍历、同步 JSON 解析、大量 DOM 插入） - 若
Rendering占比异常高 → 看是否频繁触发layout（如循环读取offsetHeight）或重绘（如内联样式频繁变更） - 若
Memory面板显示对象持续增长 → 检查事件监听器泄漏、闭包引用未释放、定时器未清除
避免强制同步布局（Forced Synchronous Layout）
这是前端动画和滚动场景中最隐蔽的性能杀手。只要在修改样式后立刻读取几何属性（如 clientWidth、getBoundingClientRect()），浏览器就必须立即计算布局，打断渲染流水线。
- ❌ 错误写法：
el.style.height = '200px'; console.log(el.offsetHeight); - ✅ 正确做法：把读操作批量放在所有写操作之后，或用
getComputedStyle(el).height替代（仍需谨慎） - 更稳妥方案：用
ResizeObserver或requestAnimationFrame延迟到下一帧读取
DOM 操作不是越少越好，而是要减少重排重绘次数
很多人记成“用 documentFragment 一定更快”，其实现代浏览器对单次插入多个子节点已做优化。真正关键的是避免“读-写-读-写”模式。
立即学习“Java免费学习笔记（深入）”；
- 批量修改样式时，优先用 class 切换而非逐个设
style.xxx - 需要插入大量元素时，
innerHTML在简单结构下可能比document.createElement+appendChild更快（但要注意 XSS） - 对列表渲染，用
key（React）或data-id（原生）做 diff，避免全量替换；哪怕不用框架，也应只更新变化的行，而不是el.innerHTML = newListHtml
函数调用开销常被高估，但闭包和 this 绑定代价真实存在
for 循环比 forEach 快？在 V8 里差异通常小于 1%。但以下情况确实有可观影响：
- 在循环中反复创建匿名函数（如
arr.map(x => () => x)）→ 产生大量闭包对象，增加 GC 压力 - 用
bind()或箭头函数在 render 中绑定this→ 每次调用都新建函数，破坏shouldComponentUpdate或React.memo判断 - 高频回调（如
scroll、mousemove）未节流/防抖 → 函数调用本身不重，但累积的 DOM 操作和状态更新会拖垮帧率
最常被忽略的一点：性能问题往往不在你写的代码里，而在你引入的第三方库中——一个没做 tree-shaking 的 lodash、一个默认开启 debug 日志的 SDK、一个内部用 setInterval 轮询的组件，都可能成为瓶颈源。先看 Performance 里的调用栈，再决定要不要优化自己的代码。
