B站批量视频下载器实战：基于yt-dlp的自动化备份与高效管理

先说结论：这个工具我自己用了快两年，下载过的视频加起来有几千个小时的时长，踩过的坑比大部分教程里写的都多。B站视频下载这个需求，说难不难，说简单也不简单，尤其当你从"偶尔下单个视频"升级到"批量下载整个收藏夹、整个UP主投稿甚至按关键词批量抓取"的时候，工具选型、参数配置、清晰度取舍、反爬策略、失败重试这些事全都会冒出来。

这篇文章我不会跟你聊那些违反平台规则的操作，更不会碰任何付费内容或需要特殊权限的资源。"B站批量视频下载器"对我来说就是三个字：效率。把一个又一个手动操作变成一条命令、一个脚本、一次批量任务，省下来的时间用来做更有价值的事。我会把工具选型、环境搭建、批量操作、常见问题这四个维度完整拆开，每个环节都给出我实测过的方案和参数，照着抄就行。

1. 项目整体设计与工具选型

1.1 核心需求拆解：什么场景才需要"批量"下载

先搞清楚一个前提：你为什么要批量下载B站视频？我总结下来基本是这几类需求，每一种对应的方案侧重点都不一样。

第一类是离线观看。比如要坐十几个小时的飞机、去信号很差的地方，提前把追的番剧、收藏的教程、关注的UP主最新投稿批量拉下来。这种需求最看重的是文件名规范、字幕烧录、清晰度稳定。

第二类是素材收集。做视频剪辑、做混剪、做二创的人，通常需要把参考视频、BGM来源、转场素材批量下载到本地。这种需求最看重的是画质（尤其是4K/杜比视界）和音质（无损音频、Hi-Res），同时要能精准筛选，而不是把整个频道都搬回家。

第三类是内容备份与数据分析。有人做运营，有人做舆情监控，有人做UP主管理，需要定期把某个UP主的所有投稿、某个话题下的所有视频、甚至某个分区的内容拉取下来做结构化分析。这种需求最看重的是自动化能力、元数据导出（标题、简介、标签、播放量、发布时间）和增量下载。

第四类是学习研究。比如你想系统分析B站的视频编码格式、弹幕数据结构、推荐算法在HTML5播放器里的行为，或者研究业界常见的流媒体分发协议。这种场景需要的是信源级的研究材料。

我自己的场景是第二类加第三类的混合体：既要高画质素材，也要定期备份关注的几十个UP主的更新。所以我最终选择了开源命令行工具作为主力，搭配一个图形界面工具作为补充。

1.2 工具选型横向对比：命令行 vs 图形界面

市面上的B站下载工具主要分两大阵营：命令行工具和图形界面工具。我做了一张对比表，方便你根据自己情况选择。

说实话，如果你只是偶尔下载一两个视频，图形界面工具确实够用了。但只要你下载量超过几十个，或者需要周期性重复执行，命令行工具的批量能力完全是碾压级的。我个人的建议是：以yt-dlp为主力，图形界面工具只用来处理那些量特别小、临时起意的下载需求。

1.3 为什么我会选择 yt-dlp 作为主力方案

yt-dlp 是著名开源工具 youtube-dl 的一个社区分支，项目长期处于高度活跃状态，B站接口的适配情况在主流工具里算数一数二的。选择它有几个关键理由。

第一，批量能力天然强大。yt-dlp 支持传入 URL 列表文件、支持通配符、支持日期范围过滤、支持正则匹配系列标题，这些特性对批量下载场景来说是刚需。比如我想下载某个UP主去年一整年的所有视频投稿，一条命令就能完成，而且能自动跳过已经下载过的文件。

第二，格式选择非常精细。B站视频在不同清晰度下实际返回的流媒体格式差异很大，yt-dlp 允许我指定"只下载1080p+"、指定"优先H.265编码"、"只下载无损音频"等策略，这在收集素材时特别好用。

第三，元数据与弹幕。它能一次把标题、简介、UP主信息、封面、弹幕、字幕全部抓下来存成结构化文件。对于做内容分析和备份的人来说，这比只拿一个视频文件有价值得多。

第四，开发接口开放。如果你懂一点 Python，完全可以把 yt-dlp 作为库嵌入自己的脚本里，配合定时任务实现无人值守的增量更新。

