卡顿主因是浏览器性能陷阱而非代码错误：频繁dom查询、innerhtml+=强制重排、scroll/resize未节流、硬件加速在老旧设备适配差，应缓存元素、批量操作、用requestanimationframe节流、禁用gpu加速并用performance面板定位瓶颈。
卡顿不是因为你写的 HTML 或 JS 本身有错，而是浏览器在执行时被拖进了几个常见性能陷阱——尤其在老旧笔记本、集成显卡或低内存设备上，这些陷阱会被放大成明显卡顿。
为什么 document.getElementById 频繁调用会让页面变慢
每次调用 document.getElementById 都触发一次 DOM 树遍历，看似轻量，但在循环里调用 100 次，就等于做 100 次线性搜索。老旧 CPU 处理这种操作容易堆积任务，主线程一卡，整个页面就“粘住”。
- 把
document.getElementById('output')提前缓存为const outputEl = document.getElementById('output');，后续直接用outputEl.innerHTML = ... - 避免在
for循环或scroll回调里反复查 DOM —— 查一次，存变量，重用到底 - 如果要批量更新多个元素，优先用
document.querySelectorAll('.item')一次性获取 NodeList，再遍历操作
为什么 innerHTML += 是隐藏的卡顿源
写 el.innerHTML += '<div>' + i + '</div>' 看似方便，但每次 += 都会让浏览器：解析整段 HTML 字符串 → 清空原有子树 → 重建全部节点 → 触发重排。连续 50 次，就是 50 次强制 layout。
- 改用
document.createDocumentFragment()批量插入：先建 fragment，循环appendChild，最后一次性el.appendChild(fragment) - 或拼接字符串后只赋值一次：
htmlStr += '<div>' + i + '</div>';→ 循环外el.innerHTML = htmlStr; - 绝对不要在
requestAnimationFrame或scroll回调里用innerHTML +=，这是卡顿高发组合
为什么 scroll 和 resize 事件一绑就卡
滚动时浏览器每秒可能触发 60–120 次 scroll 事件，而你的回调里如果含 getBoundingClientRect() 或直接改样式，每次都会强制同步回流（forced synchronous layout），CPU 直接拉满。
- 用
requestAnimationFrame节流：在事件里只设标志位，requestAnimationFrame中统一读+写 - 改用
IntersectionObserver替代scroll判断元素是否可见，它不占主线程 - 检查是否监听了
scroll却没清理：页面卸载或切换标签页时，记得removeEventListener，否则闭包持续引用 DOM 节点，内存涨到卡死
为什么禁用硬件加速反而更流畅
老旧集成显卡（如 Intel HD Graphics 3000/4000、UHD 620）驱动对 WebGL 或合成层支持不稳，开启硬件加速后，浏览器会不断尝试 GPU 渲染 → 失败 → 回退到 CPU 软合成 → 再试，这个过程本身就在吃 CPU 时间。
- 访问
chrome://settings/system，关闭「使用硬件加速模式(如果可用)」 - 验证是否生效：打开
chrome://gpu，确认Rasterization和Compositing显示为Software only - 启动浏览器时加参数
--disable-gpu --disable-webgl，彻底绕过 GPU 路径（适用于 Chrome / Edge）
真正卡住你的，往往不是某一行代码多慢，而是多个小操作叠加后，在老旧硬件上突破了 16ms 帧预算。别猜，开 DevTools 的 Performance 面板录一段滚动或点击，看哪段红色长条卡在主线程——那才是你该动刀的地方。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
