M3U8 是什么？HLS 流媒体协议与 .m3u8 播放列表完整指南

M3U8 是 HLS（HTTP Live Streaming）协议使用的 UTF-8 文本播放列表，本身不含视频画面，而是一份列出视频分片（.ts 或 .m4s）URL、时长与码率档位的清单。播放器读取 .m3u8 后按序拉取分片并实时拼接成可播放视频流——这是 YouTube、Netflix、Twitch、Apple TV+ 等大多数主流流媒体在 2026 年底层使用的核心机制。

你有没有试过从某个流媒体网站保存视频，结果得到的不是一个整洁的 .mp4，而是几百个小小的 .ts 文件？或者打开浏览器的 Network 面板，本想看到一个干净的下载 URL，却看到源源不断涌进来的两秒一片的小块？你并没有做错什么。你正在看的是 HLS——承载现代 Web 上大多数流媒体视频的协议——而 HLS 不会把视频以单一文件形式发出。它发出的是”配方加零件”。

配方是一份名为 .m3u8 的小型文本播放列表。零件是一段段短小、可独立解码的视频分片，播放器在播放过程中即时把它们拼接起来。HLS 由 Apple 于 2009 年为初代 iPhone 创立，并以 RFC 8216 标准化，如今几乎所有主流浏览器、移动端和电视设备都原生支持。

本指南将走完 .m3u8 究竟包含什么、流媒体服务为什么选择这种设计、.ts 与 fMP4 分片如何配合、2026 年哪些平台使用 HLS，以及当你试图把这种码流保存到硬盘时会发生什么。

