先说结论这个工具我自己用了快两年下载过的视频加起来有几千个小时的时长踩过的坑比大部分教程里写的都多。B站视频下载这个需求说难不难说简单也不简单尤其当你从偶尔下单个视频升级到批量下载整个收藏夹、整个UP主投稿甚至按关键词批量抓取的时候工具选型、参数配置、清晰度取舍、反爬策略、失败重试这些事全都会冒出来。这篇文章我不会跟你聊那些违反平台规则的操作更不会碰任何付费内容或需要特殊权限的资源。B站批量视频下载器对我来说就是三个字效率。把一个又一个手动操作变成一条命令、一个脚本、一次批量任务省下来的时间用来做更有价值的事。我会把工具选型、环境搭建、批量操作、常见问题这四个维度完整拆开每个环节都给出我实测过的方案和参数照着抄就行。1. 项目整体设计与工具选型1.1 核心需求拆解什么场景才需要批量下载先搞清楚一个前提你为什么要批量下载B站视频我总结下来基本是这几类需求每一种对应的方案侧重点都不一样。第一类是离线观看。比如要坐十几个小时的飞机、去信号很差的地方提前把追的番剧、收藏的教程、关注的UP主最新投稿批量拉下来。这种需求最看重的是文件名规范、字幕烧录、清晰度稳定。第二类是素材收集。做视频剪辑、做混剪、做二创的人通常需要把参考视频、BGM来源、转场素材批量下载到本地。这种需求最看重的是画质尤其是4K/杜比视界和音质无损音频、Hi-Res同时要能精准筛选而不是把整个频道都搬回家。第三类是内容备份与数据分析。有人做运营有人做舆情监控有人做UP主管理需要定期把某个UP主的所有投稿、某个话题下的所有视频、甚至某个分区的内容拉取下来做结构化分析。这种需求最看重的是自动化能力、元数据导出标题、简介、标签、播放量、发布时间和增量下载。第四类是学习研究。比如你想系统分析B站的视频编码格式、弹幕数据结构、推荐算法在HTML5播放器里的行为或者研究业界常见的流媒体分发协议。这种场景需要的是信源级的研究材料。我自己的场景是第二类加第三类的混合体既要高画质素材也要定期备份关注的几十个UP主的更新。所以我最终选择了开源命令行工具作为主力搭配一个图形界面工具作为补充。1.2 工具选型横向对比命令行 vs 图形界面市面上的B站下载工具主要分两大阵营命令行工具和图形界面工具。我做了一张对比表方便你根据自己情况选择。维度命令行工具yt-dlp图形界面工具DownKyi/哌哩哔哩浏览器脚本方案批量效率极高一条命令跑完整个收藏夹中高需要手动或半手动添加低逐页操作功能完整性完整支持弹幕、字幕、元数据、格式转换较完整但部分高级参数缺失受限依赖页面解析学习成本高需要理解命令行参数低所见即所得极低安装即用维护活跃度高社区持续更新中个人项目波动大低容易失效稳定性强有完整错误处理和重试机制中偶尔会因为接口变更需要更新弱平台前端一改就废合规边界中需自行注意用途中同上低容易误触发风控说实话如果你只是偶尔下载一两个视频图形界面工具确实够用了。但只要你下载量超过几十个或者需要周期性重复执行命令行工具的批量能力完全是碾压级的。我个人的建议是以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 用户安装顺序建议这样来安装 Python。去官方主页下载 Python 3.10 或 3.11 版本安装时务必勾选Add Python to PATH否则后面命令行找不到 python 命令。安装 ffmpeg。到 ffmpeg 官网下载 Windows 构建版解压后把 bin 目录加入系统环境变量的 Path。安装 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*[height1080]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参数传入。具体操作是浏览器打开B站并登录账号。按 F12 打开开发者工具切到 Network网络标签。刷新页面随便点一个请求找到请求头里的 Cookie 整段内容复制出来。在本地建一个文本文件比如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收藏夹IDftypecreate其中fid后面的数字就是收藏夹ID。比如fid123456789。拿到这个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.txtyoutube-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站的搜索接口适配了直接传搜索 URLyt-dlp https://search.bilibili.com/all?keyword人工智能但这有个限制——搜索页是分页加载的默认只会拿前面几页的结果。要获取更多结果关键在参数--playlist-end和--playlist-itemsyt-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%BDorderclick这里--playlist-end 150表示取前150个结果。orderclick是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 21 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.265HEVC解码。遇到这种情况升级到最新版 ffmpeg 就解决了。如果你实在不想装 ffmpeg可以用参数-f bv*[extmp4]ba[extm4a]只下载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站会检测到不规律流量然后强制你重新验证。我的实际处理经验是不要把下载频率拉满。合理的做法是每次请求间隔至少0.5秒每个视频任务间隔至少2到3秒。不要让同一个IP在短时间内下载超过几百个视频。我个人的安全经验是单日同IP不超过800到1000个超过就跑慢一点。不要同时用多台机器/多个IP频繁切换登录态。B站对登录态漂移非常敏感。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 21这会把每次执行的输出追加到日志文件。你只需要每天早上看一眼日志末尾几行确认有新增下载或者没有报错就行。更进一步写一个状态检查脚本检测今天的日志文件有没有新内容如果没有就触发告警。我用的是最朴素的方式定时任务发一封邮件或者推送到手机。这样即便偶尔平台接口变更导致批量任务失败自己也能第一时间感知到而不是过了一周才发现备份早就断了。5.3 把下载结果变成自己的索引库这是我个人觉得比较有价值的一个延伸用法。批量下载后配合--write-info-json生成的元数据文件可以快速构建一个本地视频索引库。用 Python 读取所有 JSON 文件提取标题、UP主、标签、发布时间、时长、简介等信息汇总成一个 CSV 或 SQLite 数据库需要的时候按关键词一查询就出来了。我做过的一个版本大概两百行代码能回答的问题包括这个UP主哪些视频时长超过10分钟、哪些视频标题包含关键词、哪一天发布的视频最多、哪类标签的视频在我的库里占了最大比例。对做内容研究的人来说这比在B站网页端翻页高效太多。好关于B站批量视频下载器的技术细节我基本都拆完了。最后想给刚接触这个工具链的读者一点个人建议很多看起来复杂的问题批量失败、接口失效、风控提示第一反应不要急着找替代工具或者偏门方案而是先升级 yt-dlp、先降频率、先检查 cookie这三个动作能解决掉百分之八十以上的异常。我自己在这套方案上投入了大半年的时间目前的状态是几十个UP主的投稿每周自动增量备份素材库接近上万条视频总占用空间将近10TB。从需要手工操作大半天一轮到每周零干预自动完成这套批量下载器真正解决的问题不是下载本身而是把重复劳动压缩到几乎为零让我能把时间花在看视频、剪视频和写代码这些真正有价值的事情上。你也可以从一个小小的收藏夹开始跑通一条、两条命令然后再慢慢扩展成属于你自己的自动化下载体系。