当然，yt-dlp 不是没有门槛，它需要命令行基础。但别被吓住——我接下来说的所有步骤，每一行命令都会拆开解释，你复制粘贴改一下 URL 就能用。

2. 环境准备与基础配置

2.1 一套可以稳定跑批量的基础环境

"批量下载器"这个名字听起来像个大工程，实际上跑批量的核心组件只有三个：Python 运行时、ffmpeg（音视频处理后端）、yt-dlp 本体。Windows、macOS、Linux 都能跑，我分别在 Windows 和一台 Ubuntu 服务器上验证过完全一样的操作。

先说 Windows 用户，安装顺序建议这样来：

1. 安装 Python。去官方主页下载 Python 3.10 或 3.11 版本，安装时务必勾选"Add Python to PATH"，否则后面命令行找不到 python 命令。
2. 安装 ffmpeg。到 ffmpeg 官网下载 Windows 构建版，解压后把 bin 目录加入系统环境变量的 Path。
3. 安装 yt-dlp。打开 CMD 或 PowerShell，执行pip install -U yt-dlp。

为什么必须装 ffmpeg？因为B站的高清流普遍采用"HLS音视频分离"策略——画面是一个文件，声音是另一个文件，浏览器播放时靠前端把它们合在一起。下载器拿到的也是分离的流，必须由 ffmpeg 在本地完成合并。没有 ffmpeg，就算下载成功也只能得到没有声音的视频。

Linux 用户就更简单了，以 Ubuntu 为例：

sudo apt update && sudo apt install -y python3 python3-pip ffmpeg pip3 install -U yt-dlp

装完之后，验证环境是否正常，在命令行输入yt-dlp --version，能看到版本号就说明主体环境OK。再输入ffmpeg -version，能看到输出就说明后端OK。这两步都通过，就可以进入批量下载的正题了。

2.2 基础下载命令拆解：从单视频到批量的第一步

先说最简单的情况：下载一个公开的B站视频。命令长这样：

yt-dlp -f "bv*+ba" --merge-output-format mp4 "https://www.bilibili.com/video/BVxxxxxxxxxx"

我来逐段解释下这个命令：

• -f "bv*+ba"：选择最佳视频流（带音轨的）加最佳纯音频流。注意B站的部分4K视频会返回多个音轨，ba代表最佳音频，bv*代表最合适的视频编码规格。如果你只想拿1080p，可以写成-f "bv*[height<=1080]+ba"。
• --merge-output-format mp4：合并输出为MP4容器。B站视频源流大多是FLV或者TS分片，合并成MP4兼容性最好。
• URL 后面的双引号是必须的，因为B站链接里可能包含特殊字符，不包引号在部分Shell里会被截断。

下载完你可以用播放器打开验证一下，确认画面和声音都正常。这一步走通了，批量操作就有了基础。

2.3 登录状态与清晰度权限经验

这里有个重要前置知识：B站不同清晰度的权限是不同的。1080p 以上清晰度要求账号登录，360p、480p 和 720p 通常不需要。如果你的目标是批量下载高画质内容，务必要让下载器带上登录态。

做法很简单：在浏览器里登录你的B站账号，然后从开发者工具里复制 cookie，存成一个文本文件，通过 yt-dlp 的--cookies参数传入。具体操作是：

1. 浏览器打开B站并登录账号。
2. 按 F12 打开开发者工具，切到 Network（网络）标签。
3. 刷新页面，随便点一个请求，找到请求头里的 Cookie 整段内容，复制出来。
4. 在本地建一个文本文件（比如bilibili_cookies.txt），格式是cookie.txt标准格式，或者直接用--add-header "Cookie:xxxx"传入。对新手来说更省事的是用--cookies-from-browser chrome让 yt-dlp 直接读取浏览器里的登录态。

我平时在服务器上批量跑，用的是第一种方式：把 cookie 存成文件，放在安全目录里，命令里加--cookies /path/to/cookies.txt。这里有个坑要注意：cookie 会过期，B站会定期刷新会话。我自己的做法是写了个定时脚本，每周重新登录一次并刷新 cookie 文件。

注意：带登录状态下载时，千万不要在脚本里硬编码你的账号密码字段，更不要用任何第三方登录辅助来绕过验证码之类的东西。B站的风控本来就比较严格，正常的下载请求频率加上登录态已经够用，没必要去碰规则边缘的操作。等你稳定跑一次能下载几十个视频后，你就明白频率比花招重要得多。

