有用，但仅在图片数据已下载完成且解码耗cpu时生效，需配合loading="lazy"、显式宽高和现代格式，否则会被覆盖或无效。
decoding="async"对大图滚动卡顿到底有没有用
有用，但只在特定条件下生效：图片数据已下载完成、且解码本身耗 CPU（比如宽 ≥ 1000px 的 WebP/AVIF）、同时主线程正忙于滚动或动画。它不加速下载，也不减少像素量，只是把解码从主线程挪到后台线程——实测瀑布流中 120 张 1600×900 WebP 图滚动时，主线程解码耗时下降 52%。
为什么加了decoding="async"还是卡
不是属性没起作用，而是被其他行为抵消或覆盖：
-
loading="lazy"配合overflow: hidden父容器，导致图片永远不进入视口，根本不会触发加载和解码 -
srcset没配sizes，浏览器选了 4K 高清图，体积翻倍，解码压力反而更大 - JS 懒加载库（如 lozad）在滚动后才动态替换
src，覆盖了原始decoding="async"设置 - 没设
width/height或aspect-ratio，解码虽异步，但后续绘制频繁重排，DevTools 中Rendering > Paint flashing大面积闪红 -
<picture></picture>或<source></source>上写了decoding，但该属性只对最终渲染的<img>生效，会被完全忽略
JavaScript 动态插入大图时怎么设 decoding
必须在设置 src 之前赋值 decoding，否则旧版 Chrome 会静默丢弃：
const img = new Image(); img.decoding = 'async'; // ✅ 必须在这一步 img.src = '/large-photo.webp'; img.loading = 'lazy'; img.width = 1200; img.height = 800; container.appendChild(img);
- 如果用
createObjectURL()+fetch()加载，也要确保decoding在src赋值前设置 - 框架组件（如
next/image）通常已内置解码逻辑，手动加decoding="async"可能被覆盖，需检查最终 DOM 是否真实存在该属性 - 不要写
decoding="auto"—— 所有主流浏览器（Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4）实际都按sync处理，写了等于白写
真正起效必须配套的三个硬条件
decoding="async" 不是开关，是链路中的一环，漏掉任一环节就失效：
- 必须作用于最终渲染的
<img>元素（<picture></picture>和<source></source>上设无效） - 必须配合
loading="lazy"使用——两者不互斥，但只有懒加载触发后，decoding才有机会参与解码调度 - 必须有显式宽高（
width/height或aspect-ratio），否则异步解码完成后仍会触发 layout shift，视觉上反而更卡
最容易被忽略的是：它只优化“解码”这一步，不解决图片体积大、格式老旧、CDN 延迟高等问题。一张没压缩的 5MB AVIF，即使 decoding="async"，解码本身就要 120ms+，异步只能换线程，不能省时间。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
