decoding="async"解决大图解码阻塞主线程问题，将宽≥1000px或体积≥200KB图片的解码移至后台线程，避免滚动、点击卡顿；但需配合loading="lazy"、显式宽高及WebP/AVIF格式才有效。
decoding="async"到底解决什么问题
它只管解码时机，不管下载——图片数据下载完后，浏览器在主线程同步解码会卡住滚动、点击等交互；decoding="async"把这步挪到后台线程，主线程继续响应用户操作。但前提是：这张图真得“大”，否则开销反超收益。
常见误判：decoding="async"不是给所有图加就变快。小图标、头像、按钮背景图加了反而可能因调度延迟短暂闪白，尤其快速滚动表格时更明显。
- 有效场景：宽 ≥ 1000px 或体积 ≥ 200KB 的图（如报表截图、设计稿预览、商品详情大图）
- 无效甚至有害：尺寸 ≤ 200×200 的 PNG/JPEG、未压缩图、首屏 banner 图
- 注意：现代浏览器（Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4）对未声明
decoding的<img>默认走异步路径，不写 ≠ 同步
表格里加decoding="async"必须配齐的三件事
表格单元格（<td>）本身不设尺寸，decoding="async"单独写上去等于没设——解码完成后触发重排，Paint flashing 比卡顿还刺眼。
-
loading="lazy"：防止长表格一渲染就批量触发下载+解码，尤其滚动时 - 显式
width和height（或aspect-ratio）：锁定单元格尺寸，避免解码完成导致列宽跳变、CLS 偏移 - 现代格式（
.webp或.avif）：JPEG 在大图上解码压力更大，异步收益严重依赖格式压缩率
漏掉任一环，decoding="async" 就只是 DOM 里一个安静的装饰属性。
立即学习“前端免费学习笔记（深入）”；
为什么写了decoding="async"还是卡
卡的根源往往不在解码本身，而在布局干扰和资源竞争。表格场景下最容易被忽略的是：
-
srcset没配sizes：浏览器选错高清图，单张表单元格图体积翻倍，解码压力不降反升 - 父容器用了
overflow: hidden+loading="lazy"：某些<tr>被裁剪，图片永远不进视口，根本不会加载 - 同一屏表格行塞了 5 张以上大图：即使异步解码，后台线程仍排队处理，GPU 纹理上传阶段可能挤占资源
-
<picture>里写decoding="async"：该属性只认最终渲染的<img>标签，<source>上设了也无效
动态生成表格时decoding赋值的坑
JavaScript 拼字符串插入表格，或框架（React/Vue）渲染时，decoding 极易漏设或设晚。
- 旧版 Chrome（≤ 86）会静默丢弃后设的
decoding：必须在img.src = url之前赋值 - 用
createObjectURL()时同理：要在img.src赋值前设好decoding - 组件库（如 Ant Design Table）通常已封装懒加载逻辑：手动加
decoding="async"可能被覆盖，得检查最终 DOM 是否真有该属性 - 框架中用
v-for/map()渲染，别在模板里硬写decoding="async"，优先用 computed 或 useEffect 控制赋值时机
真正难处理的是「表格首行固定 + 大图 + 滚动监听」这种组合——此时 decoding="async" 只解决一半问题，得配合 img.decode() 手动控制解码完成时机，否则快速滚动时图片仍延迟渲染。
