<picture> 本身不处理透明度，它仅作为资源选择容器，真正决定透明效果的是 <img> 加载的图片格式及其 alpha 通道是否完整保留。
为什么 <picture> 本身不处理透明度
<picture> 只是资源选择容器，它不决定图像是否透明——真正起作用的是你塞进去的 <img> 所加载的图片格式（如 PNG、WebP）和其 alpha 通道是否保留。浏览器会按 <source> 规则选一个最匹配的资源，然后把那个文件原样渲染。如果源图没透明通道，换再多个 <source> 也没用。
常见错误是以为加了 <picture> 就能“开启透明支持”，结果导出的 JPG 被塞进 <source>，背景还是白底。
- 确保所有
<source>指向的图片本身带 alpha 通道（PNG-24、WebP、AVIF） - JPG 不支持透明，哪怕写成
type="image/jpeg"也白搭 - 不要依赖 CSS 的
opacity模拟“透明图”——那只是整体变淡，不是 alpha 混合
怎么让 <picture> 正确加载带透明的 PNG / WebP
关键在 <source> 的 type 和路径指向必须匹配真实文件格式，且服务器返回的 MIME 类型要正确（比如 image/png）。否则浏览器可能忽略该 <source>，退回到 <img> 的 src，而那个 src 如果是 JPG 就彻底没透明了。
示例：
立即学习“前端免费学习笔记（深入）”；
<picture> <source media="(min-width: 768px)" srcset="logo.webp" type="image/webp"> <source media="(min-width: 768px)" srcset="logo.png" type="image/png"> <source srcset="logo-small.webp" type="image/webp"> <img src="logo-small.png" alt="logo"> </picture>
- 每个
srcset对应的文件必须真实存在，且是带透明的 PNG/WebP - 检查浏览器开发者工具的 Network 面板：确认加载的是
.png或.webp，不是 404 后 fallback 到 JPG - 本地测试时注意：某些本地服务器（如 VS Code Live Server）对 WebP 的 MIME 支持不全，可能返回
text/plain，导致<source>被跳过
遇到透明边缘发灰/发白怎么办
这是最常见的“看似透明实则漏底”问题，根源通常是图片导出时用了“杂边（matte）”或“半透明像素被错误预乘”。设计工具（如 Figma、Photoshop）导出 PNG 时若勾选了“Background color”或“Matte”，就会把 alpha 周围填上指定颜色，导致边缘出现灰白晕。
- Figma 导出：关闭
Include background color，选PNG (transparent) - Photoshop：“文件 → 导出 → 导出为”，取消勾选
Convert to sRGB和Matte - 用命令行验证：运行
file logo.png，输出应含color type = truecolor + alpha；若出现color type = truecolor（无 alpha），说明导出失败
要不要用 <picture> 加 WebP + fallback？
要，但得看场景。WebP 透明支持好、体积小，但 iOS Safari 14 以下不支持 WebP 的 alpha 通道（只支持 lossy）。如果你的用户仍有大量 iOS 13 及更早设备，<source type="image/webp"> 在那些设备上会被跳过，靠 <img src="xxx.png"> fallback 是安全的；但如果误把 fallback 写成 JPG，就全完了。
- 兼容性底线：至少保证
<img>的src是 PNG - WebP 不是银弹：部分安卓 WebView（尤其旧版）对 WebP alpha 解码异常，可加
fetchpriority="low"减少阻塞，但不能解决渲染缺陷 - 真要极致控制，不如直接上
<img src="logo.png">+srcset，省去<picture>的复杂度，除非你确实需要不同尺寸/艺术指导/格式切换
透明图的核心从来不在标签嵌套多深，而在每一张图的像素里有没有干净的 alpha 通道——<picture> 只是帮你把它准确送进浏览器的快递员，别让它送错包裹。
