picture标签本身不提升性能，真正决定高性能的是media、srcset、sizes和服务端配置的严丝合缝；任一错误（如括号缺失、source顺序错、type与响应头不一致）都会导致浏览器静默回退到img src。
picture 标签本身不提升性能，它只是把选择权交给浏览器；真正决定是否高性能的，是你写的 media、srcset、sizes 和服务端配置是否严丝合缝——错一个括号、漏一个 sizes、type 和响应头不一致，浏览器就静默回退到 <img src>，你根本看不到报错。
为什么写了 picture 却始终只加载小图或 fallback 图
这不是浏览器不支持，而是条件没被识别或匹配逻辑崩了：
-
media属性写在<picture>标签上（如<picture media="(max-width:768px)">）→ 整个属性被忽略 -
media="(max-width: 768px)"缺括号 → 写成media="max-width: 768px"就失效 -
<source>放在<img>后面 → 浏览器跳过所有<source>，只加载<img src> - 断点重叠：比如同时有
min-width: 768px和min-width: 1024px→ 1024px 设备永远命中第一条，大图加载不上
移动端优先的 media 断点怎么写才不踩坑
产品图常需不同构图（桌面展全貌，手机只突出主体），用 media 配合预裁图最稳妥，但顺序和语法必须卡死：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 断点从宽到窄写：
media="(min-width: 1200px)"→media="(min-width: 768px)"→media="(max-width: 767px)"，浏览器匹配第一个就停 - 括号不能少：
media="tablet"或media="screen and (max-width: 768px)"都非法，会被静默丢弃 - 避免缝隙：用
max-width: 479px/min-width: 480px/min-width: 1024px，别留 480–1023px 这种模糊区间 -
<source>必须在<img>前，且<img>必须存在并含src和alt—— 它是语义基础，也是旧浏览器唯一能读的内容
type="image/webp" 被跳过？先看 Network 面板里的 blocked:mime-type
WebP 能省 30%+ 体积，但浏览器只认两件事：声明和响应头必须完全一致：
立即学习“前端免费学习笔记（深入）”；
-
type="image/webp"对应的服务端Content-Type必须是image/webp（大小写、拼写、空格全要对） -
type="webp"或type="image/jpg"是非法值，Chrome 直接静默丢弃该<source> - 推荐三层 fallback：
<source type="image/webp">→<source type="image/jpeg">→<img src=".jpg"> - 别只靠
type：WebP 不支持的旧安卓 WebView 会跳过全部<source>，最终靠<img>拿 JPEG 保底
最麻烦的不是写错，而是所有配置都对了，但图片尺寸在 CSS 里是动态计算的（比如 grid-template-columns: repeat(auto-fit, minmax(300px, 1fr))），而 sizes 还写成 "100vw" —— 这会导致高清屏选错源，且无法通过 DevTools 直观定位。这时候得用 JS 注入真实占位宽度，或者改用 srcset + x 描述符配 sizes 算式。
