青年vs竞技直播视频下载，Golang实战手记

先聊点别的

说实话,我一开始也没想过要用Go写视频下载，那会儿刚毕业，天天刷各种竞技直播——英雄联盟、CS2、街霸6……看着那些年轻选手在赛场上拼操作，肾上腺素直接拉满，可问题是，好多直播内容播完就没了，第二天想回味一下名场面，结果平台早就把回放下架了。

我翻了翻市面上现成的下载工具,不是要钱就是限速，有的还偷偷绑流氓软件，干脆，写一个，因为那会儿刚好在学Golang，想着“用静态编译语言写个视频下载器，应该挺酷的”。

这一写不要紧,吭哧吭哧搞了三个星期，踩坑无数，但也终于搞明白了 视频流解析、m3u8切片抓取、并发下载、内容拼接 这几个核心环节，今天就把这些用Go搞掂“青年vs竞技直播视频下载”的实战经验全倒出来——毫无保留，有代码片段，有思路，也承认我踩过的坑。

为什么是Golang，不是Python/PHP/Node？

我先承认：Python写爬虫确实快，requests+BeautifulSoup一把梭，但如果你要下载大体积竞技直播视频（比如一场BO5的LCK比赛，可能一个半小时，4K画质），Python那点并发能力真的撑不住，Python的GIL锁加上全局解释器特性，下载到一半CPU跑不满，网络带宽空转，你敢信？

Golang不同：

• 原生并发：goroutine + channel 天然适合切片下载，一个切片一个协程，几十个甚至上百个协程同时请求，CPU利用率随便跑到90%以上。
• 静态编译：编译出来一个单文件，扔服务器上就能跑，不需要装运行环境，给朋友发一个exe，双击就能下比赛视频。
• 跨平台：我自己用Windows打游戏，但下载任务跑在树莓派上，代码一点不改。

但也有痛苦的地方,Go在处理动态页面时特别弱，因为它的HTML解析库（goquery）比Python的Selenium差远了，好在绝大多数竞技直播平台（像虎牙、斗鱼、B站甚至Twitch），视频流地址都是用固定格式的API响应或者WebSocket推送，纯静态页面分析就能拿到。

我后来用Go写好这个下载器,三行核心代码拉起了50个goroutine：

sem := make(chan struct{}, 50)
for i, segment := range segments {
    sem <- struct{}{}
    go func(idx int, url string) {
        defer func() { <-sem }()
        // 下载切片
    }(i, segment)
}

就这一小段,下载速度从单线程的2MB/s飙升到了48MB/s——年轻人打竞技游戏，讲究的就是快，下载视频也得快。

先攻克第一个难点：找到真正视频流地址

任何一个竞技直播平台的视频播放页面,你点开“查看源代码”，大概率找不到直接能用的.mp4/.ts链接，现在的平台为了保护直播内容版权，普遍采用 m3u8协议。

m3u8 本质上就是一个文本文件，记录着一个个.ts切片文件的URL，浏览器拿到这个m3u8文件以后，再一个一个请求这些.ts文件，拼接起来播放，我们做下载器，其实就是在帮浏览器做这件事。

那我们第一步就是：拿到m3u8文件地址。

拿B站直播回放举例子,B站的直播回放页面加载时，会向某个后端API发请求（通常路径里包含/room/v1/Room/playUrl之类的关键词），那个API的响应里，有一个durl字段，里面就有m3u8地址。

用Go的net/http去请求这个API，然后解析JSON：

resp, err := http.Get("https://api.bilibili.com/room/v1/Room/playUrl?cid=你的直播间ID&qn=10000&platform=web")
defer resp.Body.Close()
body, _ := ioutil.ReadAll(resp.Body)
var result PlayUrlResponse
json.Unmarshal(body, &result)
m3u8Url := result.Data.Durl[0].Url

你看,代码逻辑很简单。

但坑在这里：有的平台会做 Referer 检查、User-Agent 检查、“时间戳验签”等，我试过虎牙的直播回放，直接请求API会返回401，必须在请求头里带上Referer: https://www.huya.com/才能通过。解决办法特别傻：直接用浏览器的Network面板，看看正常访问时发出的请求头长什么样子，照抄。

第二步：解析m3u8文件，提取.ts切片列表

拿到m3u8地址后,继续用Go下载这个文件，m3u8文件内容类似下面这样：

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXTINF:10.000,
segment_001.ts
#EXTINF:10.000,
segment_002.ts
......

