浏览器按顺序匹配首个满足media和type的<source>即停止，不选最优；<img>是强制兜底，缺src或404则整个picture不渲染图片。
图片降级加载顺序不是“浏览器自动选一个备用”，而是由 HTML 解析顺序、<picture> 内 <source> 的排列顺序、以及 <img> 的 src 是否可用三者共同锁定的。顺序写错，高兼容格式会直接被跳过；<img> 缺失或 src 不可用，整个降级链就断了。
为什么 <source> 顺序不能调换
浏览器从上到下逐个检查 <source>，遇到第一个 media 匹配且 type 被当前浏览器支持（并能解码）的，就加载它，然后停止扫描。这不是建议，是硬性执行逻辑。
-
type="image/avif"必须放最前——AVIF 压缩率最高但支持度最窄（Chrome/Firefox/Edge ≥120），放后面等于白写 -
type="image/webp"居中——覆盖 iOS 14+、主流桌面浏览器，但 Safari ≤13.1 和旧 WebView 不认 - 绝不能把
type="image/jpeg"或type="image/png"写成第三个<source>——<picture>不支持这些 MIME 类型的老浏览器（如 IE、Android 4.4 WebView）根本不会尝试它们
img src 是强制兜底，不是可选项
<img> 标签不是“备选 source”，它是整个 <picture> 结构的语义终点和加载兜底入口。没有它，<picture> 就不渲染任何内容，也不发任何请求。
-
<img>的src必须指向一个真实可用的资源，比如/assets/fallback.jpg，不能是src="#"、空字符串或带查询参数的动态地址（如?format=webp） - 如果
src指向 404 路径，整个<picture>会退化为只显示alt文本，不加载任何图 - 这个
src图片必须是 JPEG 或 PNG 格式，且服务器返回状态码为 2xx，否则降级失败
loading="lazy" 和 onerror 怎么配合才不破坏降级
这两个属性容易互相干扰：一个控制是否延迟发起请求，一个只响应请求失败，但都不管“路径解析失败”或“CORS 静默拦截”这类问题。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
-
loading="lazy"不支持时，浏览器直接忽略该属性，不会 fallback 到data-src——所以src仍需指向一个可用资源（如 1px GIF 或 LQIP） -
onerror只在 HTTP 状态非 2xx 或网络中断时触发；对src=""、跨域没加crossorigin、404 返回占位图（状态码 200）等情况完全静默 - 可靠写法是内联绑定：
onerror="this.onerror=null;this.src='/assets/placeholder.svg'"，且占位图优先用data:image/svg+xml;base64,...内联，避开路径风险
轮播图首图必须写死在 HTML 里
JS 初始化失败、网络极慢或禁用 JS 时，轮播逻辑根本不会执行。此时唯一能起作用的是 HTML 原生结构。
- 第一张图必须用标准
<img>写在轮播容器最前面，带真实src和alt - 其余图片只能存
data-src或放在 JS 数组里，不能生成带src的<img>标签——否则无 JS 时页面会显示一堆破碎图标 - CSS 可用
:first-child强制首图可见，即使动画或 JS 失效，用户至少看到一张图
真正容易被忽略的是：所有降级路径都依赖「每个环节都提供真实可用的资源」。AVIF 放最前没错，但如果 <img src> 指向的是 404，那连老浏览器都看不到图；onerror 写得再全，也救不了 CORS 拦截或空 src 这种解析层错误。降级不是堆功能，是环环校验。
