DOM操作是JS性能下降的主因之一，因其触发重排重绘且JS与GUI线程互斥；应减少跨线程查询、缓存DOM引用、用静态NodeList替代实时集合、合理委托事件。
DOM 本身不会改善 JavaScript 性能；相反，**频繁或低效的 DOM 操作是 JS 性能下降的主因之一**。关键不在“用不用 DOM”，而在“怎么用”。
浏览器中 JS 引擎线程和 GUI 渲染线程互斥，每次读写 document、调用 getElementById、修改 style 或插入节点，都可能触发重排（reflow）或重绘（repaint）。这些开销远大于纯 JS 运算。
下面直说几个真实开发中高频踩坑点和对应解法：
为什么 document.getElementById 每次调用都慢？
它不是“查缓存”，而是每次向渲染线程发起同步查询请求。尤其在循环里反复写 document.getElementById('list')，等于反复跨线程通信。
- ✅ 正确做法：查一次，存变量 ——
const list = document.getElementById('list'); - ⚠️ 注意：
getElementsByClassName返回的是实时集合（HTMLCollection），每次访问.length都会重新遍历 DOM，比querySelectorAll（返回静态 NodeList）更耗性能 - ❌ 错误模式：
for (let i = 0; i —— 每次循环都重算长度
innerHTML 和 createElement 哪个更快？
没有绝对答案，取决于场景和浏览器。Chrome 下 createElement + appendChild 批量插入常优于 innerHTML；Firefox 则反之。但安全性和可维护性上，createElement 明显占优。
- ✅ 插入大量静态结构（如模板 HTML 字符串）：用
innerHTML可读性高，但必须确保内容可信，否则有 XSS 风险 - ✅ 动态拼接、含用户输入：优先用
document.createElement+textContent，避免解析 HTML - ✅ 真正的性能关键点：是否用了
document.createDocumentFragment()—— 它把多次 DOM 修改收拢成一次插入，减少重排次数
为什么改 10 次 style 属性比改 1 次慢 10 倍？
因为每次写 el.style.color、el.style.fontSize 都可能触发强制同步布局（forced synchronous layout），浏览器必须立刻计算当前样式并回滚渲染队列。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- ✅ 推荐：用 CSS 类控制样式变化 ——
el.classList.add('active')，所有变更由 CSSOM 统一处理 - ✅ 若必须内联样式，合并写入：
el.style.cssText = 'color: red; font-size: 14px;'（注意会覆盖原有style） - ❌ 避免混着读写：
console.log(el.offsetHeight); el.style.height = '200px';—— 这种组合极易引发强制重排
事件绑定太多导致内存泄漏？
给每个 li 单独绑 click，100 个就是 100 个监听器。不仅初始化慢，后续移除节点时若没手动 removeEventListener，就容易泄漏。
- ✅ 一律用事件委托：
parent.addEventListener('click', e => { if (e.target.matches('.item')) { ... } }) - ✅ 父容器尽量选稳定节点（如
#list），别用document或body—— 事件冒泡路径越长，响应延迟越明显 - ✅ 动态增删子元素完全无感，无需重绑
真正卡顿的从来不是 JS 逻辑本身，而是你让 JS 不停地“敲门问渲染线程：这个元素在哪？它现在多高？我要把它塞进去，你重画一下？”——这些敲门声，才是性能瓶颈的本体。优化方向很明确：少敲门、敲得准、一次问清楚、别边问边改。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
