会，decoding="sync" 会明确阻塞渲染，浏览器强制等待图片解码完成才继续布局绘制；典型表现为滚动时内容“突然跳入”、lcp 指标变差；仅在 canvas 绘图依赖像素数据或特定解码兼容性问题时需使用。
img 的 decoding 属性设为 "sync" 会阻塞渲染吗？
会，而且是明确的、可观察的渲染阻塞。当 decoding="sync" 时，浏览器会强制等待该图片完成解码（即像素数据准备就绪）后，才继续布局和绘制后续内容——哪怕图片已加载完成（loaded），只要没解码完，就卡住渲染流水线。
典型表现：滚动页面时，图片下方区域“突然跳入”，或首屏关键内容延迟显示；Lighthouse 的 largest-contentful-paint（LCP）指标明显变差。
-
decoding="sync"主要用于需要像素级精确控制的场景，比如 Canvas 绘图前必须确保图片已解码完毕 - 默认值是
"async"，浏览器会异步解码，不阻塞主线程渲染 -
"auto"由浏览器决定（现代浏览器基本等同"async"）
什么时候必须用 decoding="sync"？
极少。仅在以下两种情况有实际必要：
- 用
ctx.drawImage(img, ...)向<canvas></canvas>绘制前，且你依赖图片的width/height或像素数据（如ctx.getImageData()），而图片尚未触发解码（例如刚设置src就立即调用绘图） - 服务端返回的图片格式存在解码兼容性风险（如某些 WebP 变体在旧 Chrome 中需同步解码才能避免渲染空白），但这种情况应优先修复图片源而非硬加
sync
注意：img.complete 为 true 并不表示已解码——它只代表加载完成。真正判断是否可安全绘图，应监听 img.decode() Promise：
img.addEventListener('load', () => {
img.decode().then(() => {
ctx.drawImage(img, 0, 0); // 此时 width/height 和像素数据 100% 可用
});
});
decoding="sync" 在不同浏览器中的行为差异
行为基本一致，但兼容性边界需留意：
- Chrome 69+、Firefox 69+、Safari 15.4+ 支持
decoding属性 - Safari 15.4 之前完全忽略该属性（等效于
"auto"），所以加了也无副作用，但也不起作用 - IE 和旧 Edge 不支持，会被直接忽略
- 所有支持该属性的浏览器中，
"sync"均表现为同步解码 + 渲染阻塞，无例外
如果你的项目需兼容 Safari decoding="sync" 做逻辑判断；若用 img.decode()，需加 Promise polyfill 或 fallback。
替代方案：比 decoding="sync" 更可控的解码控制
绝大多数场景下，用 img.decode() 显式触发并等待解码，比全局设 sync 更精准、副作用更小：
- 只对真正需要的图片调用
img.decode()，不影响其他图片的渲染流水线 - 可配合
IntersectionObserver按需解码，避免首屏外图片提前占用 CPU - 失败时能捕获错误（
img.decode().catch(...)），而decoding="sync"失败只会静默降级为异步
示例：仅对即将进入视口的图片预解码
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.decode().catch(() => { /* 解码失败，仍可 fallback 显示 */ });
observer.unobserve(img);
}
});
});
真正难处理的是多图并发解码时的 CPU 峰值——这没法靠 decoding 属性缓解，得靠节流或分帧（requestIdleCallback）来摊平。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