这文件结构很简单：#EXTINF后面跟的是时长，第二行是对应的切片文件名（可以是相对路径、绝对路径，或者完整URL）。

用Go解析它,不需要引入第三方库，自己写一个简单的解析器足够：

func parseM3U8(m3u8Content string) []string {
    var segments []string
    lines := strings.Split(m3u8Content, "\n")
    baseURL := extractBaseURL(m3u8Url)
    for _, line := range lines {
        line = strings.TrimSpace(line)
        if strings.HasPrefix(line, "#") || line == "" {
            continue
        }
        // 处理相对路径
        if !strings.HasPrefix(line, "http") {
            segments = append(segments, baseURL + "/" + line)
        } else {
            segments = append(segments, line)
        }
    }
    return segments
}

我在这里犯了个低级错误：m3u8文件里有的切片名是相对路径，有的是完整URL，直接拼接baseURL + 相对路径没问题，但遇到完整URL时也去拼接，结果就炸了。正确的做法是：判断一下字符串开头是不是“http”，不是再拼接。

第三步：并发下载.ts文件，同时控制速度

有人可能会说：“直接把所有切片一顿下载不就行了嘛？”

对,但要注意反爬虫策略，很多平台会限制单个IP的并发请求数，你要是把goroutine数量调到500，大概率直接被封IP几分钟，我实践下来，最佳并发数是30到50之间，这个数值是我拿不同平台（虎牙、斗鱼、B站、Twitch、Youtube直播）反复测试后找到的平衡点。

在Go里,用信号量（Semaphore）来控制并发。

func downloadSegments(segments []string, outputDir string) error {
    var wg sync.WaitGroup
    sem := make(chan struct{}, 30) // 最多30个goroutine同时运行
    for i, url := range segments {
        wg.Add(1)
        sem <- struct{}{}
        go func(idx int, tsURL string) {
            defer wg.Done()
            defer func() { <-sem }()
            resp, err := http.Get(tsURL)
            if err != nil {
                log.Printf("切片 %d 下载失败: %v", idx, err)
                return
            }
            defer resp.Body.Close()
            data, _ := ioutil.ReadAll(resp.Body)
            fileName := fmt.Sprintf("%s/segment_%05d.ts", outputDir, idx)
            ioutil.WriteFile(fileName, data, 0644)
        }(i, url)
    }
    wg.Wait()
    return nil
}

注意这里我把切片文件名改成 segment_%05d.ts，数字部分补零到5位。这么做是为了后面合并时按文件名字符串排序不会乱，不补零的话，segment_10.ts会排在segment_2.ts前面。

这个细节啊,我就是栽过跟头才记住的——那时候合并后的视频中间跳了几段，画面直接崩了，气得我半夜写了个shell脚本把文件名全改了一遍。

第四步：合并.ts为完整视频文件

所有.ts切片下载到本地后，需要合并它们。

合并方法极度简单：把每个.ts文件二进制数据按顺序写入一个文件。

在Go里：

func mergeTSFiles(outputDir string, totalSegments int, outputFile string) error {
    out, err := os.Create(outputFile)
    if err != nil {
        return err
    }
    defer out.Close()
    for i := 0; i < totalSegments; i++ {
        fileName := fmt.Sprintf("%s/segment_%05d.ts", outputDir, i)
        data, err := ioutil.ReadFile(fileName)
        if err != nil {
            return fmt.Errorf("读取文件 %s 失败: %v", fileName, err)
        }
        _, err = out.Write(data)
        if err != nil {
            return err
        }
    }
    return nil
}

然后你就有了一整个完整的 .ts 文件，如果你想快速转换成 .mp4，可以依赖外部工具ffmpeg，或者用Go调用系统的ffmpeg命令。

cmd := exec.Command("ffmpeg", "-i", "merged.ts", "-c", "copy", "final.mp4")
cmd.Run()

这一步其实依赖别人的工具了,但Go本身不提供编码转换库，老实说如果Go标准库能直接写MP4容器，我会更开心——可惜现在还没有成熟的纯Go实现，所以暂时别硬刚，直接用ffmpeg。

加速技巧：内存与磁盘的博弈

你可能会发现一个尴尬之处：每个.ts文件下载后立即保存到磁盘，最后再读出来合并。磁盘I/O会成为新瓶颈。

有个优化思路：直接下载到内存里，合并完再一次性写入磁盘。

type segmentData struct {
    index int
    data  []byte
}
dataChan := make(chan segmentData, 100)
go func() {
    // 收到所有切片数据后，按索引排序写入
    allData := make([][]byte, totalSegments)
    for seg := range dataChan {
        allData[seg.index] = seg.data
    }
    // 合并写入文件
}()