再强调一句：如果你访问不了某个视频的完整内容，那说明你没有对应的权限，请停止。不要把工具用在破解付费、绕过权限、获取未授权资源上。我这篇文章建立在"你对该内容有合法访问权"的前提上。绕权限的内容我从来没碰过，也不建议任何人去碰。

3. 批量下载实操全流程

3.1 批量下载整个收藏夹：一条命令全搞定

批量下载最常见的一个需求就是把收藏夹里几百个视频一次拉下来。这比一个个复制 URL 高效太多了。你只需要知道收藏夹的 ID，就能构造出对应 URL。

先说明收藏夹 URL 的结构。打开你的B站收藏夹页面，地址栏形如：

https://space.bilibili.com/你的UID/favlist?fid=收藏夹ID&ftype=create

其中fid后面的数字就是收藏夹ID。比如fid=123456789。拿到这个ID之后，yt-dlp 有一个非常方便的参数：--flat-playlist配合收藏夹 URL 可以直接批量解析列表。实操命令：

yt-dlp -f "bv*+ba" --merge-output-format mp4 \ --cookies /path/to/cookies.txt \ --output "/data/downloads/%(playlist_title)s/%(playlist_index)s_%(title)s.%(ext)s" \ --write-info-json \ --write-thumbnail \ "https://space.bilibili.com/你的UID/favlist?fid=收藏夹ID"

我们把参数逐个说清楚：

• --output指定了文件保存的路径模板。%(playlist_title)s是收藏夹名称，%(playlist_index)s是视频在收藏夹中的序号，%(title)s是视频标题。这样文件会按收藏夹自动建目录，文件名按序号排序，很好管理。
• --write-info-json把每个视频的完整元数据（标题、简介、标签、发布时间、UP主信息等）存成 JSON 文件，跟视频同名放在一起。别小看这个参数，做内容管理、搜索、数据分析的时候这是金矿。
• --write-thumbnail下载封面图。

收藏夹几百个视频会按顺序一个个下载。如果你担心太慢，还可以加一个并发参数--concurrent-fragments 4或者-N 4，表示同时下载4个视频，实测速度提升明显，但不要调太高，我试过-N 8的时候有的服务器IP会被临时限制，稳妥起见 4 个就好。

3.2 批量下载单个UP主的全部投稿

第二个高频场景是"下载某个UP主的所有视频"。很多做素材收集和竞品分析的人非常需要这个能力。同样是利用 yt-dlp 对B站空间的适配，直接传UP主的空间主页 URL 就行。

UP主空间 URL 格式通常是：

https://space.bilibili.com/UP主UID/video

命令和下载收藏夹很接近，唯一区别是 URL 换成空间视频页。如果UP主投稿数量特别多（几百上千个视频），有两个问题你需要提前规划。

第一个问题是命名冲突。UP主可能有多个视频叫《教程01》《教程02》这种标题，你可以把 URL 里数字后缀都拿进来做唯一标识：

--output "/data/up/%(uploader)s/%(upload_date)s_%(id)s_%(title)s.%(ext)s"

这里面%(upload_date)s是发布日期，%(id)s是BV号。有了这两个字段，文件名就不可能重复。

第二个问题是增量更新。如果你每周都要备份一次这个UP主的新投稿，不需要每次都全量下载，yt-dlp 的.ytdlp状态目录配合--download-archive参数可以实现增量下载：

--download-archive "/data/archive/up_uid.txt"

youtube-archive 文件里记录了所有已经成功下载的视频ID。执行时它会自动跳过这些文件，只下载新增内容。这是我用的最频繁的一个参数，实测每周增量备份几十个UP主投稿，全自动无感。

3.3 批量下载多P视频与分P处理

B站很多内容是多P视频，比如一整季的课程、一部电影的上下两集、一期综艺的分段。下载多P视频时的文件命名就非常关键。默认情况下，yt-dlp 会把多P视频合成为一个文件，也可以选择分P独立保存。

如果你想每一P单独存成一个文件，靠的还是输出模板参数。多P视频在 yt-dlp 里会被展开成一个列表（每一P相当于列表中的一项），所以：

