DOM性能瓶颈源于不当操作模式而非DOM本身；getElementById因ID索引接近O(1)，比querySelectorAll快；批量插入优先用DocumentFragment或innerHTML；读取offsetTop等会触发强制同步布局，应“读-写分离”；需用DevTools渲染面板定位重排重绘。
DOM 操作确实是 JS 性能瓶颈的常见来源，但不是“只要碰 DOM 就慢”，而是特定操作模式（如频繁读写、强制重排重绘、低效遍历）会显著拖慢执行。关键在怎么用，不在能不能用。
为什么 document.getElementById 比 document.querySelectorAll 快得多
前者直接走 ID 索引（浏览器内部有哈希映射），时间复杂度接近 O(1)；后者要遍历整个子树匹配 CSS 选择器，哪怕只写 #id，也仍走选择器引擎，多一层解析开销。
- 用
document.getElementById('foo')替代document.querySelectorAll('#foo')[0]，尤其在循环或高频回调中 -
querySelector适合动态选择器场景（比如根据 class 名拼接），但别为静态 ID 或 class 迁就它 - 如果真要多次查同一个元素，缓存到变量里，避免重复调用 ——
const btn = document.getElementById('submit');
innerHTML 批量插入 vs appendChild 单个追加
一次性设置 innerHTML 会触发完整 HTML 解析 + DOM 构建，但只触发一次重排；而循环调用 appendChild 每次都可能触发样式计算和布局（尤其插入带样式的元素时）。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 插入大量节点（比如渲染列表）：先拼字符串或用
DocumentFragment，再一次性挂载 - 示例：
const frag = document.createDocumentFragment();<br>data.forEach(item => {<br> const el = document.createElement('div');<br> el.textContent = item;<br> frag.appendChild(el);<br>});<br>container.appendChild(frag); - 注意：
innerHTML有 XSS 风险，纯文本优先用textContent或手动转义
读取 offsetTop、getBoundingClientRect 触发强制同步布局
这些属性需要当前布局准确值，浏览器不得不立即完成所有待处理的样式计算和重排（即使你刚改完 class 还没渲染），打断渲染流水线，是隐藏最深的性能杀手。
立即学习“前端免费学习笔记（深入）”；
- 避免在循环里反复读取
el.offsetTop或el.getBoundingClientRect() - 把读取集中到一起（“读-写”分离）：先批量读所有需要的布局信息，再批量写样式或位置
- 用
getComputedStyle(el).height同样会触发同步布局，和offsetHeight本质一样 - 现代替代：CSS
contain: layout可隔离子树布局影响，但兼容性有限（Chrome 85+）
真正卡顿往往不是 DOM API 本身慢，而是你无意中把它变成了“重排触发器”。测性能别只看 JS 函数耗时，打开 Chrome DevTools 的 Rendering 面板，勾上 “Paint flashing” 和 “Layout Shift Regions”，动一动页面就知道哪块 DOM 在偷偷重绘重排了。
