直播流不能直接用标签加src播放，需匹配协议（如safari原生支持m3u8、chrome需hls.js）、浏览器能力与加载时机；rtmp/flv等协议须借助flv.js或mediasource，且play()必须在用户交互后、媒体就绪事件触发时调用。
直接用 <video></video> 标签播放直播流，不是“加个 src 就行”，而是必须匹配协议、浏览器能力与加载时机。Safari 能原生播 .m3u8，Chrome 不行；rtmp:// 地址在任何现代浏览器里都必然失败——这不是代码写错了，是协议根本不被支持。
怎么判断你的直播 URL 能不能直接塞进 <video></video>
看协议前缀和后缀：
-
https://xxx.com/live/index.m3u8→ 可能行（但需 Safari / iOS 或配hls.js） -
http://xxx.com/play/123.flv→ 不行（原生不支持 FLV，得用flv.js） -
rtmp://xxx.com/live/stream→ 绝对不行（浏览器已弃用 Flash，无原生 RTMP 支持） -
http://xxx.com/stream/segment-001.fmp4→ 可行（需手动用MediaSource接入）
URL 中 ? 后的参数（如 ?token=xxx&User-agent=xxx）不影响协议判断，但必须原样保留；若服务端校验 User-Agent 或要求 HTTPS，而你用 HTTP 加载，会 403 或 CORS 失败。
Chrome / Firefox 播 .m3u8 必须用 hls.js，且不能乱调 play()
hls.js 不是“让 <video></video> 支持 m3u8”，而是把 HLS 解析成 MSE 可接受的分片流。常见错误是：loadSource() 后立刻 play()，结果静默失败或报 DOMException: play() failed because the user didn't interact with the document first。
- 必须等
Hls.Events.MANIFEST_PARSED事件触发后再调video.play()，此时MediaSource已 ready - 不要给
<video></video>设src属性，hls.attachMedia(video)才是绑定方式 - Safari 19+ 原生支持 HLS，
Hls.isSupported()返回false，此时应退回到直接设video.src = 'xxx.m3u8'并调play() -
muted属性仍要加，否则部分安卓 WebView 会拦截自动播放
低延迟场景别硬啃 HLS，试试 flv.js 或 MediaSource + WebSocket
HLS 默认延迟 10–30 秒，真要 sub-3s 延迟，得换路径：
-
flv.js：适合服务端能输出 HTTP-FLV 或 WebSocket-FLV 的场景，Chrome/Firefox/Safari 10+ 全兼容，初始化快，延迟常压在 1–2 秒 -
MediaSource + WebSocket：后端推fMP4分片（非完整 MP4），前端用sourceBuffer.appendBuffer()持续写入；优势是完全可控，劣势是时间戳对齐、随机 Seek、buffer eviction 都得自己处理 - 别碰 RTSP：浏览器无原生支持，所有“RTSP 播放”方案本质都是服务端转封装（如 RTSP → WebRTC 或 RTSP → FLV），前端只是消费结果
video.play() 失败？先查三件事
不是 JS 写错了，是媒体状态没到位：
-
video.readyState是 0（HAVE_NOTHING）？说明还没加载任何数据，play()必挂 - 是否在用户交互（click/touch）后才调用？移动端尤其严格，无交互 + 有音频 = 直接拒播
- 是否用了
hls.js却忘了监听MANIFEST_PARSED？此时video.src还是空，play()对着空气喊
最稳的写法永远是：等库明确告诉你“可以播了”，再播；而不是靠 setTimeout 或轮询 readyState。延迟容忍度低的项目，更要盯紧服务端输出格式和浏览器 MSE 兼容性边界——比如某些旧版 Edge 对 video/mp4; codecs="avc1.64001f" 解码失败，换 avc1.42E01E 就通了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
