为什么DY会同时提供FLV和HLS(TS+M3U8)

很多人在抓取抖音视频或分析接口时，都会遇到一个看似反直觉的现象：

明明不是直播，而是一个普通的抖音视频，接口里却同时给了 FLV 和 HLS（TS + M3U8）两套地址。

如果你也有过这个疑问，这篇文章基本可以一次性把底层逻辑讲清楚。

一、先给结论

在抖音的技术体系里，很多视频在底层并不是文件，而是已经结束的直播流。

也正因为如此：

会出现 FLV
会出现 HLS（TS + M3U8）
甚至会有多码率（SD / HD / FULL_HD）

这不是历史包袱，而是一个非常理性的工程选择。

二、三种看似相同、实则不同的视频形态

从用户视角看，抖音里都是视频，但从工程视角看，至少有三种形态。

1️⃣ 传统短视频（真正的文件）

CDN 上通常是：
有完整文件
适合：

这类视频通常不会出现 FLV / M3U8。

2️⃣ 直播

推流：RTMP
拉流：FLV / HLS
实时、无固定长度

这是大家最熟悉的直播形态。

3️⃣ 直播回放 / 点播流

这是本文的重点。

很多抖音视频，尤其是：

游戏区内容
OBS / 第三方推流
超长视频
直播切片

在底层都会被当成：

一个已经结束的直播流，用直播系统继续分发

于是你就会看到：

stream-xxxx.flv
index.m3u8
FULL_HD1 / HD1 / SD

三、FLV 到底是什么角色？

FLV 不是过时格式，而是：

为流式传输设计的封装格式

它的核心特征：

不需要等文件结束
边来边播
不依赖全局索引

为什么 FLV 特别适合直播系统？

因为它是流优先的：

特性	FLV
是否需要完整文件	否
是否支持中途开始	是
是否怕中断	否
是否适合录制	非常适合

对平台来说：

可以随时掐断
可以随时限速
成本低、实现简单

四、那 FLV 既然够用，为什么还要 HLS？

FLV 对工程够用，但对平台规模和生态不够用。

1️⃣ 浏览器与系统生态

现代环境下：

平台	FLV	HLS
Chrome / Edge	❌	✅
iOS / iPadOS	❌	✅
Android	❌	✅
智能电视	❌	✅

FLV 基本只能靠：

flv.js
自己解封装

而 HLS 是系统级支持。

2️⃣ CDN 与大规模分发

FLV 的问题：

长连接
不易缓存
断了就重来

HLS 的优势：

TS 切片
强 CDN 缓存友好
弱网可跳片
支持自适应码率

这对千万级并发至关重要。

五、为什么 HLS 一定是 TS + M3U8？

TS 并不是老格式，而是：

为不稳定网络设计的工业级切片格式

它的特点：

固定包长
任意切片
丢一片不影响整体

相比之下，MP4 并不适合随意切。

六、抖音真正的策略：双轨制

抖音并不是纠结，而是非常清楚地在区分对象。

使用场景	使用格式
内部系统 / 拉流 / 录制	FLV
App / Web / 普通用户	HLS

接口里的两套地址，并不是冗余，而是刻意设计。

七、从使用者视角的一个现实结论

想录制、想原画、想无水印 → FLV 最优
想稳定播放、跨设备、弱网友好 → HLS 必须

所以当你看到一个抖音视频同时有 FLV / M3U8 时：

不要觉得奇怪，这恰恰说明它走的是直播级别的分发系统。