开头那段先把项目的整体轮廓放在这里。我前后做了好几个基于 HLS 协议的直播和点播项目从最早的 PC Web 端到后来的移动端 H5再到嵌在 App 里的 WebView 播放器换来换去底层始终绕不开 HLS-M3U8 这套方案。很多人一看到 M3U8 就觉得是个“打不开的视频格式”其实它压根不是视频文件而是一个索引文件——真正的视频内容被切成了无数个以秒为单位的小分片M3U8 只是负责告诉播放器“这些分片在哪里、按什么顺序播”。这套机制的三个核心关键词就是视频切片、AES 加密和多码流自适应。这篇文章就围绕这三个点展开结合我实际踩过的坑和调优经验把 HLS 直播和点播从原理到落地一次性讲透。适合刚接触 HLS 的前端开发、后端开发、音视频测试同学也适合那些已经在用 M3U8 但一直没搞清楚内部逻辑的同行。1. 内容整体设计与思路拆解1.1 为什么选 HLS 而不是 RTMP 或 WebRTC做视频方案选型时我一般先问三个问题目标平台是什么是直播还是点播允许的延迟大概是多少HLS 最核心的优势是兼容性。iOS 的 Safari 原生支持 HLSAndroid 的 ExoPlayer 原生支持Web 端几乎所有浏览器都能通过 hls.js 播放。也就是说一套 HLS 视频流可以同时覆盖 iPhone、iPad、Android 手机、PC 浏览器不需要为每个平台各写一套播放逻辑。RTMP 虽然延迟低但浏览器端需要 Flash现在基本没人用了。WebRTC 延迟最低但服务端架构复杂度高对于大多数中小型项目来说没有必要为那几百毫秒的延迟去背这个复杂度。还有一个现实因素CDN 对 HLS 的支持太成熟了。M3U8 是文本文件TS 分片是普通二进制文件这两类文件在 CDN 上做缓存、做分发都非常友好。RTMP 需要长连接CDN 边缘节点要维持状态成本和稳定性都不如 HLS。如果你的业务不是强互动型的低延迟场景HLS 就是性价比最高的选择。1.2 HLS 协议里的几个关键角色HLS 协议从逻辑上拆开其实只有两个核心对象M3U8 索引文件和 TS 分片文件。M3U8 文件按照用途可以再细分点播场景用的是 VOD 类型的播放列表直播场景用的是 live 类型的滑动窗口列表。点播的 M3U8 文件长这样#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:10 #EXT-X-MEDIA-SEQUENCE:0 #EXT-X-PLAYLIST-TYPE:VOD #EXTINF:10.0, segment_00001.ts #EXTINF:10.0, segment_00002.ts #EXTINF:8.5, segment_00003.ts #EXT-X-ENDLIST直播的 M3U8 文件则没有#EXT-X-ENDLIST而且#EXT-X-MEDIA-SEQUENCE会随着时间推移不断增加播放器会定期重新拉取这个 M3U8 文件把新增的分片追加进播放队列。理解这两个区别非常重要。很多人在做视频切片时因为 M3U8 里少了ENDLIST导致播放器一直转圈或者直播流明明在推播放器却停在前几个分片不动这些问题的根源往往就在于没搞清楚点播和直播索引文件的语义差别。1.3 方案选型背后的几个权衡点视频切片粒度、加密方式、码流档位设置这三个点决定了整个 HLS 系统的体验质量。切片粒度我一般推荐 4 到 10 秒。切得越短直播延迟越低但 M3U8 文件越大分片文件数量越多CDN 请求量也越高。切得越长分片数量少但直播延迟会被拉大。实测下来6 秒切片是一个比较均衡的取值兼顾了延迟和 CDN 压力。加密方面HLS 标准里最常用的是 AES-128。它加密的是每个 TS 分片的 payload密钥通过 M3U8 里的#EXT-X-KEY标签告诉播放器去哪里取。加密可以防直接下载但我不建议把它当成绝对的安全屏障更合理的定位是“提高盗链和盗播门槛”。多码流自适应方面至少要准备三档低码率档负责弱网环境下的流畅播放中档负责手机网络高档负责 Wi-Fi 或有线网络。码流设置不是简单把分辨率降下来就行还要同时调整视频编码的 bitrate 和音频的 bitrate否则会出现“画面糊但带宽没省下来”的问题。2. 核心细节解析与实操要点2.1 用 FFmpeg 做视频切片参数到底该怎么给视频切片最常遇到的错误做法是把一个完整的 MP4 直接按秒数硬切这样会导致画面花屏、音画不同步。原因是 MP4 的封装结构把关键帧IDR 帧的间隔和分片边界没有对齐播放器从头解码时找不到可用的参考帧。正确的做法是先确保关键帧间隔和切片长度对齐再生成独立的 TS 分片。这里给一套我实际验证过的命令ffmpeg -i input.mp4 \ -c:v libx264 \ -preset veryfast \ -g 60 \ -sc_threshold 0 \ -c:a aac \ -b:a 128k \ -hls_time 6 \ -hls_list_size 0 \ -hls_segment_filename output_%04d.ts \ -hls_playlist_type vod \ output.m3u8这里面的参数逐个说一下。-g 60表示每 60 帧一个关键帧。假设视频是 30fps那么每 2 秒一个 IDR 帧这与 6 秒的切片时长对齐保证每个 TS 分片都以 IDR 帧开头播放器拿到分片后可以直接解码。-sc_threshold 0是关闭场景切换检测防止 FFmpeg 因为检测到画面剧烈变化而在非预期位置插入关键帧导致分片时长不稳。-hls_time 6指定目标切片时长为 6 秒FFmpeg 会结合关键帧位置做对齐最终每个分片大约在 6 秒左右浮动。-hls_list_size 0表示生成点播类型完整的 M3U8 列表不会只保留最近若干个分片。-hls_playlist_type vod指定播放列表类型为点播会在文件末尾自动加上#EXT-X-ENDLIST。如果做直播切片-hls_list_size要改成固定值比如 6 或 10表示 M3U8 里只保留最近 6 到 10 个分片旧的会从列表里淘汰但文件本身保留在磁盘上方便 CDN 拉取。2.2 TS 分片和 MP4 的本质区别很多人不理解为什么 HLS 使用 TS 而不是直接用 MP4 分片。这是因为 TS 流是面向实时传输设计的它允许播放器从任意位置开始解码并且没有 MP4 中常见的 moov box 依赖问题。MP4 的元数据moov box通常在文件头部或尾部播放器需要先读取 moov 才能获知视频轨和音频轨的位置这对流式播放非常不友好。而 TS 流把视频、音频的包混在同一个传输流里以 188 字节的包为单位解析器可以边下载边解码不需要等待完整的元数据。实操中最重要的一个验证标准是分片后的第一个 TS 文件必须能够独立播放。如果你用 FFmpeg 切完片后直接把第一个分片丢进 VLC 播放能够正常出画面说明关键帧对齐没问题如果黑屏或者花屏就要检查-g和-hls_time的设置。2.3 AES-128 加密M3U8 里的密钥怎么管理和下发HLS 的 AES 加密原理可以这样理解每个 TS 分片的内容被 AES-128-CBC 模式加密密钥是一个 16 字节的随机数。加密后的分片照样存放在原来的位置M3U8 里通过#EXT-X-KEY:METHODAES-128,URIkey.key,IV0x1234567890ABCDEF这个标签告诉播放器解密的钥匙在哪里。这里有一个加密强度上的细节值得强调同一把密钥如果对所有分片生效那么一旦密钥泄漏整个视频内容等于裸奔。所以实践中我通常采用定期更换密钥的策略。比如直播场景下每 24 小时或每 4 小时刷新一次密钥M3U8 文件中会有多个#EXT-X-KEY标签每个标签对应一个时间段的密钥。密钥的下发有两种常见方案。第一种是直接放在静态文件服务下需要加防盗链校验简单但安全性一般。第二种是走后端 API 接口播放器请求 M3U8 时发现URI是一个 API 地址后端校验请求的合法性后返回密钥。第二种方案更可控也能在日志里看到谁拿走了密钥。用 FFmpeg 开启 AES-128 加密的命令如下ffmpeg -i input.mp4 \ -c:v libx264 \ -preset veryfast \ -g 60 \ -c:a aac \ -b:a 128k \ -hls_time 6 \ -hls_key_info_file key_info.txt \ -hls_segment_filename enc_%04d.ts \ encrypted.m3u8key_info.txt的文件内容有三行key.key http://your-api-server.com/keys/key.key 0x00000000000000000000000000000000第一行是本地密钥文件的路径FFmpeg 用来读取密钥内容。第二行是 M3U8 里写入的密钥 URI播放器打开这个地址去获取密钥。第三行是 IV初始化向量可以指定固定值也可以写random让 FFmpeg 每次生成新的 IV。实际操作中要特别注意密钥文件必须是 16 字节。如果你手工生成密钥可以用openssl rand 16 key.key生成不要用文本文件代替否则解密时会报 “invalid key length” 错误。2.4 多码流自适应的 Master Playlist 配置多码流自适应的核心是一个“主索引”文件它本身不指向任何视频分片而是指向多个不同码率的子 M3U8 文件。播放器根据当前网速和 CPU 负载动态选择最适合的码流。一个典型的 Master Playlist 长这样#EXTM3U #EXT-X-STREAM-INF:BANDWIDTH800000,RESOLUTION640x360,NAME360p 360p/index.m3u8 #EXT-X-STREAM-INF:BANDWIDTH1400000,RESOLUTION1280x720,NAME720p 720p/index.m3u8 #EXT-X-STREAM-INF:BANDWIDTH2800000,RESOLUTION1920x1080,NAME1080p 1080p/index.m3u8每个子 M3U8 文件的生成方式与前面单码流切片一致只是编码参数不同。关键是三个子流的BANDWIDTH值不能拍脑袋乱填它直接影响播放器的切换决策。如果 BANDWIDTH 标得过高播放器会高估当前网络带宽加载高码流后频繁卡顿标得过低播放器会一直停留在低清画质浪费带宽。对比一下我在项目中常用的三档码率设置档位分辨率视频bitrate音频bitrate带宽估值低640×360600kbps64kbps800kbps中1280×7201200kbps128kbps1400kbps高1920×10802500kbps128kbps2800kbps生成三档码流后再用一个简单的 FFmpeg 命令把所有子 M3U8 文件整合成 Master Playlist或者直接手写上面的索引内容注意BANDWIDTH必须是实际平均比特率加上冗余值建议在实测平均值上增加约 15% 的余量避免因为带宽波动导致切换延迟。3. 实操过程与核心环节实现3.1 端到端跑通一个点播切片的完整流程前面讲了不少参数和原理这一节我带你把一个完整的点播视频从 MP4 切成带加密、带多码流自适应的 HLS 资源整个过程走一遍。第一步准备测试素材。没有合适的视频时用 FFmpeg 自动生成一个测试视频是最快的ffmpeg -f lavfi -i testsrcduration60:size1280x720:rate30 \ -f lavfi -i sinefrequency440:duration60 \ -c:v libx264 -c:a aac -shortest test.mp4第二步生成三个码率的切片。这里以三档为例你可以先在 720p 下跑通再扩展到其他档位。# 360p 档 ffmpeg -i test.mp4 \ -vf scale640:360 \ -c:v libx264 -preset veryfast -g 60 -b:v 600k -maxrate 600k -bufsize 1200k \ -c:a aac -b:a 64k \ -hls_time 6 -hls_list_size 0 -hls_playlist_type vod \ -hls_segment_filename video/360p/360p_%04d.ts \ video/360p/index.m3u8 # 720p 档 ffmpeg -i test.mp4 \ -vf scale1280:720 \ -c:v libx264 -preset veryfast -g 60 -b:v 1200k -maxrate 1200k -bufsize 2400k \ -c:a aac -b:a 128k \ -hls_time 6 -hls_list_size 0 -hls_playlist_type vod \ -hls_segment_filename video/720p/720p_%04d.ts \ video/720p/index.m3u8第三步给切片加上 AES-128 加密。如果你在切片时没有加密可以直接对已经生成的 M3U8 再做一次加密但更干净的做法是切片和加密一步到位在前面两档的 FFmpeg 命令里追加-hls_key_info_file key_info.txt。第四步在主目录下生成 Master Playlist把三个子 M3U8 统一引用进来。手写即可也可以写一个脚本动态生成。第五步把生成的整个目录部署到 Nginx 或 CDN 上。这里有一个重要配置静态文件服务需要正确返回.m3u8和.ts的 Content-Type。Nginx 默认会按扩展名识别.ts为video/mp2t.m3u8为application/vnd.apple.mpegurl一般不用额外改。但如果你的服务用的是自定义文件服务一定要在 MIME 映射里加上这两项否则播放器可能直接拒绝解析。第六步在浏览器里用 hls.js 播放验证。const video document.getElementById(video); if (Hls.isSupported()) { const hls new Hls({ maxBufferLength: 30, abrEwmaDefaultEstimate: 800000, }); hls.loadSource(/video/master.m3u8); hls.attachMedia(video); hls.on(Hls.Events.MANIFEST_PARSED, () video.play()); }abrEwmaDefaultEstimate这个参数是初始带宽估值单位是比特每秒。我一般设为中等码流对应的带宽这样播放器不会一上来就蹦到最高码率导致首屏加载变慢。3.2 直播场景的切片链路怎么搭直播和点播最大的区别是切片不能等整个视频录完再做而是边推流边切片。完整链路是采集端推 RTMP 流到流媒体服务器服务器转封装成 HLS 分片并不断刷新 M3U8 索引。一个轻量级方案是用 FFmpeg 把 RTMP 流转成 HLS 输出ffmpeg -i rtmp://your-server/live/stream \ -c:v libx264 -preset veryfast -g 60 -b:v 1200k \ -c:a aac -b:a 128k \ -hls_time 4 \ -hls_list_size 10 \ -hls_flags delete_segments \ -hls_segment_filename live/segment_%04d.ts \ live/index.m3u8这里的-hls_list_size 10表示 M3U8 索引只保留最近 10 个分片也就是大约 40 秒的内容窗口。-hls_flags delete_segments表示磁盘上只保留被索引引用的分片旧分片自动删除避免磁盘被无限制占满。直播场景的延迟能压到多低主要取决于两个因素分片时长和播放器加载策略。分片时长越短延迟越低但过短会导致大量小文件请求CDN 和服务器压力增大。我在项目中一般用 4 秒分片实测端到端延迟在 8 到 12 秒之间。如果你需要更低延迟可以尝试 LL-HLSLow-Latency HLS但需要服务器和播放器双端支持复杂度高了不少我这里先不展开。3.3 Vue 项目里播放 M3U8 的小坑和配置建议在 Vue 项目里播放 M3U8常见做法是封装一个视频播放组件。如果你用的是原生 video 标签加 hls.js只需要处理三个生命周期点组件挂载后创建 Hls 实例、仓库地址变更时切换资源、组件销毁时销毁实例。组件销毁时经常有人忘记调用hls.destroy()导致切换路由后视频的声音还在后台播放或者控制台一直报“Media source already attached”之类的错误。正确的清理逻辑是onBeforeUnmount(() { if (hls) { hls.destroy(); } });如果项目本身用了 vue-video-player 之类的封装其实底层还是 hls.js只是在封装层帮我们处理了这些生命周期问题。但封装通用性越好定制能力就越弱特别是你想针对多码流自适应做细粒度控制时还是自己封装一个比较灵活。切换码流时有一个容易踩的坑不能在同一个 video 元素上直接改 source需要先销毁旧的 Hls 实例再用新实例加载新的 M3U8 地址。否则视频元素的内存状态是混乱的表现出的症状就是黑屏或播放进度异常。3.4 为什么有些 AES 加密每次加密结果都不一样很多人问“同样是 AES-128 加密为什么每次加密出来的 TS 文件不一样”答案和 AES-CBC 的加密模式有关。CBC 模式要求每段明文在加密前先和上一个密文块做异或运算第一个块则和初始化向量IV做异或。只要 IV 或密钥发生变化加密结果就完全不同。FFmpeg 在 HLS 加密时默认会为每个分片生成随机 IV除非你在key_info.txt第三行指定了固定 IV。还有一个原因是 TS 分片里带的元数据可能包含时间戳、节目信息等动态内容即使同一份视频源重新切片后 TS 包内容也可能不同。这一点在调试加密问题时要注意不要因为“加密结果不同”就怀疑加密失败只要播放器能在解密后正常播放就说明加密链路是通的。如果是自己写代码实现 AES 解密需要特别注意 IV 的获取方式。HLS 规范里如果 M3U8 中EXT-X-KEY没有指定 IV默认使用分片的媒体序列号作为 IV否则必须使用标签里写的 IV。这里很容易因为实现不一致导致解密失败排查时可以先用 VLC 播放器验证一下分片和密钥是否正确再回来看自己的代码。4. 常见问题与排查技巧实录4.1 m3u8 视频转换失败问题可能出在哪个环节M3U8 转 MP4 是搜索频率特别高的话题这类命令看起来很简单但失败率一点都不低。最常见的错误命令是这样的ffmpeg -i https://xxx.com/live/index.m3u8 -c copy output.mp4直播地址或者带加密的地址直接用-c copy转换几乎必挂。第一个原因直播 M3U8 没有ENDLISTFFmpeg 正常解析完当前列表后会继续等待新的分片直到超时或手动终止导致输出文件不完整。第二个原因加密分片需要提供密钥才能解码-c copy不会执行解密步骤直接报错。正确的做法是先确认地址的类型。点播 VOD 地址可以直接转换但直播地址要么用播放器录制功能要么用 FFmpeg 指定-t限制时长后重新编码。对于加密分片需要先下载密钥文件或者用-hls_key_info_file指定本地密钥信息再转换。单个分片损坏导致转换失败也经常碰到。M3U8 索引里定义了所有分片的顺序当一个分片下载失败或损坏时FFmpeg 默认直接报错退出。要给 FFmpeg 一些容错空间可以加上-xerror的反向参数或者改用-err_detect ignore_err让它跳过错误分片继续拉后面的内容。ffmpeg -i playlist.m3u8 -err_detect ignore_err -c copy output.mp44.2 Vue 播放 M3U8 常见的黑屏和数据加载错误使用 hls.js 播放时最常遇到的错误有两类一类是manifestLoadError代表加载 M3U8 文件本身出了问题另一类是fragLoadError代表分片加载失败。manifestLoadError的排查重点在 URL 是否正确、服务端是否返回了正确的 Content-Type、M3U8 内容本身是否合法。如果你用浏览器直接访问 M3U8 地址看到的内容是纯文本但没有#EXTM3U开头那多半是服务端返回了错误页面而不是真正的索引文件。fragLoadError最常见的诱因是分片 404 或 CORS 跨域被拦截。如果分片地址和 M3U8 地址不在同一个域服务端必须返回Access-Control-Allow-Origin响应头。开发环境下我通常会在 Nginx 配置里统一给.ts和.m3u8加上 CORS 头避免联调时来回折腾。黑屏还有一个隐蔽原因视频元素设置了autoplay且没有muted属性浏览器为了防骚扰会阻止有声自动播放。video 元素的 readyState 一直停在HAVE_METADATA看起来就像卡在加载中。这时不要怀疑解码器先手动调一下video.play()看控制台有没有 NotAllowedError。4.3 多码流自适应不生效播放器一直停在高码率自适应切换依赖播放器对网络带宽的估算。如果你的播放器一直停留在最高码率即使网络已经卡得不行先检查一个参数是否给播放器设置了过大的初始带宽估算值。hls.js 里有几个控制带宽估算的参数。abrEwmaDefaultEstimate决定了初始带宽估值abrEwmaFastVoI和abrEwmaSlowVoI控制估算的灵敏度。为了追求“用户一点播放就能看到清晰画面”我把初始带宽设得过高结果在弱网环境下播放器迟迟不肯降级用户体验更差。正确的做法是把初始带宽设置为中档码流对应的带宽让播放器先加载中档观察实际网络情况后再决定向上切换还是向下切换。另外startLevel参数可以指定初始加载的码流层级设置为-1表示自动选择设置成固定数字则强制从指定档位开始。另一个常见的自适应失效原因是多码流 Master Playlist 里只写了一个EXT-X-STREAM-INF播放器自然无从切换。检查一下 M3U8 是否包含多个子流索引条目以及每个子流索引能否单独访问。4.4 加密流播放报403问题不在播放器而在密钥下发遇到加密流播放报 403 的错误第一反应不要去看播放器的日志先去看网络请求里密钥地址的返回状态。密钥 URI 是 M3U8 的EXT-X-KEY标签里指定的地址如果这个地址做了鉴权但播放器请求时没有携带必要的 Cookie 或 Token服务器返回 403播放器自然无法解密分片。解决思路有两个一是密钥接口放宽鉴权策略只验证固定的 Referer 或签名参数二是让播放器在加载密钥时带上有权限的请求头。如果你自己封装播放器可以在创建 Hls 实例时通过fetchSetup或loader自定义请求行为。我这里补充一个经验密钥地址不要和使用 HLS 的页面放在完全独立的域名下除非你已经处理好了 CORS。跨域请求密钥时如果服务端没有正确的 CORS 头浏览器就算拿到了密钥内容也会因为跨域安全策略把它拦截掉表现为“加密流永远无法播放”。4.5 FFmpeg 转码时内存和 CPU 占用过高怎么控制视频转码是非常吃资源的操作。如果是离线批量切片建议控制并行数不要一次性提交太多 FFmpeg 任务。如果是直播实时转码要在 FFmpeg 命令里加上-threads参数限制单个转码进程的线程数避免和服务器上其他服务抢 CPU。编码器预设也对资源占用影响巨大。-preset veryfast比-preset slow编码速度更快但对应地会增加体积。在直播场景码率控制优先速度是最大制约因素一般用veryfast或faster离线点播切片则可以用slow或medium同一码率下画质更好。内存溢出的情况多数和-vf滤镜链有关。当滤镜链里包含多个缩放、裁剪操作时FFmpeg 会为每个滤镜分配缓冲区分辨率越大内存占用越高。处理 4K 视频时如果条件允许先抽帧检查关键帧位置再决定缩放策略不要一次性挂太多滤镜。5. 项目上线前必须检查的几个细节5.1 密钥和分片的更新策略加密流上线前要制定密钥的轮换策略。我见过不少团队把密钥文件放在与视频同目录的公开路径下访问者只要猜到文件名就能把密钥下载下来整个加密等于没做。正确的做法是把密钥放在独立的只读目录或者由后端接口动态下发并加上访问时效限制。对于分片清理直播场景建议设置磁盘监控脚本当分片目录占用超过阈值时自动删除过了保留窗口的文件。否则某个时刻观看人数暴涨分片生成速度超过清理速度磁盘很快就满了。5.2 从 M3U8 索引解析到播放器加载的完整链路上线前的验收清单一般是这样先用 VLC 直接打开 M3U8 地址能正常播放再用浏览器端 hls.js 能正常播放最后再用手机 Safari 和 Android 自带浏览器播放一遍。这三层都通过说明服务端切片、加密、分发基本没有问题。如果手机端播放不了优先检查是否缺少#EXT-X-INDEPENDENT-SEGMENTS标签这个标签告诉播放器所有分片都是独立可解码的对某些 Android 播放器来说缺少这个标签会直接影响多码流切换。5.3 直播场景的分片保留窗口要留多少分片保留窗口直接影响两个东西回看功能和播放并发。如果你的产品既有直播又有回看建议把分片保留时间长一些比如 6 小时并单独生成一个持久化的回看 M3U8。如果纯直播不提供回看保留 1 到 2 小时足够超过保留时间的旧分片可以直接清理。这个窗口还决定了 CDN 的回源命中率。CDN 边缘节点拉取分片后会按照缓存规则保留一段时间。如果分片保留窗口太短用户刚好错过某个分片的播放时机回源时源站已经没有这个文件了就会报 404导致直播播放中断。5.4 监控告警要盯哪些指标HLS 上线的第一天我建议至少盯住四个指标M3U8 请求成功率、TS 分片 404 率、密钥接口响应时间、各码流档位的播放占比。前两个指标直接反映分发链路是否健康第三个指标反映鉴权链路是否够快第四个指标能告诉你自适应调度是偏向高清还是偏向流畅。我曾经遇到过一个诡异的线上问题用户普遍反馈直播卡顿但服务器 CPU 和带宽都很宽裕。后来查了日志才发现大量用户被 CDN 调度到了同一个边缘节点该节点的回源带宽打满导致分片加载超时。这种情况靠加服务器没有用需要优化 CDN 的调度策略或者增加回源带宽。6. 结尾想聊的几点个人经验这篇文章从 HLS 和 M3U8 的基础结构讲到 FFmpeg 切片、AES 加密、多码流自适应再到 Vue 播放和常见问题排查算是把我这几年做 HLS 项目踩过的坑都整理了一遍。最后分享一个我自己的排查习惯遇到任何播放异常先用 VLC 试一遍再用浏览器的开发者工具看一遍网络请求最后才去翻代码。因为 VLC 能排除播放器兼容性问题网络请求能直接看到 M3U8、TS、密钥的返回状态这两步做完绝大多数问题都已经能定位到具体环节了。做 HLS 项目最忌讳的就是一上来就埋头写代码先花半小时把 M3U8 索引文件的内容从上到下读一遍比什么都管用。索引文件本身就是协议的最好说明读懂了它你也就真正理解了 HLS。
