type属性必须与服务端Content-Type逐字符一致，差一个空格、大小写或分号位置都会导致Safari跳过该source；首个source需为H.264 Baseline+ AAC-LC的MP4并精确声明codecs；本地file://协议下type失效，须用HTTP服务测试。
type属性必须和服务端Content-Type逐字符一致
浏览器在解析 <source> 时，会把 type 属性值和服务器返回的 Content-Type 响应头做严格字符串比对——差一个空格、大小写或分号位置，Safari 就直接跳过该源，Network 面板里根本看不到请求发出。
常见翻车点：
-
type="audio/mp3"→ 错误，标准 MIME 是audio/mpeg，哪怕文件后缀是 .mp3 -
type="video/mp4"→ 不够，缺少codecs参数时，iOS Safari 可能静默丢弃（尤其自动播放场景） -
type="video/webm; codecs="vp9, opus""→ 注意引号内逗号后有空格，少空格会导致匹配失败 - 用
curl -I https://example.com/vid.mp4确认真实响应头，别信本地文件名或开发服务器默认配置
iOS Safari 要求首个必须是 H.264 Baseline + AAC-LC
WebKit 内核不 fallback：只要第一个 <source> 的 type 和实际编码不满足 Baseline Profile + AAC-LC，整个 <video> 就被判定为不可用，后续所有 <source> 都不会加载，也不报错。
实操要点：
立即学习“前端免费学习笔记（深入）”；
- 首个
<source>必须是 MP4，且type写成video/mp4; codecs="avc1.42E01E, mp4a.40.2"（注意 avc1 后面的点、空格、逗号、引号位置） - 导出时用 FFmpeg 加参数：
-profile:v baseline -level 3.0 -c:a aac -b:a 128k，避免 High/Main Profile - 用
ffprobe video.mp4检查输出中的profile和codec_name，别信后缀或软件界面显示 - 把 WebM 或 AV1 放后面，不是为了“降级”，而是因为 iOS 根本不看它们——顺序错了等于没写
canPlayType() 比硬写更可靠
浏览器对 type 的匹配是静态的，但实际能否解码还得看硬件支持。比如写了 type="video/mp4; codecs="av01.0.05M.08""，Chrome 能播，Safari 16+ 才识别，旧版直接忽略——而 canPlayType() 能提前探测。
建议这样用：
- 先调用
video.canPlayType('video/mp4; codecs="avc1.42E01E"')，返回"probably"才插入对应<source> - 不要只依赖
canPlayType('video/mp4')，它可能返回"maybe"，但实际解码失败 - 对 WebM 做探测时，用
canPlayType('video/webm; codecs="vp9"')比只写video/webm更准 - 动态插入
<source>后需手动触发video.load()，否则浏览器不重新探测
本地开发用 file:// 协议时 type 匹配完全失效
所有现代浏览器在 file:// 协议下都会忽略 type 属性，只按文件后缀猜测格式。这意味着你写对了 type="audio/mpeg"，但在本地双击 HTML 文件打开时，它可能根本不起作用。
必须这样做：
- 本地测试务必起一个 HTTP 服务，比如 Python 的
python3 -m http.server或 VS Code Live Server 插件 - 检查 Network 面板里每个
<source>的请求是否发出，而不是只看元素是否存在 - 路径大小写敏感（尤其 Linux/macOS 服务器），
src="Audio/track.mp3"和src="audio/track.mp3"是两个不同资源 - 跨域资源要确保服务端带
Access-Control-Allow-Origin，否则静默失败，控制台可能只报 CORS 错误，不提type
type 值和服务端响应头之间那一个空格、一个大小写、或者 FFmpeg 导出时漏掉的 -profile:v baseline 参数。这些地方不验证，光靠重排 <source> 顺序解决不了问题。 
