单src属性在Safari和旧Android上大概率失败，因浏览器仅按type做MIME匹配而不解析文件内容；必须显式声明合法type（如audio/mpeg、video/webm），且autoplay需同时满足muted与用户手势授权。
为什么单 src 属性在 Safari 和旧 Android 上大概率失败
浏览器不解析文件内容，只按 type 做 MIME 匹配。省略 type 时，Chrome 可能碰巧加载成功，但 Safari（尤其 iOS）会直接跳过该 <source>，导致 canplay 不触发、duration 为 NaN，控制台还静默失败。
常见错误现象：
-
<source src="talk.mp3">→ iOS Safari 拒绝加载，无报错 -
<video src="clip.mp4" controls>→ Android 4.4 内置浏览器黑屏 - 多个
<source>但没写type→ 浏览器逐个发 404 请求，直到超时
<source> 必须带 type，且值要严格匹配标准 MIME 类型
MP3 不是 audio/mp3，而是 audio/mpeg；WebM 视频必须写 video/webm，不能简写为 webm；Ogg 音频是 audio/ogg，不是 audio/ogv。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 音频优先提供
<source src="a.mp3" type="audio/mpeg">+<source src="a.ogg" type="audio/ogg"> - 视频优先提供 MP4（H.264+AAC）+ WebM（VP8/V9+Vorbis/Opus）双源：
<source src="v.mp4" type="video/mp4">+<source src="v.webm" type="video/webm"> - 避免用
preload="auto"：iOS 会忽略，且浪费流量；改用preload="metadata"更稳妥
autoplay 被拦截时的真实生效路径
autoplay 不是“写了就播”，而是“写了 + 满足策略 + 用户无交互时才可能播”。所有现代浏览器都强制要求 muted 存在才能静音自动播放；iOS Safari 还额外要求页面已获得用户手势授权（比如用户点过任意区域），否则即使 muted 也静默失败。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 放弃
autoplay+ 无muted的组合，它在任何主流移动端都不生效 - 要自动播，必须同时写
autoplay muted，且确保编码是 H.264 视频 + AAC 音频（最稳） - 如有声自动播需求，只能等用户首次交互后调用
play()，例如：document.addEventListener('click', () => video.play()) - 调用
play()必须处理 Promise 拒绝：video.play().catch(e => console.warn('play rejected:', e))
iOS 与 Android 在 currentTime 设置和事件触发上的关键差异
iOS WebKit 对生命周期控制极严：未触发 canplay 前设置 currentTime 无效；loadstart 和 loadeddata 触发不稳定；而 Android（尤其低版本 WebView）压根不抛 canplay，但 play 事件相对可靠。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 设置播放位置必须分平台：iOS 等
canplay事件后再设currentTime；Android 可直接设currentTime后立即play() - 监听播放完成别只靠
ended事件：iOS 可能因网络抖动漏发，建议加timeupdate+ 判断currentTime >= duration - 0.1作兜底 - 不要依赖
duration初始化就可用：iOS 下需等loadedmetadata，Android 下有时得等canplay
真正落地的兼容方案，不是堆格式，而是把 <source> 的 type 写对、把 autoplay 的 muted 和手势条件想透、把时间轴操作按平台拆开处理——这些细节一旦漏掉，哪怕格式全齐，照样在真机上卡死或静音失效。