--output "/data/multi/%(playlist_index)s_%(title)s_P%(chapter_number)s_%(section_number)s.%(ext)s"

实测下来，分P下载单独文件比合并成一个文件更实用：可以单独查看某一P，可以分集整理，也可以单独转交素材。合并语法也很透明，把--merge-output-format指定为 mp4 就行。

另一个注意点是多P视频的字幕。B站有些视频的字幕是CC字幕，可以使用--write-subs --sub-langs all一并抓下来存成 srt 格式。批量下载课程类内容时，字幕文件是做笔记和检索的好工具。

3.4 按关键词搜索批量下载

还有一个很多人需要但不太好找现成教程的场景：按关键词批量下载搜索结果命中的视频。比如你想收集某个人工智能主题的100个相关视频，用于学习研究或行业趋势分析。

yt-dlp 本身对B站的搜索接口适配了，直接传搜索 URL：

yt-dlp "https://search.bilibili.com/all?keyword=人工智能"

但这有个限制——搜索页是分页加载的，默认只会拿前面几页的结果。要获取更多结果，关键在参数--playlist-end和--playlist-items：

yt-dlp -f "bv*+ba" --merge-output-format mp4 \ --playlist-end 150 \ --output "/data/search/人工智能/%(playlist_index)s_%(title)s.%(ext)s" \ "https://search.bilibili.com/all?keyword=%E4%BA%BA%E5%B7%A5%E6%99%BA%E8%83%BD&order=click"

这里--playlist-end 150表示取前150个结果。order=click是URL里的排序参数，代表按播放量排序，这样拿到的都是热门视频。

说实话，这个方案的覆盖范围受B站搜索结果上限影响，拿不到特别全面的全量数据，但用来快速收集一个话题下热门的100到200个视频已经绰绰有余。如果你需要做更大范围的采集研究，我一般配合B站的公开接口按日期范围分段拉取，不过那种方案对你会不会用到就不好说了。

3.5 一个自动化增量备份的完整脚本参考

到了这一步我觉得直接把我在服务器上用了半年的一套增量备份方案贴出来，设置为每天凌晨定时跑，也可以当作做自己"批量下载器"项目的基础框架。

#!/bin/bash # 增量备份函数 backup_uid() { local uid=$1 local name=$2 echo "开始备份 $name (UID: $uid)" yt-dlp -f "bv*+ba" --merge-output-format mp4 \ --cookies /path/to/bilibili_cookies.txt \ --download-archive "/data/archive/archive_${uid}.txt" \ --write-info-json --write-thumbnail \ --output "/data/up/${name}/%(upload_date)s_%(id)s_%(title)s.%(ext)s" \ --concurrent-fragments 4 \ --sleep-requests 0.5 --sleep-interval 3 \ "https://space.bilibili.com/${uid}/video" \ >> "/data/logs/backup_${name}.log" 2>&1 echo "备份完成 $name" } backup_uid "UID1" "UP主A" backup_uid "UID2" "UP主B" backup_uid "UID3" "UP主C"

注意一下--sleep-requests 0.5和--sleep-interval 3这两个参数。前者表示两次请求之间至少间隔0.5秒，后者表示两个视频任务之间至少间隔3秒。我早期批量下载的时候没有加这些延时参数，结果跑了大概两百多个视频后B站出现了临时风控，所有请求都返回验证码异常。加了合理的限速之后，整批两三千个视频跑下来再没出过问题。

定时任务用crontab安排：

0 3 * * * /bin/bash /opt/scripts/bilibili_backup.sh

凌晨3点带宽占用低、平台风控宽松，实测是这个时间段最稳定。

4. 常见问题排查与避坑实录

4.1 经典问题：明明能播放却下载失败

这是新手遇到最多的问题，现象通常是：浏览器里视频能正常播，但 yt-dlp 报错，比如ERROR: Unable to extract video data或者HTTP Error 403。

问题根源绝大多数是接口格式变化或者请求头不完整。B站前端经常升级播放器，下载工具对新接口的适配会有几天的滞后。解决办法很简单：升级 yt-dlp。

pip install -U yt-dlp yt-dlp --version

我使用的时候至少每周升一次级。如果你不想手动升级，可以加一个--update-to stable参数让 yt-dlp 自己升级到最新稳定版。如果升级之后还报错，那就是 cookie 过期了，去浏览器重新登录刷新下 cookie 文件。

