预加载透明图片与普通图片技术路径一致，关键在<link rel="preload" as="image">必须指定且href为静态路径；WebP/PNG需分别预加载以支持fallback；new Image()须先绑事件再赋src并检查complete。
预加载透明图片（比如 PNG、WebP 含 Alpha 通道）和预加载普通图片在技术路径上完全一致，但**透明特性本身不改变预加载逻辑，只影响渲染结果与 fallback 行为**。关键在于别让格式特性干扰资源获取流程。
用 <link rel="preload"> 预加载 WebP/PNG 透明图必须指定 as="image"
浏览器靠 as 属性决定如何处理缓存、解码和优先级。如果漏掉或写错（比如写成 as="fetch"），即使 URL 指向的是 .webp 或 .png，浏览器也可能跳过图片特有的解码优化，甚至不进图片缓存池。
-
href必须是静态路径，不能含 JS 变量或模板字符串，例如href="/assets/logo.webp"✅，href=`/assets/${name}.png`❌（直接 404） - 相对路径要以 HTML 文件位置为基准，推荐统一用根路径
/assets/xxx.png - WebP 透明图无需额外声明，只要文件本身含 Alpha 通道，
<link>加载后就能被后续<img src>正常复用
用 new Image() 预加载时，img.complete 判断比 onload 更可靠
透明图常用于首屏关键元素（如带阴影的 logo、毛玻璃背景图），缓存命中率高。但缓存命中时 onload 是同步触发的——如果你先赋值 src 再绑定事件，回调会直接丢失。
- 必须严格按顺序：先设
img.onload/img.onerror，再赋img.src - 赋值后立刻检查
img.complete === true，为true就说明已就绪，需立刻执行成功逻辑（比如解锁 UI、触发绘制） - 不要依赖
img.naturalWidth > 0判断是否加载完成，它在部分旧版 Safari 中不可靠
WebP 透明图需要 fallback？<link rel="preload"> 不负责 fallback
<link rel="preload"> 只管下载，不参与渲染决策。如果你用 <picture> 做 WebP + PNG fallback，那么预加载也得对应两套：
立即学习“前端免费学习笔记（深入）”；
- 对 WebP 版本：加
<link rel="preload" as="image" href="/assets/logo.webp"> - 对 PNG fallback：加
<link rel="preload" as="image" href="/assets/logo.png">（仅当浏览器不支持 WebP 时才可能用到） - 不要试图用一个
<link>同时覆盖两种格式——浏览器不会自动降级 - 如果只预加载 WebP，而用户浏览器不支持（如旧版 Edge），后续
<picture>仍会正常请求 PNG，但此时 PNG 没预加载，首屏可能出现延迟
真正容易被忽略的点是：预加载透明图时，你无法从网络面板或缓存状态里直观判断“Alpha 通道是否被正确解析”。它只在真正渲染时才暴露问题——比如白底上 PNG 透明区域变成灰色块，那大概率是图片本身导出异常，而非预加载失败。