核心要点 {#key-takeaways}

• HLS 是流媒体协议，而非文件格式。 它通过普通 HTTP 把视频以播放列表（.m3u8）加短分片（.ts 或分片 MP4）的形式交付。
• .m3u8 是索引，不是视频。 仅保存 .m3u8 文件得到的是”没有食材的菜谱”。
• Apple 于 2009 年为 iPhone 创立了 HLS，并在 2017 年将其标准化为 RFC 8216。如今 iOS/Safari 上是强制的，其他平台也几乎普遍支持。
• 分片为 2–10 秒 的视频——足够短，可以在它们之间切换画质；足够长，让 HTTP 开销保持合理。
• 主播放列表列出档位，媒体播放列表列出分片。 播放器先读主播放列表，选定档位，再加载该档位的媒体播放列表。
• .ts 分片正被分片 MP4 （CMAF）取代，使同一组文件可以同时服务 HLS 和 DASH 播放器。
• 现代流媒体大多基于 HLS 或 DASH，常常两者并存——包括 YouTube、Netflix、Disney+、Twitch、Apple TV+ 与 Cloudflare Stream。

M3U8 vs MP4：核心差异对比

很多人第一次接触 .m3u8 是因为下载视频时拿到的不是熟悉的 .mp4 而是一份小文本。两者经常一起出现，但根本不是同一类东西——一个是清单（playlist），另一个是容器（container）。下面这张表把日常使用中最常被搜索的差异一次说清。

一句话总结：M3U8 是”目录”，MP4 是”成品文件”。 在线观看时浏览器拿到的是 M3U8 清单，按需拉取分片；想离线长期保存或分享给朋友，最终通常还是要把分片合并回 MP4。

简明解释

先把协议搁一边。设想一位导演要把一部完成片通过不可靠的互联网发给全球观众。一次性发一个巨大 MP4 行不通：观众的连接下载到一半中断，就得从零开始，而且想换画质就要全部重新下载。于是导演把电影切成数百段 6 秒的片段，并写一份编号的播放列表，说”先播 001、再播 002、再播 003……”。观众的播放器下载播放列表、拉取最初几段并开始播放，剩下的在后台陆续到达。连接变慢时，播放器在不丢帧的情况下切到下一段的较低画质版本。

一句话说清 HLS：把电影切成短片段，再加一份 .m3u8 播放列表，告诉播放器接下来播哪段。

从观众视角看，这种设计藏了大量魔法。跳转瞬时完成——播放器可以直接跳到覆盖目标时间戳的那一分片，而不是从头串到尾。画质切换平滑——播放器可以在下一片选用不同档位而不必重启播放。缓冲温和——播放器只需领先几分片，通常 10 到 30 秒，而无需预先下载大块文件。直播之所以可行——是因为广播方产出新分片时可以追加到播放列表里，播放器每隔几秒轮询 .m3u8 以发现新条目。

如果你曾纳闷为何 Wi-Fi 抖动时 YouTube 或 Netflix 的码流能平滑过渡，而某个随机网站直接给的 MP4 下载却卡死了，原因就在这里。整套设计基于一个前提：互联网是混乱的、连接来来去去。深入讨论播放器如何实时调整画质有专门的文章；此处只需留意，正是”分片 + 播放列表”的设计让这种自适应得以成立。

HLS 究竟如何运作

一段 HLS 流由两层播放列表加上一堆分片构成，全部通过普通 HTTP 提供。 没有特殊东西，也没有自定义协议——你的浏览器本来就会做每一步。

主播放列表

播放器最先拉取的是主播放列表。这是一份扩展名为 .m3u8 的小型文本文件，列出码流的每个可用档位——通常是不同画质——以及各自的带宽和分辨率。下面是经过轻微修剪的真实示例：

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2"
1080p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720,CODECS="avc1.4d401f,mp4a.40.2"
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=854x480,CODECS="avc1.4d401e,mp4a.40.2"
480p/index.m3u8

#EXTM3U 一行表明这是一份扩展 M3U 播放列表。#EXT-X-VERSION:6 声明使用的 HLS 协议版本。每个 #EXT-X-STREAM-INF 块描述一个档位：码率、分辨率和编解码器字符串，后接一个 URL，指向该档位的第二份播放列表。播放器读取这份文件、估算你的带宽，挑出它认为你能撑住的档位。

媒体播放列表

档位选定后，播放器拉取该档位的媒体播放列表。真正的分片 URL 就在这里：

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:6.000,
segment000.ts
#EXTINF:6.000,
segment001.ts
#EXTINF:6.000,
segment002.ts
#EXT-X-ENDLIST

#EXT-X-TARGETDURATION:6 表示任何分片都不超过 6 秒。每个 #EXTINF:6.000, 声明一段分片的精确时长，紧跟其后的是分片 URL。#EXT-X-ENDLIST 告诉播放器这是点播流——不会再追加分片。直播流省略 #EXT-X-ENDLIST，播放器每隔几秒重新请求该播放列表以发现新分片。

分片：.ts 与 fMP4

分片是短小的音视频块——通常 2 到 10 秒——并在关键帧边界切开，使播放器可以从任意分片的起点开始解码。当播放列表声明 #EXT-X-INDEPENDENT-SEGMENTS 时，每个分片都保证可独立播放；没有这个标志时，后续分片可能依赖前面分片中的数据。历史上分片是 MPEG-2 Transport Stream 文件，扩展名 .ts——与卫星和有线电视所用的容器格式相同。MPEG-TS 为嘈杂的广播信道而生，对局部损坏鲁棒，任何能解码 .ts 包的播放器都能播放 HLS 分片。

典型分片时长是 2 到 10 秒。更短的分片意味着更低的延迟和更敏捷的码率切换，但每分钟视频要更多 HTTP 请求与更多开销。更长的分片压缩效率更高、请求更少，但对带宽变化反应更慢。Apple 最初规范推荐 10 秒分片；现代服务通常落在 2 到 6 秒区间。

自 2016 年起，行业一直在从 .ts 迁移到分片 MP4——具体说是 Common Media Application Format (CMAF)，作为 ISO/IEC 23000-19 标准化。CMAF 分片使用与 MPEG-DASH 相同的 MP4 分片方式，这意味着 CDN 上的同一组文件可以同时服务 HLS 和 DASH 播放器。这是流媒体服务的一笔重大成本节约：一次编码、一组字节、两套协议。来自 YouTube、Netflix 和 Apple 的现代 HLS 码流几乎全是 CMAF，而非旧式 MPEG-TS。

全程 HTTP

“HTTP Live Streaming”里的”HTTP”才是真正的妙处。线上没有任何特殊协议——HLS 的每个部分都通过你的浏览器为 HTML 和 JPEG 所用的同一种 HTTPS 请求传输。CDN 钟爱这一点，因为它们本就为 HTTP 做了优化。防火墙允许它通过，因为看上去毫无异常。CDN 可以把热门分片缓存到边缘。范围请求、gzip、HTTP/2、HTTP/3、TLS——一切免费可用。

这也是 HLS 之所以胜出的原因。早期流媒体协议如 RTMP、RTSP、MMS 需要专用端口、有状态服务器和特殊防火墙规则。HLS 看起来就像一个发布大量小文件的网站。

多数用户无需手动处理这些——VidMost 会在后台解析 .m3u8 清单并把分片合并成干净的 MP4。

现实世界里你会在哪里遇到 HLS

2026 年几乎所有主流流媒体服务都使用 HLS，往往与 DASH 并存。 Apple 在 2009 年发明 HLS，正是为了把视频传给初代 iPhone——这部设备在蜂窝网络上无法很好地处理渐进式下载，而 Apple 想要一种在运营商眼中看起来就像 HTTP 流量的流媒体格式。此后这一协议成了互联网上很大一块版图的默认。

• Apple 自家的服务 是 HLS 独占的。Apple TV+、iTunes Store、Apple Podcasts 上的播客，以及任何在 Safari、iOS 或 tvOS 上播放的视频，都基于 HLS。Apple 平台不内建 MPEG-DASH 解码器，任何想在 iPhone 上播放的服务都必须提供 HLS。
• YouTube 在 Web 和 Android 上以 MPEG-DASH 为主协议，但在 iOS、Safari、AirPlay 和大多数 TV 应用上提供 HLS。在 Safari 上的 YouTube 打开开发者工具，你会看到 .m3u8 请求；在 Android 上的 Chrome 则会看到 DASH 的 .mpd 请求。
• Netflix、Disney+、Hulu、Max、Amazon Prime Video 都是混用。它们的智能电视和主机应用经常用 HLS 搭配 FairPlay 或 PlayReady DRM；Web 播放器则常切到 DASH 加 Widevine。同样的内容，不同客户端不同协议。
• Twitch 自 2014 年放弃旧 RTMP 播放栈起，就跑在 HLS 上。Twitch 上每条直播和每段点播底层都是 HLS。
• 直播间与创作者平台 —— Bigo Live、Chaturbate、OnlyFans 直播、Fansly 直播——浏览器播放几乎清一色使用 HLS，因为它无需插件，并且对网络抖动宽容。
• 托管视频服务商 如 Vimeo、Mux、JW Player、Cloudflare Stream 默认提供 HLS。如果某网站嵌入了 Vimeo 或 Mux 的 iframe，下面的视频几乎肯定是 HLS。
• 体育和新闻广播商 —— ESPN、BBC iPlayer、DAZN、Sling TV——都依赖 HLS 进行直播分发，通常在其之上再叠一层 DRM。

HLS 之所以能跳出 iOS 起源，是因为它解决的不只是 Apple 的问题，而是所有人的实际问题。等 2012 年 DASH 出现时，HLS 已经在野外有了广泛的 CDN 支持、可用的播放器和势头。如今两种协议并存；一家深思熟虑的流媒体服务两者都支持，许多服务直接在同一套 CMAF 分片之上发布两种清单格式。关于DASH 与 HLS 的详细对比，兄弟篇有完整的端到端讨论。

想把视频保存下来意味着什么

理解 HLS 的运作后，一个实际问题就变得显而易见：你没法靠”右键 → 另存为”把一段 HLS 视频下载下来。 原因有几条是机械层面的、几条是微妙的，还有一两条会让你惊讶。

• 浏览器的”另存为”只会保存 .m3u8。 页面在开始播放时下载的就是这份 .m3u8——一个小型文本文件。保存它你只得到菜谱，得不到食物。在 VLC 里打开有时管用（VLC 会跟随里面的 URL），但这只在原始会话仍然有效、URL 尚未过期时成立。
• 每个分片都是一次独立 HTTP 请求。 30 分钟视频按 6 秒一片计算，就是 300 次独立下载。你要枚举播放列表、拉取每个分片，并按正确顺序串接，才能得到一个可作为单文件播放的成品。
• 档位选择是个真问题。 主播放列表列出多种画质。选错就得到一部本来流着 1080p 的电影的 480p 副本。通常正确的选择是你的存储与耐心能承受的最高带宽档位。
• HTTPS 保护的是传输中的字节，而非磁盘上的字节。 分片 URL 几乎总是通过 HTTPS 提供，因此网络上的窃听者读不到你在流的内容。但分片一旦到达你的浏览器，它就是明文视频——TLS 对一个已经能访问到响应的工具毫无阻碍。
• HLS 支持 AES-128 分片加密作为内容层。 当 .m3u8 携带 #EXT-X-KEY 标签时，每个分片以 AES-128 加密，播放列表指向一个密钥 URL，播放器通过 HTTPS 拉取该密钥。把分片下下来却没有密钥，你得到的是一堆密文。这是内容加密，与传输安全相互独立，本身不带任何权益校验——密钥 URL 本身就是入口。
• 商业 DRM 是另一回事。 Netflix、Disney+ 和 Apple TV+ 这类高级服务在 HLS 之上叠加 FairPlay（Apple）、Widevine（Google）或 PlayReady（Microsoft）。线上加密仍是 AES 基础，但密钥仅在播放器在可信设备上证明权益之后才由许可证服务器签发，且解密在硬件支持的安全模块内完成，画面永不经过应用程序内存。完整图景参阅什么是 DRM 受保护内容？。
• 令牌与签名 URL 会过期。 许多 .m3u8 与分片 URL 都使用短期签名令牌，几分钟内就会失效。等你手工把下载流程写完，半数链接可能已经死了。

这正是 VidMost 接手的地方。VidMost 用于在合规前提下保存你有合法权利访问的 HLS 内容——你自己直播的回放、付费课程的离线副本、自由授权或公有领域的视频、未启用商业 DRM 的企业培训素材，以及付费订阅服务条款明确允许下载的内容。它解析 .m3u8 清单，挑出可用的最高画质档位，从你浏览器本就在对话的同一家 CDN 并发下载每个分片，自动处理普通的 AES-128 分片加密，最终重新封装为一个干净的 MP4 文件。对于受 FairPlay、Widevine、PlayReady 等商业 DRM 保护的码流（Netflix、Disney+、Apple TV+ 等高级服务），请遵守对应平台的服务条款与所在地法律。对用户而言，整个体验是”粘贴一个合规的 URL，得到一个 MP4”——协议层消失了。

常见误区与误解

关于 HLS 有几个反复出现在论坛话题里的误解。值得澄清。

• “.m3u8 不是视频文件。” 它是索引。真正的视频在播放列表所引用的分片里。如果有工具声称”下载 m3u8”，先问它是否还会拉取并合并分片——否则你只得到一份没用的文本文件。
• “.ts 文件在多数播放器里不会直接播放。” 单个分片或许能在 VLC 里播几秒，但整段视频不是文件夹里一串 .ts——而是必须按序解码、彼此串接的序列。不讲 HLS 的播放器最多播完第一片就停。
• “HLS 不一定意味着直播。” “HTTP Live Streaming”在 2026 年是个误导名字。HLS 同样适用于点播：相同的播放列表、相同的分片，只是用 #EXT-X-ENDLIST 标识一段有限的码流。Netflix、Disney+ 和 Apple TV+ 的绝大多数目录内容都是点播 HLS，而非直播。
• “码率越高画质越好——除非你的连接掉线。” 10 Mbps 的档位在光纤上看起来不错，在 3 Mbps 的移动链路上则一塌糊涂。自适应设计的全部要点就在于让播放器选择连接能承受的档位——手动覆盖往往让体验更差而非更好。
• “浏览器下载工具在 HLS 上通常会失败。” 通用的”视频下载器”扩展寻找指向 MP4 文件的 <video src="..."> 标签。HLS 流不会暴露这种 URL；播放器通过 Media Source Extensions 以编程方式把分片喂给 video 元素。正因如此，才会有专门解析清单的工具存在。

结语

HLS 是你所看视频背后的沉默基础设施。它能成立，是因为放弃了在传输层耍小聪明——没有自定义协议、没有特殊服务器，只有 .m3u8 文本文件和 .ts 或 fMP4 分片，通过你浏览器本就会说的同一种 HTTP 拉取。Apple 在 2009 年解决了一个手机问题，不经意间造就了之后二十年的主导流媒体格式。

一旦你能在浏览器网络面板中识别出 .m3u8 请求并读懂播放列表，大量流媒体行为——短暂的画质切换、瞬时跳转、“提前缓冲”指示，以及那个莫名出现的装满 .ts 文件的文件夹——就不再神秘。全都是同一个循环：取播放列表、选档位、取分片、解码、重复。

如果你宁愿完全跳过协议层，直接保存视频，VidMost 可以处理 HLS、DASH、fMP4 以及受 DRM 保护的码流。

相关阅读

• 在线视频究竟是怎么播放的 —— 从摄像头到屏幕的完整流水线。
• MPEG-DASH 与 HLS 对比 —— 每种协议各自胜出的场景，以及为何多数流媒体服务两者都发布。
• 画质为何会在播放中变化 —— 每个 HLS 和 DASH 播放器内部的 ABR 逻辑。
• 视频容器与编解码器 —— .mp4、.ts 或 .m4s 里真正装了什么。
• 什么是 DRM 受保护内容？ —— Widevine、FairPlay 与 PlayReady 如何为那些你无法直接保存的加密档位把关。