decoding="async"仅在图像数据已下载完成且像素转换耗cpu时生效，适用于宽≥1000px或体积≥200kb的大图、懒加载图、瀑布流缩略图及fetch动态插入图，需配合loading="lazy"、显式宽高和现代图片格式才能真正提升性能。
decoding="async" 不是“让图片加载更快”，而是把解码这一步从主线程挪走——加对了能明显减少滚动卡顿，加错了反而让首屏图发虚或延迟渲染。
什么时候该写 decoding="async"
它只在图像数据已下载完成、但像素转换耗 CPU 的阶段起作用。典型场景包括：
- 宽 ≥ 1000px 或体积 ≥ 200KB 的 JPEG/WebP/AVIF 图（小图如头像、图标加了几乎没收益）
-
loading="lazy"的图片进入视口后触发解码，此时主线程正忙于滚动或动画 - 瀑布流/商品列表中批量出现的缩略图（实测 100+ 张大图滚动时，主线程解码耗时降 40–60%）
- 通过
fetch()+createObjectURL()动态插入的图，且你已提前设好decoding="async"
如果图片还没下载完（比如控制台看到 Failed to load resource），decoding 压根没机会执行。
为什么写了 decoding="async" 还卡
不是属性失效，而是被其他行为覆盖或抵消：
-
srcset没配sizes，浏览器选错高清图，体积翻倍，解码压力反而更大 - 父容器用了
overflow: hidden+loading="lazy"，图片永远不进入视口，加载都不触发 - JS 懒加载库在滚动时才动态替换
src，覆盖了原生decoding设置（禁用 JS 后测试一下就清楚） - 没设
width/height或aspect-ratio，解码虽异步，但后续绘制频繁重排，Chrome DevTools 的 Rendering > Paint flashing 会大面积闪红
decoding 必须配合哪些属性才真正生效
它不是万能开关，漏掉任一环，async 就只是个没用的字符串：
- 必须作用于最终渲染的
<img>元素 ——<picture></picture>和<source></source>上设decoding会被完全忽略 - JavaScript 动态创建
img时，decoding必须在设置src之前赋值，否则旧版 Chrome 会静默丢弃 - 与
loading="lazy"并存时，下载优先级提升，但解码仍排队 —— 大图（如 4K WebP）解码本身就要 80ms+，异步只能换线程，不能省时间 - 框架组件（如
next/image）通常已内置解码优化，手动加decoding="async"可能被覆盖，需检查最终生成的 DOM 确认是否生效
sync / async / auto 三个值怎么选
auto 是规范默认值，但当前所有主流浏览器（Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4）实际都按 sync 处理 —— 写了等于白写，别用。
-
decoding="sync"：仅用于极少数必须像素级同步的场景，比如canvas绘图前要读img.naturalWidth做布局计算，或动画帧序列首帧需严丝合缝 -
decoding="async"：非首屏、非关键、大尺寸/大体积图的明确推荐，但必须搭配loading="lazy"和显式尺寸声明才稳妥 - 完全不写该属性：对首屏 banner、logo、主图最稳妥，默认
sync能保证视觉立即稳定
真正决定解码体验的，从来不是单个属性，而是 decoding + loading + width/height + 图片格式（WebP/AVIF）四者协同；漏掉任一环，async 就只是个没用的字符串。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