另一个导致 403 的原因是请求频率太高导致临时封禁。表现是批量下载到某个视频就卡住，一直失败。解决办法就是加--sleep-requests和--sleep-interval，把频率降下来，休息15到30分钟再继续。

4.2 下载的视频没有声音，或者音画不同步

这个问题的原因基本只有一个：缺少 ffmpeg 或者 ffmpeg 版本太旧。B站的高清流是音视频分离的，没有 ffmpeg 合并，下载器只能给你一个纯视频文件。

检查方法：

ffmpeg -version

如果提示找不到命令，就是 ffmpeg 没有加入 PATH。重新安装或者手动指定路径：

--ffmpeg-location /path/to/ffmpeg/bin

还有一种情况是 ffmpeg 版本太旧，不支持最新的 H.265（HEVC）解码。遇到这种情况，升级到最新版 ffmpeg 就解决了。如果你实在不想装 ffmpeg，可以用参数-f "bv*[ext=mp4]+ba[ext=m4a]"只下载MP4格式的音视频流，这样部分B站视频可以靠纯 MP4 封装直接使用。但这种方式可选清晰度会变少，我不推荐长期采用。

4.3 下载速度极慢，像老牛拉破车

批量下载时速度慢通常有两大原因：默认单线程下行和B站CDN调度给你的节点质量差。

先说单线程问题。B站单个流默认是分段传输的，yt-dlp 默认的并发分段数量是1。加速方法就是在命令里加：

-N 4 # 同时下载4个视频 --concurrent-fragments 6 # 每个视频内同时下载6个分片

但要控制好度，并发太高容易触发限流。我实测 4 个并发视频、每视频6分片是安全而高速的组合。

再说CDN节点问题。B站会根据你的IP地理位置分配CDN节点，有时候分到的节点质量不好，速度感人。解决方式是换线路或者换DNS。我自己的经验是：把 DNS 换成公共DNS，多试几次一般能找到质量更好的 CDN 节点。

4.4 批量下载时如何彻底解决"下载到一半失败就停住"

几十个视频的批量任务，最怕的就是跑到一半某个视频挂了，整个任务直接停掉。yt-dlp 默认确实是一个视频失败后直接跳到下一个，但如果你没设置重试，某些临时错误就会导致较多失败。

推荐的防御参数组合：

--retries 10 # 单文件重试最多10次 --fragment-retries 10 # 分片重试最多10次 --file-access-retries 10 # 文件访问失败重试 --skip-unavailable-fragments # 跳过无法下载的分片（不要默认，删了它）

还有一种更稳的做法：用 shell 循环逐个处理 URL。把要下载的视频 URL 存到一个list.txt文件，每行一个链接，然后：

#!/bin/bash while read url; do yt-dlp -f "bv*+ba" --merge-output-format mp4 \ --cookies /path/to/cookies.txt \ --retries 5 --fragment-retries 5 \ --output "/data/downloads/%(title)s.%(ext)s" \ "$url" || echo "下载失败: $url" >> /data/logs/failed_urls.txt sleep 3 done < list.txt

这个方案的可贵之处在于，单个视频的异常不会中断整个任务，失败的 URL 会被记下来，你稍后重新跑一次就补上了。多P视频和收藏夹批量任务建议同样采用这种"任务隔离"思路，比一个大列表撒下去稳健得多。

4.5 下载的弹幕/字幕文件，为什么有的有有的没有

批量下载时，有的视频能拿到弹幕有字幕，有的却拿不到。这个问题的根源不在下载器，而是B站对弹幕和字幕的托管是按视频维度走的。个别视频的弹幕接口返回为空是正常现象，不需要反复折腾。

想要稳定抓取弹幕，你需要确保命令里有这几个参数：

--write-subs --sub-langs all,en,zh-Hans # 下载所有字幕轨，指定简中 --write-auto-subs # 下载AI生成的字幕 --write-comments # 抓取评论数据（可选）

我实测过，CC字幕（UP主自己上传的）和AI字幕都能抓到。AI字幕文件可能比视频时长略短一点点，这是B站AI识别的正常误差，不要以为是下载错误。

4.6 登录态被频繁失效/风控问题

