hls适合求稳求广的场景，dash适合需灵活多格式支持的点播平台，webrtc适合超低延迟互动直播；三者选择取决于实际需求而非先进性。
HTML5 页面里想播流，HLS、DASH 和 WebRTC 是当前最主流的三种选择。选哪个不取决于“谁更先进”，而要看你实际要解决什么问题：是做低延迟互动直播？还是面向大众的点播回放？或是需要强兼容又不怕稍慢一点？
选 HLS：求稳、求广、求省心
HLS 是目前 HTML5 环境下落地最成熟、兼容性最好的方案。iOS 全系原生支持，Android 5.0+、Chrome、Edge、Safari 都能直接播放 .m3u8 地址，连 CDN 分发和 HTTPS 加密都天然适配。
- 适合场景：新闻直播、赛事集锦、教育录播、企业内训视频等对延迟不敏感（可接受 10–30 秒）但要求“打开即播”的业务
- 关键配置注意点：用 -hls_time 2 把切片设为 2 秒，-hls_list_size 3 控制列表长度，能将端到端延迟压到 6–10 秒左右（即所谓 LL-HLS）
- 安全方面：支持 AES-128 加密，配合 token 鉴权 URL 可满足基础内容保护需求
选 DASH：要灵活、要标准、要多格式支持
DASH 是 MPEG 制定的国际标准，设计上比 HLS 更开放。它不绑定容器或编码格式，MP4、WebM、AV1、VP9 都能塞进去，也更容易实现多语言字幕、多音轨切换等高级功能。
- 适合场景：大型点播平台（如网课平台、影视 APP）、需要统一协议管理多终端的中后台系统
- 实际限制：浏览器原生支持不如 HLS 广泛——Chrome 和 Edge 没问题，Firefox 支持有限，Safari 直播场景基本不认 DASH（需 JS 解析，比如 dash.js）
- 部署要点：必须搭配 MPD（Media Presentation Description）清单文件，且服务端要正确设置 CORS 和 MIME 类型（如 application/dash+xml）
选 WebRTC：只在真需要“说话就听见”的时候用
WebRTC 不是传统意义的“流媒体协议”，它是为实时双向通信设计的。在单向直播中，它能把端到端延迟压到 500ms 以内，真正实现“主播说话、观众秒听”。但代价是架构复杂、带宽消耗高、CDN 支持弱。
- 适合场景：在线问诊、远程面试、互动课堂、超低延时监控预览
- 不能绕开的依赖：必须有信令服务器（WebSocket）、STUN/TURN 服务器（应对 NAT 穿透），纯静态 HTML 页面跑不起来
- 播放方式：HTML5 原生 标签即可，但要用 JavaScript 调用 RTCPeerConnection，无法像 HLS 那样直接填 src
没有万能解法。HLS 是“能跑通”的底线，DASH 是“想做好”的进阶，WebRTC 是“必须快”的特例。根据你的用户设备分布、延迟容忍度、运维能力来定，比纠结协议名字实在得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