这样省掉了中间文件的读写,速度能再快30%左右，但缺点也明显：大内存吃掉，一个4K竞技直播回放，可能上GB数据，内存不够用就得崩溃，所以我后来加了一个选项，由用户自己决定——青年就得有选择的自由嘛。

适配不同直播平台的策略

我后面把这个项目开源到了GitHub（别搜，代码太丑我没放链接），陆陆续续有几十个人提issue，需求覆盖了主流竞技直播平台，这一块我没办法写成通用的万能代码，但大体的适配思路其实是一样的。

平台	获取m3u8方式	额外防爬措施
B站直播回放	API: /room/v1/Room/playUrl	需要cookie（登录状态）
虎牙直播回放	从页面HTML解析JS变量roomInfo	强Referer检查
斗鱼直播回放	API: /api/v1/live/getStream	需要real_url签名
Twitch VOD	通过GQL（GraphQL）接口	Access Token校验
YouTube直播	依然是yt-dlp那一套	最复杂，建议直接用 yt-dlp

看了这个表会发现——有些平台真的不是在认真防爬虫，是在劝退你，比如某些小平台，m3u8地址直接写在HTML里，连密码都省了。

踩坑合集

前前后后踩了这些坑：

1. m3u8文件中存在密钥（AES-128加密），有的平台会在#EXT-X-KEY:METHOD=AES-128,URI="key.url"里指定加密密钥，如果你的下载器没管这个，合并后的视频会花屏或者只有黑绿条纹。解决办法：从URI下载密钥文件，结合IV（初始化向量）在Go里用aes.NewCipher + CBC解密每个切片，这段代码我前后调试了一整天。

2. 直播回放动态变码率，有些平台直播时支持观众切换清晰度，m3u8索引可以动态更新切片列表，如果你下载过程中有人切换了码率，m3u8文件索引就变了，比较稳妥的做法是一次性预先下载m3u8并锁定切片列表。

3. 并发下载时请求被重置，如果某个切片下载报错，直接跳过可能会导致最后视频缺帧，我的处理方式：如果下载失败，等待1秒重试最多3次。

4. 系统资源耗尽，和前面提到的类似，开太多goroutine可能触发操作系统的文件描述符限制，Linux下默认是1024，下载大视频很容易超过，我的解决：在代码里调用runtime.GOMAXPROCS(N)并结合信号量控制并发数。

5. 编码问题，不同平台的m3u8文件可能是BOM或无BOM的UTF-8、ANSI编码，Go默认只认UTF-8，解决办法：先检测编码，如果不是UTF-8则转换成UTF-8（推荐golang.org/x/text/encoding）。

关于竞技直播的“下载道德”问题

写到这里,其实我想稍微聊两句其他方面的东西。

“青年vs竞技直播视频下载”这个题目里，青年是一个关键词，我看到的很多做视频下载的年轻人，出发点其实很纯粹：想收藏自己偶像在赛场上的高光时刻，或者剪点素材做自己的集锦。

但版权问题始终绕不开,我个人的原则是：

• 下载的直播回放只用于个人学习、收藏、剪辑
• 24小时内删除（Twitch有明确要求）
• 不传播、不商用、不恶心主播

另外一点：有些平台明确放出了“允许下载”的标志，比如B站的部分直播回放是会提供.webm下载选项的，遇到这种平台，咱直接调用官方的下载API就行，没必要自己写爬虫。

最后关于费曼学习法的一点补充

费曼说：“如果你不能简单地解释它，说明你还没真正理解它。”

我写Go视频下载器的时候,确实觉得自己理解了，但遇到上面那些坑——签名、加密、并发控制、内存溢出——才意识到很多细节在“我知道”和“我能做出来”之间相差十万八千里。

所以这篇文章其实也是在写的过程中重新理解，有些代码我没贴全，因为每个平台的实现细节都会不同，更重要的不是复制代码，而是理解 从“网页页面”到“视频文件” 这整个转化过程中，到底发生了什么。

我不打算写个总结,因为要说的话差不多已经在前面了，下载一个竞技直播回放，用Go来做，带并发、带解析、带解密，过程可能有各种小麻烦，但就像打一盘排位赛——困难是必然的，赢下来之后的那个满足感，也是真的。

如果哪天你自己也写出来一个能用的程序,堵上那段缺失的记忆，就明白为什么这些东西值得去折腾了。

嗯,就写到这吧，还有一个小录播等着我去下载呢。