必须用 Chrome DevTools 的 Layers 和 Rendering 面板定位真实重绘区域；确认元素是否在独立渲染层，需观察 Layers 面板中其是否单独成层，而非依赖 will-change 提示，真正稳定触发合成的是 transform: translateZ(0) 或 translate3d(0, 0, 0)。
重绘频繁不是“有没有”的问题，而是“在哪、多频、多重”的问题；必须用 DevTools 的 Layers 和 Rendering 面板定位真实重绘区域，而不是靠猜或删代码。
怎么确认某个元素真在独立渲染层？
浏览器不会因为你写了 will-change: transform 就自动升层——它只是个提示，且 Safari 会静默忽略。真正可靠的是 transform: translateZ(0) 或 transform: translate3d(0, 0, 0)，它们能稳定触发合成层创建。
- 打开 Chrome DevTools → More Tools → Layers，滚动/交互时观察目标元素是否单独成层
- 若元素和文字、图标挤在同一层，改一个颜色也会重绘整块区域
- 父容器设了
overflow: hidden或border-radius，会剪裁合成层，导致层缓存失效，每次重绘都得全量重画 -
filter: blur()或box-shadow模糊半径 > 2px 时，像素填充量指数级增长，Layer 面板里能看到该层尺寸异常膨胀
scroll/input 里直接改 style.color 为什么卡？
不是 color 本身贵，而是每帧都触发一次重绘调度：60fps 下等于每秒 60 次重绘请求，浏览器来不及合并或跳过，直接压垮主线程。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 把
el.style.color = 'red'换成el.classList.toggle('active')，让样式变更走 CSSOM 批处理 - 用
requestAnimationFrame节流，确保最多每帧只更新一次，哪怕事件触发 100 次 - 避免在循环里读
getComputedStyle(el).color—— 它强制同步 flush 样式队列，间接拖慢重绘节奏 - 批量更新同类型元素（如列表项高亮），优先给
document.body加临时 class，用预设 CSS 规则控制，别逐个操作
visibility: hidden 和 display: none 在重绘上差别在哪？
visibility: hidden 元素仍参与布局、占位，重绘范围包含其原始尺寸区域；display: none 会触发重排，但后续显示时重绘区域更小，且不进渲染树。
立即学习“前端免费学习笔记（深入）”；
- 高频切换显示/隐藏的浮层、下拉菜单，用
display: none+ class 切换比visibility更可控 -
opacity: 0连续变化时，若合成层未成功创建（如旧版 Safari 或禁用硬件加速），会退化为逐帧重绘，比display: none开销更大 -
contenteditable元素加了visibility: hidden也照样卡——因为浏览器对它开了实时 layout + paint 通道，输入/光标移动都会强制刷新
最常被忽略的点：重绘成本不只看单次，而看「是否可被浏览器合并」。class 切换、translateZ 分层、rAF 调度，本质都是在帮浏览器把零散请求攒成一批——不是减少动作，而是让动作可预测、可批处理。
