<picture> 不支持嵌套，其内容模型仅允许 <source> 和 <img> 且必须严格按顺序排列，<img> 必须为最后一个子元素并带 src 属性，否则渲染为空白；浏览器静默忽略非法结构或语法错误，不报错但逻辑失效。
为什么 <picture> 不能嵌套在另一个 <picture> 里
浏览器解析时会直接忽略外层 <picture> 的语义，把内部所有 <source> 和 <img> 提升到同一层级处理。结果是：你写的嵌套结构在 DOM 中根本不存在，所有 <source> 变成无序并列，匹配逻辑彻底失效。
- Chrome/Firefox 遇到
<picture><picture>...</picture></picture>，会把内层<source>当作外层的子元素，但外层没有闭合，导致后续 DOM 偏移 - 即使侥幸渲染出图，
media条件也因上下文丢失而无法正确计算（比如sizes依赖父容器宽度） - W3C 规范明确将
<picture>定义为“流式内容容器”，其内容模型只允许<source>和<img>，不允许嵌套自身或其他同类容器
<picture> 内部的 <source> 和 <img> 必须严格按顺序排列
顺序不是风格建议，而是执行逻辑：浏览器从上到下扫描，遇到第一个合法且匹配的 <source> 就停止，加载它的 srcset，其余全部跳过。
- 错误写法：
<source media="(max-width: 768px)">放最前 → 所有设备（包括桌面）都命中这个宽泛条件，后面高分辨率规则永不可达 - 正确顺序：先写
min-width+min-resolution组合（如(min-width: 1440px) and (min-resolution: 2dppx)），再逐级放宽 -
<img>必须是最后一个子节点，且必须带src—— 缺失则整个<picture>渲染为空白，不会报错，也不会 fallback 到其他<source>
浏览器容错不等于结构容错：DOM 会被悄悄重写
你写的 HTML 和实际生效的 DOM 往往不一致。比如漏写 <img>、media 语法错误、或 type="image/webp" 但服务器返回 text/plain，浏览器不会报错，而是静默跳过该 <source>，继续往下找。
-
media="(max-width: 768px)"（缺括号）→ 整个<source>被忽略，等同于不存在 -
srcset项里混用w和x描述符（如"a.jpg 400w, b.jpg 2x"）→ 整个srcset解析失败，该<source>不参与选择 - 服务器未配置 WebP 的
Content-Type→ Chrome 显示blocked:mime-type，该<source>直接失效，不尝试下一个
真正需要“多层决策”时，别硬套 <picture> 嵌套
如果需求是“先按格式选 WebP/AVIF，再按 DPR 选 @2x/@3x，最后按视口选裁剪构图”，<picture> 本身无法分层判断。它只做一次顺序匹配。
立即学习“前端免费学习笔记（深入）”；
- 方案一：用
type+media组合，把最高优先级格式放最前（如 WebP + 大屏），但注意：Chrome 支持 WebP 就用它，不支持就跳过整条，不会退到 JPEG 的同尺寸源 - 方案二：放弃纯声明式，用 JS 预检
fetch()+response.headers.get('content-type')，再动态设置<img>.src—— 这才是可控的多层 fallback - 方案三：回归
<img srcset="" sizes="">，它对 DPR 和视口宽度的混合适配更鲁棒，且兼容性更好（Safari 9+、Edge 16+）
<picture> 的“容错”只体现在静默跳过非法节点，而不是帮你修复逻辑。你看到图加载出来了，不代表所有 <source> 都起效了——可能只是碰巧第一个就匹配了。检查 Elements 面板里的实际加载资源，比看源码更可靠。
