HTML音频流媒体多端兼容需“格式兜底+协议适配+用户手势绑定”：HLS需hls.js（Chrome/Firefox）或原生（iOS Safari，须MIME正确且无DRM）；MP3流须设audio/mpeg MIME、禁preload；所有播放必须绑定用户手势，且按平台差异处理中断重连。
HTML 音频流媒体（如 HLS、MP3 连续流、Icecast）在多端兼容上，**不能直接用 src 指向 .m3u8 或 /stream 路径就指望它播起来**——绝大多数浏览器（包括 Safari iOS、Chrome Android、Firefox Desktop）原生不支持 HLS 流；而裸 TCP 流或未分片的 MP3 流，在移动端极易卡死或静音。真正能落地的方案，是「格式兜底 + 协议适配 + 用户手势绑定」三者缺一不可。
为什么 <audio src="live.m3u8"> 在 iOS 上根本不动
Safari（含 iOS）是唯一原生支持 HLS 的主流浏览器，但仅限于 .m3u8 且必须满足：服务器返回 Content-Type: application/vnd.apple.mpegurl，且流本身是 H.264+AAC 封装（即使只有音频，也得带 dummy video track 或用 audio-only HLS profile）。其他所有浏览器（Chrome、Firefox、Edge）对 .m3u8 直接忽略，canPlayType('application/vnd.apple.mpegurl') 返回空字符串，连错误都不抛。
- Chrome / Firefox / Android WebView：必须用 JavaScript 解析 HLS —— 推荐
hls.js（v1.3+ 支持 MSE，不依赖 Flash） - iOS Safari：可直用
<audio>播.m3u8，但需确保服务器 MIME 正确，且流里无 DRM、无 EXT-X-KEY 加密（否则静默失败） - 别把
hls.js和原生播放混用：检测video.canPlayType('application/vnd.apple.mpegurl')为"probably"才走原生，否则才加载hls.js
hls.js 播放流时，移动端点击没反应怎么办
不是代码写错了，是 hls.js 创建的 MediaSource 实例，其底层 HTMLMediaElement 仍受浏览器自动播放策略约束——哪怕你用 audio.play()，只要没用户手势上下文，Promise 一样被 reject。
- 必须把
hls.loadSource()和audio.play()都包在用户事件回调里，例如：button.addEventListener('click', () => { hls.loadSource(url); hls.attachMedia(audio); audio.play().catch(e => {}); }) - iOS Safari 中，
audio元素必须在视口内、未被display: none或opacity: 0遮挡，否则即使点过也触发不了 play - 不要在
hls.on(Hls.Events.MANIFEST_PARSED, ...)里直接play()—— 此时还没获用户授权，必失败 - Android WebView（尤其旧版）可能不支持 MSE，
Hls.isSupported()必须提前检查，不支持则 fallback 到 MP3 连续流（见下一条）
MP3 连续流（/stream.mp3）怎么让 Chrome 和 Firefox 都能播
MP3 连续流本质是 HTTP chunked response，浏览器会边收边解码。但它有硬伤：Chrome 会等收到足够帧头才开始播（约 2–3s 延迟），Firefox 更激进，若首帧不完整或 Content-Type 错误，直接卡住不报错。
立即学习“前端免费学习笔记（深入）”；
- 服务器响应头必须设
Content-Type: audio/mpeg，不能是text/plain或空；同时加Cache-Control: no-cache和Transfer-Encoding: chunked - 前端用
<audio>标签，但src不能指向静态文件路径，而是后端代理接口（如/api/stream），避免跨域和 CORS 阻断 - 别用
preload="auto"—— 它会让浏览器尝试预读整个流，导致阻塞；应设preload="none"，靠用户点击再触发play() - 容错处理：监听
audio.error，若code === 4（MEDIA_ERR_SRC_NOT_SUPPORTED），说明流格式或 MIME 不被接受，可提示降级为下载链接
如何统一处理 iOS、Android、桌面端的流中断与重连
流媒体最脆弱的不是首次播放，而是网络抖动后的恢复——iOS Safari 一旦网络断开，ended 事件不触发，networkState 可能卡在 NETWORK_LOADING，而 hls.js 的 ERROR 事件又分 networkError 和 fatalError，处理逻辑完全不同。
- 对原生 HLS（iOS）：监听
audio.onstalled和audio.onabort，配合定时检查audio.networkState是否长期为NETWORK_NO_SOURCE - 对
hls.js：必须区分错误类型：if (data.fatal) { hls.destroy(); hls = new Hls(); ... }；非 fatal 可调hls.recoverStreamFailure() - 所有平台都应设置超时兜底：用
setTimeout监控audio.readyState < 2超过 10s，则视为流失效，触发重试或提示 - 别依赖
timeupdate判断是否在播——流中断时它可能还在触发；可靠方式是结合audio.paused === false+audio.ended === false+audio.currentTime > 0
真正麻烦的不是“怎么播”，而是“播断了怎么悄无声息地续上”。每个平台对流状态的定义不一致，iOS 把断开当 error，Android 当 stalled，桌面 Chrome 又可能直接静音卡住——所以容错逻辑必须按平台拆开写，不能共用一套 if (err.code === 4)。
