频繁重绘虽不改布局，但高频触发会卡顿；关键在于控制最小粒度、最低频次、最轻路径：visibility:hidden仍占位扩大重绘，box-shadow/filter等属性强制整层重绘，应通过translateZ分层、rAF节流、class切换优化。

频繁重绘本身不改布局，但每秒几十次就会卡顿——关键不是“禁用重绘”，而是把重绘控制在最小粒度、最低频次、最轻路径上。

哪些 CSS 属性一改就偷偷扩大重绘范围

很多人以为只改 color 或 background-color 就很安全，其实浏览器仍可能扩大重绘区域：

• visibility: hidden 不触发回流，但元素仍占位，重绘范围包含其原始布局区域；换成 display: none 会触发回流，但后续显示时重绘区域更小
• box-shadow 和 text-shadow 每次变化都强制重绘整块渲染层，尤其模糊半径大时像素填充量剧增
• opacity 在 0–1 之间连续变化时，若合成层未成功创建（如旧版 Safari 或未启用硬件加速的 Chrome），会退化为逐帧重绘
• filter: blur() 或 filter: brightness() 要求浏览器对整个元素做像素级处理，成本远超纯颜色变更

用 will-change / translateZ 强制分层是否有效

分层是控制重绘粒度的核心手段，但必须确认它真生效了：

• 加 will-change: transform 是提示，不是保证；长期开启会吃 GPU 内存，且部分浏览器（如 Safari）静默忽略
• transform: translateZ(0) 或 transform: translate3d(0, 0, 0) 更稳妥，兼容性好，能稳定创建新渲染层
• 父容器有 overflow: hidden 或 border-radius 会剪裁合成层，导致浏览器无法复用层缓存，每次重绘都得全量重画
• 务必打开 DevTools 的 Layers 面板验证：目标元素是否真在独立层？若和文字、图片挤在同一层，改一个就重绘全部

JS 修改样式时怎么避免高频重绘

JavaScript 不直接重绘，但它调度不当会让重绘失控：

Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转

实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。

下载

• 别在 scroll 或 input 回调里直接改 el.style.color——60fps 下等于每秒 60 次重绘；改用 requestAnimationFrame 节流
• 避免循环中读取 getComputedStyle(el).color，它会强制同步刷新样式队列，间接拖慢重绘调度
• 用 el.classList.toggle('active') 替代 el.style.color = 'red'，class 切换更易被浏览器批处理
• 批量更新多个同类型元素时，先用 document.body.classList.add('batch-update') 触发预设 CSS 类，比逐个操作更高效

contenteditable 自适应高度为何一加就卡

这不是 DOM 太大，而是浏览器对 contenteditable 元素开启了实时 layout + paint 通道：

• 每次输入、粘贴、光标移动都会触发完整同步 layout + paint，哪怕只输一个字
• 错误写法：el.innerHTML 读写、:focus 里带 box-shadow、父容器用 flex 却没设明确高度
• 正确做法：先 el.style.height = 'auto'，再 el.style.height = el.scrollHeight + 'px'，空内容时用 textContent.trim().length === 0 兜底设最小高度
• 包一层 requestAnimationFrame，避免粘贴大段文本时连续触发 layout；禁用 overflow-y: scroll，改用 hidden

真正难优化的不是单次重绘，而是那些藏在事件回调里的「高频小重绘」——它们叠加起来比一次大重排更伤性能，且极难被 Layers 面板直接捕获。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！