media查询与class切换会触发重排，因width/height/margin等布局属性变化迫使浏览器重建渲染树；连锁重排可能波及父容器及子元素，应优先使用transform、clip-path或will-change优化。
卡顿不是模板“写得不够炫”，而是浏览器在反复解析、重排、重绘——尤其在响应式断点切换或动态内容注入时，DOM 和样式树频繁重建，直接拖垮帧率。
为什么 media 查询 + class 切换会触发重排
每次 window.matchMedia 触发或 classList.toggle 导致媒体查询条件变化时，若 CSS 中用了 width/height/margin/padding 等触发布局的属性，浏览器必须重新计算整个渲染树。更隐蔽的是：哪怕只改一个 max-width，只要它影响了元素尺寸或流式位置，就可能引发父容器重排，连锁反应到子元素。
- 避免在
@media块里修改width、height、display（尤其是inline↔block）、float - 优先用
transform: scale()或clip-path模拟尺寸缩放，它们不触发重排 - 如果必须切换布局（如移动端侧边栏展开），把该区域包裹进
will-change: transform提前告知浏览器
HTML模板注入后事件丢失或响应延迟
用 innerHTML = htmlStr 插入响应式片段后，新节点没绑定事件、querySelector 查不到、甚至点击无响应——这不是 JS 没执行，而是 DOM 节点被重建后，原事件监听器未迁移，且浏览器还没完成样式计算和布局。
- 别用
innerHTML直接拼接含交互逻辑的模块；改用<template>+document.importNode(template.content, true)克隆 - 克隆后必须手动绑定事件：
cloned.querySelector('button').addEventListener('click', handler) - 若需批量委托，确保父容器是静态存在的（比如
id="main-content"的 div），且监听器在克隆完成后再挂载 - 避免在插入后立刻调用
getBoundingClientRect()—— 加requestAnimationFrame(() => { /* 读取尺寸 */ })确保布局已就绪
图片加载导致滚动卡顿和切出冻结
响应式模板常配多套 srcset 图片，但若原始图未压缩、格式陈旧、或 background-attachment: fixed 搭配高分辨率图，GPU 显存会在后台持续满载，Alt+Tab 切出即假死。
立即学习“前端免费学习笔记（深入）”；
- 所有
<img>必须带width和height（或 CSSaspect-ratio），否则加载时触发 CLS + 重排 - 禁用
background-image高清大图；改用<picture>+ WebP/AVIF +loading="lazy"，且首屏图设fetchpriority="high" - 检查是否误对
<img>设置了loading="lazy"却又在首屏 —— 这会让 LCP 延迟数百毫秒 - 服务端返回的 HTML 片段若含图片，确保其
src是现代格式 URL，而非原始 JPG 路径
真正难调的不是“怎么让页面动起来”，而是“怎么让它在 resize、tab 切换、网络抖动、低端 GPU 上都不掉帧”——这些场景下，transform 和 opacity 是仅有的安全出口，其他任何样式变更都得先问一句：它会触发 layout 吗？
