<picture> 标签仅负责资源选择，不参与重绘优化；重绘由 CSS 层级、合成策略及动画属性决定，其核心价值在于前置资源决策、避免 JS 切图引发的额外重绘。
<picture> 标签本身不解决“多图片重叠”导致的重绘问题——它根本不管重绘，只管**选哪张图加载**。重叠、定位、层叠（z-index）、动画触发重排重绘，这些全是 CSS 和 DOM 层的事。把 <picture> 当成“防重绘神器”，是常见误解。
为什么<picture>和重绘完全无关
<picture> 是一个**资源选择器**：它在 HTML 解析阶段根据 <source media> 或 srcset 条件，决定最终哪个 src 被赋给内部的 <img>。一旦选完，剩下的就是普通 <img> 渲染流程。它不改变 DOM 结构层级，不添加/移除元素，也不触发动画或样式变更。
所谓“多图片重叠”，通常指：
- 多个
<img>或<picture>绝对定位堆在一起 - 用
background-image+content图片双层叠加 - 伪元素
::before/::after插入图片再叠在主图上
- CSS
transform、opacity、filter动画没启用合成层 - 频繁修改
top/left等几何属性触发 layout - 没设
will-change或transform: translateZ(0)提前升层
重叠图片卡顿？先检查容器是否走 GPU 合成
如果重叠图层在滚动/悬停/缩放时掉帧，大概率是浏览器还在用 CPU 做重绘。必须让每个参与重叠的图层单独成为合成层：
给最外层容器（比如包裹 <picture> 的 <div class="overlay-stack">）加：
立即学习“前端免费学习笔记（深入）”；
.overlay-stack {
will-change: transform;
/* 或 */
transform: translateZ(0);
}同时确保每个子图层（包括 <picture> 内部的 <img>）满足以下至少一条：
- 有
transform（哪怕只是translateZ(0)） - 有
opacity且值 ≠ 1 - 有
filter（哪怕只是blur(0.1px)） - 父容器已设
will-change
用<picture>配合语义结构减少不必要的重绘触发
虽然 <picture> 不直接优化重绘，但它能帮你**避免错误的重绘诱因**。例如：
错误做法：用 JS 监听 resize，手动切换 img.src —— 每次切换都触发一次解码 + 重绘，还可能造成 layout thrashing。
正确做法：用 <picture> + <source media> 让浏览器在解析时就锁定资源，后续无 JS 干预：
<picture> <source media="(min-width: 768px)" srcset="hero-desktop.webp 1x, hero-desktop@2x.webp 2x"> <source media="(max-width: 767px)" srcset="hero-mobile.webp 1x, hero-mobile@2x.webp 2x"> <img src="hero-fallback.jpg" alt="Hero image"> </picture>
这样，即使你用绝对定位把这张图和其他图层重叠，只要不改它的尺寸或位置，浏览器就不会因为“换图”而额外重绘。关键点在于：<picture> 把资源决策前置，把 DOM 和样式稳定下来。
真正要防重绘，得盯紧 CSS 层级、合成策略和动画属性；<picture> 只负责让那张被叠在最上面的图，从一开始就是对的、不用换的、不拖慢主线程的。
