decoding="async"仅在图片已下载完成且像素解码成主线程瓶颈时生效，适用于宽≥1000px或体积≥200KB的大图，加错反而引发发虚、CLS或naturalWidth读取失败；decoding="sync"仅用于需立即读取尺寸参与布局或严格帧同步的UI基础元素。
decoding 属性不是“让图变快”的开关，而是把像素解码从主线程挪到后台线程的调度指令。它只在图片数据已下载完成、但尚未绘制时起作用——加对了能明显缓解滚动卡顿，加错了反而导致首屏发虚、CLS 抖动或脚本读取 naturalWidth 失败。
decoding="async" 什么时候真正生效
它不加速下载，也不减少总解码耗时，只换线程。生效必须同时满足：
- 图片已完整加载（
img.complete === true且img.naturalWidth > 0） - 图片是位图且尺寸够大：宽 ≥ 1000px 或体积 ≥ 200KB（JPEG/WebP/AVIF）
- 浏览器正在主线程上执行解码，且该步骤成为瓶颈（Performance 面板中
Decode Image占比高） - 图片未被
overflow: hidden等样式锁死视口，能正常触发loading="lazy"加载
decoding="sync" 必须显式写的两种场景
现代浏览器（Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4）对未声明 decoding 的 <img> 默认走异步路径——所以“不写” ≠ 同步。只有以下情况才需强制写 decoding="sync"：
- 需要立即读取
img.naturalWidth或img.naturalHeight参与布局计算（例如动态生成<canvas>贴图、CSS Grid 容器依赖图片尺寸） - 图片是 UI 基础元素且有严格帧同步要求（如动画序列第一帧、实时滤镜入口图），否则可能视觉撕裂
注意：decoding="sync" 会延长主线程占用，禁用懒加载，且不能和 loading="lazy" 共存；首屏 banner、文章配图、头像都不属于这个范畴。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
容易被覆盖或失效的典型配置组合
写了 decoding="async" 还卡？大概率是下面某条在抵消效果：
-
<picture>或<source>上设decoding—— 完全被忽略，必须写在最终渲染的<img>上 - JS 动态创建
img时，先赋值src再设decoding—— 旧版 Chrome 会静默丢弃 -
srcset没配sizes，浏览器误选 4K 图，体积翻倍，解码压力反升 - 父容器用了
overflow: hidden+loading="lazy"，图片永远不进入视口，根本不加载 - 没设
width/height或aspect-ratio，解码虽异步，但绘制阶段频繁重排，Paint flashing大面积闪红
框架组件和动态插入图的特殊处理
Next.js 的 next/image、Nuxt 的 NuxtImg 等通常已内置解码优化，手动加 decoding="async" 很可能被覆盖。上线前务必用 DevTools 查看最终 DOM 是否保留该属性。
通过 fetch() + createObjectURL() 动态插入的图，必须在调用 img.src = url 之前设置 img.decoding = "async"，否则无效。另外要注意：decoding="async" 对 canvas.drawImage() 或 getImageData() 有风险——异步解码可能让脚本拿到未完成解码的图像数据，引发 SecurityError 或空白帧。
