IE和Edge≤18完全不识别decoding属性，会被静默忽略；部分安卓WebView（Chromium 80–86）虽能解析但未启用后台解码，decoding="async"形同虚设。
decoding属性在哪些浏览器里根本不起作用
Chrome ≥ 87、Firefox ≥ 78、Safari ≥ 16.4 支持 decoding，但 IE 和 Edge ≤ 18 完全不识别该属性——它会被浏览器静默忽略，连解析都不会做。不是报错，而是当它不存在。这意味着你在这些旧浏览器里写 decoding="async" 或 decoding="sync"，DOM 中能看到，但行为完全等同于没写。
更隐蔽的问题是：部分安卓 WebView（尤其基于 Chromium 80–86 的定制内核）虽能解析该属性，但实际解码路径未启用后台线程，decoding="async" 形同虚设。验证方式很简单：用 Chrome DevTools 打开 Performance 面板，滚动瀑布流页面，看主线程“Image Decode”任务是否明显减少；若无变化，大概率是内核太老或被绕过。
为什么写了decoding却没效果：三个常见覆盖场景
属性写对了，但没生效，往往是因为它被其他逻辑覆盖或阻断：
-
loading="lazy"配合overflow: hidden的父容器：图片永远进不了视口，img.complete始终为false，解码阶段压根不会触发 - JS 懒加载库（如 lozad、vanilla-lazyload）在滚动时才动态替换
src或data-src：此时原生decoding已绑定到旧 DOM 节点，新插入的img元素没带该属性 -
<picture>或<source>上写了decoding：规范明确要求该属性**只作用于最终渲染的<img>元素**，<picture>内部所有decoding设置都会被浏览器完全忽略
兼容性兜底：不支持decoding时该怎么补
不能指望旧浏览器自动降级，得主动应对：
立即学习“前端免费学习笔记（深入）”；
- 对 IE 和旧 WebView，直接不写
decoding属性，改用更保守策略：压缩图片体积（≤ 100KB）、强制用width/height、避免批量大图同屏渲染 - 对支持
decoding但行为不可靠的中间版本（如某些安卓 WebView），可用特性检测快速判断：const img = new Image();<br>if ('decoding' in img) {<br> // 可安全使用<br>} - 关键帧同步需求（如 canvas 绘图首帧）别只靠
decoding="sync"：必须配合await img.decode()，否则即使属性生效，也可能因 race condition 导致naturalWidth读不到
框架里加decoding容易被吃掉，怎么确认它真在起作用
React、Vue 或 Next.js 的图片组件（如 next/image、v-img）通常封装了懒加载、尺寸适配、格式 fallback 等逻辑，会重写原始 <img> 标签。手动加的 decoding 很可能在渲染过程中被丢弃或覆盖。
上线前务必检查最终 DOM：
- 打开 DevTools → Elements 面板，搜索
<img，确认目标元素上确实存在decoding="async"或decoding="sync" - 右键 → “Break on” → “attribute modifications”，然后刷新页面，看是否在 JS 插入/替换节点时被移除
- 若发现属性消失，优先查框架文档是否提供
decoding透传配置项（例如next/image的decodingprop），而不是硬塞到unoptimized模式下
最易被忽略的一点：decoding 不是“开关”，它是解码调度策略的声明。浏览器是否执行、何时执行、执行效果如何，取决于图片是否已下载完成、主线程负载、GPU 后备缓冲区状态等多个实时条件——它本身不保证结果，只承诺行为意图。