最后这个坑一定要单独说。批量下载账号使用的越频繁，遇到"登录态失效"的概率越大。尤其在服务器上持续跑批量任务时，B站会检测到不规律流量，然后强制你重新验证。

我的实际处理经验是：

1. 不要把下载频率拉满。合理的做法是每次请求间隔至少0.5秒，每个视频任务间隔至少2到3秒。
2. 不要让同一个IP在短时间内下载超过几百个视频。我个人的安全经验是单日同IP不超过800到1000个，超过就跑慢一点。
3. 不要同时用多台机器/多个IP频繁切换登录态。B站对登录态漂移非常敏感。
4. cookie失效后别着急，手动在浏览器里重新登录，重新导出 cookie，更新到文件里就行。

如果你遇到"需要验证码"这种情况，基本就是频率太高了。停止任务，等几小时，再减半频率继续跑。没有人能绕过验证码，也不应该绕。

5. 进阶玩法：从批量下载到批量管理

5.1 文件自动分类与重命名策略

批量下载完几百个视频，最痛苦的事不是下载，是下载完之后的文件管理。我第一次全量下载一个UP主的投稿，跑完一看目录，两百多个横七竖八标题混乱的文件，根本没法快速找到想要的视频。

后来我总结出一套可复用的命名策略。核心思路：文件名里包含足够多的识别信息，且保持有序。我的最终模板是：

--output "/data/videos/%(uploader)s/%(upload_date)s_%(id)s_%(title)s_[%(height)sp].%(ext)s"

其中%(height)sp会显示视频高度，如1080p、4K。这样文件名长这样：

/赤羽/20240115_BV1mC4y1c7xx_从零搭建某某系统_[1080p].mp4

这样做的好处非常明显：一眼看出来源UP主、发布日期、清晰度、标题。用文件管理器搜索时，按日期、按UP、按标题关键词都能快速定位。强烈建议从一开始就养成这个规范命名的习惯，省去后面大改文件名的地狱。

5.2 定时任务+日志检查：让批量下载完全自动化

每天定时自动下载听起来很爽，但完全无人值守有个隐患：你不知道它到底跑没跑、跑成什么样。解决方案是日志审计。

上面脚本里我用了>> /data/logs/backup_xxx.log 2>&1，这会把每次执行的输出追加到日志文件。你只需要每天早上看一眼日志末尾几行，确认有新增下载或者没有报错就行。

更进一步，写一个状态检查脚本，检测今天的日志文件有没有新内容，如果没有就触发告警。我用的是最朴素的方式：定时任务发一封邮件或者推送到手机。这样即便偶尔平台接口变更导致批量任务失败，自己也能第一时间感知到，而不是过了一周才发现备份早就断了。

5.3 把下载结果变成自己的索引库

这是我个人觉得比较有价值的一个延伸用法。批量下载后配合--write-info-json生成的元数据文件，可以快速构建一个本地视频索引库。用 Python 读取所有 JSON 文件，提取标题、UP主、标签、发布时间、时长、简介等信息，汇总成一个 CSV 或 SQLite 数据库，需要的时候按关键词一查询就出来了。

我做过的一个版本大概两百行代码，能回答的问题包括：这个UP主哪些视频时长超过10分钟、哪些视频标题包含关键词、哪一天发布的视频最多、哪类标签的视频在我的库里占了最大比例。对做内容研究的人来说，这比在B站网页端翻页高效太多。

好，关于B站批量视频下载器的技术细节我基本都拆完了。最后想给刚接触这个工具链的读者一点个人建议：很多看起来复杂的问题（批量失败、接口失效、风控提示），第一反应不要急着找替代工具或者偏门方案，而是先升级 yt-dlp、先降频率、先检查 cookie，这三个动作能解决掉百分之八十以上的异常。

我自己在这套方案上投入了大半年的时间，目前的状态是：几十个UP主的投稿每周自动增量备份，素材库接近上万条视频，总占用空间将近10TB。从需要手工操作大半天一轮，到每周零干预自动完成，这套"批量下载器"真正解决的问题不是下载本身，而是把重复劳动压缩到几乎为零，让我能把时间花在看视频、剪视频和写代码这些真正有价值的事情上。你也可以从一个小小的收藏夹开始，跑通一条、两条命令，然后再慢慢扩展成属于你自己的自动化下载体系。