html中不存在“html函数”，卡顿源于dom操作触发的强制布局、重绘及后台标签页资源争抢；应监听visibilitychange暂停无意义更新，用requestidlecallback低优先级执行，动画优先用css transform/opacity，innerhtml与createelement需按场景选择，严防内存泄漏。
HTML函数本身不会卡顿，但频繁操作DOM会拖慢多标签页
浏览器里“HTML函数”并不存在——你实际调用的是 document.createElement、innerHTML、appendChild 这类 DOM 操作方法。多开标签时卡顿，往往不是函数本身慢，而是这些操作触发了强制同步布局（layout）、重绘（paint），尤其在后台标签页仍持续执行定时器或监听器时，CPU 和内存压力会叠加。
- 后台标签页的
setTimeout和requestAnimationFrame会被浏览器节流（比如降频到 1fps），但 DOM 修改一旦发生，仍需参与渲染管线 - 多个标签页共用同一进程（如 Chrome 的默认设置）时，一个标签页的长任务会阻塞其他页的 JS 执行
-
innerHTML = ...替换大段 HTML 比createElement+appendChild更易引发回流，尤其在循环中反复赋值
避免在 visibilitychange 事件外持续更新 DOM
用户切走标签页后，多数 UI 更新其实毫无意义，但很多代码仍照常运行：轮播图自动切换、倒计时刷新、图表重绘……这些都会偷偷吃掉资源。
- 监听
document.addEventListener('visibilitychange', ...)，在document.hidden === true时暂停所有 DOM 更新逻辑 - 不要只靠
setInterval控制频率；改用requestIdleCallback做低优先级更新，它会在浏览器空闲时才执行 - 对动画类操作，优先用 CSS
transform和opacity，它们走合成线程，不触发布局计算
innerHTML vs createElement：性能差异取决于场景
不是“哪个更快”，而是“在哪种结构下更可控”。直接拼接字符串再赋给 innerHTML 看似简洁，但容易忽略注入风险和解析开销；而逐个 createElement 虽安全，但写法啰嗦、易出错。
- 小量、静态结构（如生成一个按钮）：用
createElement+setAttribute更稳妥 - 大量、动态 HTML（如渲染列表项）：用
innerHTML配合template标签或documentFragment批量插入，避免逐个 append - 绝对避免在循环里反复写
element.innerHTML += ...—— 每次 += 都会重新解析整个字符串并重建子树
内存泄漏常见源头：事件监听器 + 闭包引用
多开标签页时，每个页都可能因未清理的监听器或定时器，让 DOM 节点无法被 GC 回收，久而久之堆内存持续上涨，最终卡顿甚至崩溃。
- 用
addEventListener时，务必配对removeEventListener；若用匿名函数，则无法移除——改用具名函数或AbortController（Chrome 95+） - 避免在事件回调里直接引用大型数据对象；用弱引用（
WeakMap）缓存关联状态更安全 - 检查控制台 Memory 面板里的 “Detached DOM tree” —— 如果数字居高不下，说明有节点被 JS 引用却已从文档移除
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
