JavaScript DOM操作性能瓶颈源于触发重排和重绘，尤其中低端设备；重排开销远高于重绘且必引发重绘；避免“读-写”布局抖动、高频查询、低效插入及内联样式操作，推荐缓存引用、DocumentFragment、classList和transform/opacity动画。
JavaScript 中 DOM 操作之所以成为性能瓶颈，核心在于它直接牵动浏览器的渲染流水线——每次不当操作都可能触发重排（reflow）和重绘（repaint），而这两者是渲染中最耗资源的环节。尤其在中低端设备或复杂页面中，影响尤为明显。
重排与重绘的触发代价
重排是浏览器重新计算元素几何位置和尺寸的过程，开销远高于重绘；而重绘仅更新像素颜色等视觉样式。但重排必引发重绘，因此控制重排次数是关键。
- 会触发重排的操作：修改 width/height、margin/padding、position、display、font-size；添加/删除可见元素；读取 offsetTop、clientWidth、scrollHeight 等布局相关属性。
- 会触发重绘但不重排的操作：修改 color、background-color、visibility（visibility: hidden 不触发重排，display: none 会）。
- 最隐蔽的陷阱：“读-写”模式：先读布局属性（如 el.offsetHeight），再改样式，浏览器为返回准确值会强制同步执行一次重排——连续多次读写就会反复触发，即“布局抖动（Layout Thrashing）”。
高频 DOM 查询带来的开销
DOM 查询本身不是零成本操作。document.getElementById、querySelector 等方法需遍历内部节点索引或渲染树，尤其在深层嵌套或大规模 DOM 中，查找延迟明显。更严重的是，频繁查询常伴随后续修改，形成“查→改→查→改”的恶性循环。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 避免在循环中反复调用 querySelector 或 getElementById；应提前缓存引用，如 const list = document.getElementById('list');
- 对动态生成的列表项，优先使用事件委托，而非为每个子节点绑定监听器，减少查询+绑定双重开销。
- 批量读取布局信息时，可借助 getBoundingClientRect() 一次性获取多个坐标值，比逐个访问 offsetLeft + offsetTop 更高效。
低效插入与更新方式
直接拼接 innerHTML 或逐个 appendChild 是常见误区。前者会销毁并重建整个子树，引发多次重排；后者每插入一个节点就可能触发一次重排（尤其在非空父容器中）。
立即学习“Java免费学习笔记（深入）”；
- 用 DocumentFragment 预构建节点树，所有操作在内存中完成，最后单次 append 到真实 DOM，将 N 次重排压缩为 1 次。
- 避免在循环中反复读写 innerHTML；若必须字符串拼接，建议先累积字符串再一次性赋值，而非 += 循环拼接（现代引擎已优化，但语义不清易出错）。
- 更新文本内容优先用 textContent 而非 innerHTML（无 HTML 解析开销，也更安全）。
样式操作引发的隐性开销
直接设置 element.style.xxx 属性不仅代码冗长，还会绕过 CSS 引擎优化，且每次赋值都可能触发重排——尤其是连续设置多个样式时。
- 推荐通过 classList.add/remove/toggle 切换预定义 CSS 类，样式逻辑交由 CSSOM 处理，浏览器可批量合并变更。
- 需要动态计算样式时，可先移除元素（display: none）、批量修改、再恢复显示，实现“离线操作”；或使用 CSS 自定义属性（CSS Custom Properties）配合 JavaScript 控制，让变化尽量落在合成层（compositor layer）。
- 动画场景下，优先使用 transform 和 opacity，它们触发的是合成器线程更新，不触发重排重绘，性能更优。
