必须显式添加decoding="sync"仅限两类场景：一是需立即读取naturalWidth/Height参与布局计算，如动态canvas贴图或CSS Grid尺寸依赖；二是UI基础元素有严格帧同步要求，如动画首帧或滤镜预览图，否则易致视觉撕裂或layout thrashing。
需要立即读取 naturalWidth/naturalHeight 做布局计算时才用 decoding="sync"
比如你用 JS 动态生成 <canvas>，尺寸要严格匹配图片原始宽高；或者 CSS Grid 容器的列宽依赖 img.naturalWidth 计算。不加 decoding="sync" 时，图片可能已渲染但尚未解码完成，img.naturalWidth 还是 0，导致布局错乱或 canvas 绘制失败。
常见错误现象：img.naturalWidth 为 0、canvas 贴图空白、Grid 列宽塌缩
- 必须在
<img>标签中显式写decoding="sync"，不能靠“不写就默认同步” - 配合
loading="eager"使用，避免懒加载干扰解码时机 - 不要在
img.decode()之前漏掉这个属性——否则 Safari 可能抛SecurityError
动画序列帧第一帧或 UI 基础元素有帧同步硬要求时才用 decoding="sync"
典型场景：启动页 logo 动画首帧、滤镜预览入口图、实时视频封面图。这些元素一旦出现轻微解码延迟，就会和后续帧/交互产生视觉撕裂，或触发 layout thrashing（强制同步布局重排）。
关键判断点：是否“像素级时序对齐”直接影响用户体验，而非“看起来快一点”
立即学习“前端免费学习笔记（深入）”；
-
decoding="sync"不加速加载，只把解码操作锁进主线程，确保渲染前像素就绪 - 多张
sync图并存会排队阻塞，所以仅限首屏内 1–2 个最核心元素 - 大图（>500KB）、懒加载图（
loading="lazy"）、列表头像都不适用，该用decoding="async"
不写 decoding 或写 decoding="auto" 实际等于异步解码
Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4 都把未声明 decoding 的 <img> 当作 decoding="auto" 处理，而 auto 在实践中基本等同于异步——这和直觉相反，很多人误以为“不写就是同步”。
真正难处理的是边界场景：既要解码完成，又不能卡主线程，比如 canvas 动画首帧 + 首屏大图叠加。这时候单靠 decoding="sync" 不够，得结合 img.decode() 手动控制 Promise 时机。
滥用 decoding="sync" 的后果比想象中更隐蔽：低端机上主线程长时间占用、滚动卡顿、甚至触发浏览器降级策略（如跳过部分解码直接渲染模糊占位）。
