<source>标签本身不渲染，仅声明备选资源；在<video>中按DOM顺序尝试首个可解码资源，在<picture>中则依据media查询匹配响应式图像，二者规则不可混用。
<source> 标签本身不渲染、不播放，只声明备选资源；它在 <video> 和 <picture> 中行为完全不同，混用规则会导致静默失败。
video 中的 source：顺序即兼容性，type 必须带 codecs
浏览器按 DOM 顺序逐个尝试 <source>，首个 type 被识别、HTTP 返回 200、且能解码成功的即被采用——后面全部跳过。这不是“选最优”，而是“第一个能用就停”。
- iOS Safari 强制要求第一个
<source src="vid.mp4" type="video/mp4">必须是 H.264 Baseline + AAC-LC 编码，否则可能静音、禁自动播放，甚至抛NotAllowedError -
type值必须和服务器返回的Content-Type响应头逐字符一致：比如audio/mpeg写成audio/mp3，Safari 就跳过 - 仅写
type="video/mp4"不够安全；推荐写全编码：type="video/mp4; codecs="avc1.42E01E, mp4a.40.2""（H.264 Baseline + AAC-LC） - 本地用
file://协议时，所有type匹配逻辑失效，必须走 HTTP(S) 服务才能触发格式判断 -
<source>的media属性在<video>中基本被所有浏览器忽略，写了也白写
picture 中的 source：media 是核心，sizes 必须写在 img 上
<source> 在 <picture> 中才真正支持 media 和 srcset 协同工作；它的作用是响应式图像选择，不是格式降级。
Html To Pdf
下载
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
-
media属性在这里起效：浏览器按顺序匹配 CSS 媒体查询，命中第一个就停止并加载其srcset或src -
sizes属性**必须写在<img>标签上**，不能放在<source>里；例如：<img src="fallback.jpg" sizes="(max-width: 768px) 100vw, 50vw"> -
srcset中每个 URL 后需带宽度描述符（如320w或2x），否则浏览器无法计算密度匹配 - 所有
<source>都不匹配时，才 fallback 到<img src>—— 所以<img>是兜底，不是备选 -
<source>的type在<picture>中用于格式协商（如type="image/webp"），但优先级低于media匹配结果
常见结构错误与静默失效点
多数“写了 <source> 却不生效”的问题，不是代码语法错，而是三处没对齐：DOM 结构、type 声明、服务端响应头。
立即学习“前端免费学习笔记（深入）”；
-
<source>必须是<video>或<picture>的**直接子元素**；嵌套在<div>里或脱离父标签，会报DOMException: The element has no supported sources，播放器区域直接空白 - 路径错误（404、大小写不符、跨域）不会触发控制台报错，只会静默跳过；建议逐个在新标签页打开
src验证可访问性 - 不要用 JS 动态插入
<source>—— 可能绕过浏览器原生的格式探测逻辑，导致回退链断裂 - 多个
<source>共存时，若首个src返回 404，但没监听error事件，用户看不到任何提示，只看到空控件 - 用
ffprobe vid.mp4确认真实编码，别信文件后缀；用curl -I https://example.com/vid.mp4确认响应头Content-Type: video/mp4
最容易被忽略的是：浏览器判断“能用”，要同时满足三个条件——type 匹配、HTTP 返回 200、视频帧真能解码。Network 面板看到请求成功，不代表就能播；得进 DevTools 的 Media 面板看解码器是否初始化成功。
