B站4K视频本地备份全攻略：从Cookie配置到批量归档

我大概从2018年开始认真做本地视频备份，当时吃过一次大亏：一个追了两年的UP主突然删稿，补档资源七零八落，硬是没找回几个完整的高清源。后来凡是真正喜欢的视频，我都会第一时间拉到本地，尤其是4K画质的内容，更是优先处理。今天这篇东西，就是围绕bilibili-downloader这个命令行下载工具，把B站4K视频备份这件事彻底讲透——从环境准备、Cookie配置、清晰度选择，到文件归档和批量管理，一共3个核心步骤，跑通之后基本就是无脑执行。适合收藏党、剪辑素材党，以及手里攒了大量B站4K内容、想系统整理进NAS或移动硬盘的朋友参考。

1. 为什么要把B站4K视频备份到本地

1.1 本地备份的三个核心场景

很多人觉得“视频在B站挂着，随时能看，为什么要下载？”这个想法我理解，但真正跑过一遍备份流程之后想法会变。我自己遇到的真实场景大概有三类，每类都足够成为备份的理由。

第一类是收藏夹的深度整理。B站的收藏夹本质是一个在线列表，想离线看、想投屏到电视、想在NAS上做媒体库，都得先把文件拉下来。尤其是用Plex、Jellyfin做了家庭影音库之后，B站视频和本地电影混排，那种体验是网页端给不了的。

第二类是防删稿和防版权下架。UP主主动删稿、平台因版权问题下架、专栏内容调整，这些情况每天都在发生。你点开一个灰掉的视频页面，才意识到当初没备份的代价。这几年因为各种原因消失的视频，比我预想的多得多。

第三类是剪辑素材复用。做二次创作、混剪、字幕翻译，都需要源文件。在线播放器转出来的画质损失大，B站的4K源本身就是高码率，很多还带杜比或Hi-Res音轨，只有拿到原始文件才能做精细处理。

这三个场景对应三种需求：整理收藏、防止失效、复用素材。无论你是哪种，结论都是一样的——把4K视频变成本地文件，值得做。

1.2 B站4K源的获取机制与挑战

B站视频和普通网站的视频有一个很大区别：它的源文件走的是DASH流，也就是视频轨和音频轨是分开存储的。你在网页端看到的一整段视频，实际上是播放器边下边拼的——视频轨一个文件、音频轨一个文件，播放器负责让它们同步。

这个设计对带宽利用率和在线体验是好事，但对“下载到本地”来说就麻烦了。你没法像右键普通视频那样一键保存，因为浏览器拿到的只是分片数据，而且4K资源还被限制在登录态内。

具体来说，B站的4K清晰度有几个硬性门槛：

• 只有大会员账号能看到完整的4K选项，普通游客或非会员账号在接口层根本拿不到4K源。
• 4K视频切分成了成百上千个小分片，下载时需要拼接，且每个分片都有有效期，过期后URL会失效。
• 视频轨和音频轨需要合并，否则你拿到的是一段无声视频加一个单独音频文件。
• 4K视频体积大，一个二三十分钟的视频可能接近1GB甚至更大，长视频超过2GB也不罕见，断点续传几乎是刚需。

这些挑战叠加起来，就注定“B站4K下载”这件事不能靠浏览器插件或在线解析网站解决，必须用一个能完整模拟客户端协议、处理鉴权、拼接分片、调用ffmpeg合并轨道的专业下载器。

1.3 方案选型：为什么选中命令行工具

市面上能下载B站视频的方案不少，我几乎都试过，做个客观对比。

命令行工具的优势在于确定性和可控性。它不做任何图形界面的猜测，你能看到它请求了什么接口、拿到了什么格式、合并到了哪一步。出了问题，错误信息直接打在终端里，排查路径是透明的。批量下载、断点续传、输出模板、自动合并，这些核心功能全都有，而且完全没有在线解析网站那种“今天能下明天就不能”的不确定性。

我用的是bilibili-downloader这条技术路线的工具，下文统一简称bili-dl。它本质上是把yt-dlp这类成熟下载核心封装成一套更贴合B站场景的命令行接口，对4K、杜比音轨、封面、字幕、弹幕都有专门处理。接下来所有操作，都以这个工具为核心展开。

2. 动手前的准备工作

2.1 下载工具本体的安装

这一步没什么难度，难的是选对应你系统的安装方式。Windows用户建议直接下载release目录里编译好的exe文件，放到一个固定目录，把该目录加入PATH环境变量，就能在任意终端里调用bili-dl命令。

macOS和Linux用户更推荐用包管理器直接安装。macOS上用Homebrew最省事，一条命令搞定：

brew install bili-dl

Linux上则看发行版，Debian/Ubuntu系可以用源码装，也可以直接用二进制文件。装完之后验证一下版本：

bili-dl --version

能正常输出版本号，说明安装成功。这里有个很重要的习惯：建议固定一个版本使用，不要每次升级盲跟最新版。视频网站接口变动频繁，有时候最新版反而和新接口不兼容，装完的版本如果跑得稳，就先用着。

2.2 ffmpeg与媒体处理依赖

B站4K资源是DASH流，视频轨和音频轨分离，所以bili-dl在下载完成后需要调用ffmpeg把两条轨道合并成一个完整的MP4文件。ffmpeg是整个链路中不可或缺的一环，没有它你会得到一堆无法直接播放的碎片文件。

ffmpeg的安装同样简单，Windows用户可以在官网下载编译好的release包，解压后把bin目录加入PATH。macOS用户直接：

brew install ffmpeg

Linux用户用发行版自带的包管理器安装即可。装好之后验证一下：

ffmpeg -version

如果输出版本信息，就可以继续下一步。注意ffmpeg的版本不要太老，建议4.4以上，因为太老的版本对某些编码格式（比如AV1、HEVC）的支持不完整，合并时可能出现音画不同步或者编码错误。

2.3 获取并配置登录态（Cookie）

这是整个准备工作中最关键的一步，没有Cookie，4K选项根本不会出现在清晰度列表里。B站判断你有没有权限看4K，靠的就是请求头里的登录凭证。

获取Cookie的方式有两种，我分别说一下。第一种是浏览器插件导出cookies.txt文件，Chrome和Firefox都有类似EditThisCookie的插件，可以一键导出当前网站的Cookie为Netscape格式的文本文件。导出的文件保存为cookies.txt，后面命令里直接引用。

第二种方式更省事，直接用工具内置的浏览器读取功能：

bili-dl --cookies-from-browser chrome -F "视频URL"

这个参数会从Chrome的Cookie数据库中读取B站登录态，无需手动导出。第一次执行时，浏览器可能需要关闭，因为数据库文件被占用会读取失败。

这里有几点必须注意：

• Cookie是有有效期的，B站的登录态通常能维持较长时间，但账号安全策略变化、异地登录、改密等操作都会导致Cookie失效。
• Cookie包含你的账号信息，务必妥善保管，不要随意分享给别人，也不要提交到公开的Gist或代码仓库里。
• 如果使用了--cookies-from-browser，注意浏览器版本更新可能导致读取路径变化，报错时优先检查这个。

2.4 设计好你的下载输出模板

很多人下载视频都是下载完再手动改名、手动移动文件，这样在单集场景下没问题，一旦开启批量备份就乱了。正确的做法是先设计好消息的归档路径，再让工具自动按这个规则存放文件。

bili-dl的输出模板支持很多字段变量，比如上传者、标题、视频清晰度、视频时长、BV号等。我自己的归档规则是这样设计的：

-o "D:/BiliBackup/%(uploader)s/%(title)s.%(ext)s"

这个规则的效果是：视频按照UP主名字分目录存放，文件名直接使用视频标题，后缀由工具自动补全。比如UP主叫“混剪阿明”，视频标题是“2024年度混剪总结”，最终文件就是：

D:/BiliBackup/混剪阿明/2024年度混剪总结.mp4

这个目录结构对后续整理非常友好，一个UP主一个文件夹，整个文件夹直接扔进NAS或移动硬盘，媒体服务器也能自动识别。批量备份时还能配合--windows-filenames参数自动清理Windows系统不支持的字符，避免路径报错。

设计模板时还可以加一档分类目录，比如把“科技区”“影视区”“混剪区”作为一级目录：

-o "D:/BiliBackup/%(category)s/%(uploader)s/%(title)s.%(ext)s"

这样文件会先按分区归档，再按UP主细分，后期检索效率会高很多。

3. 3个步骤完成4K视频下载与备份

3.1 第一步：确认视频信息与4K清晰度

下载之前先看货，这是我一直坚持的操作。直接把视频URL喂给bili-dl，让它列出所有可用的清晰度和格式：

bili-dl --cookies cookies.txt -F "视频URL"

如果刚才选择了--cookies-from-browser方式，就把--cookies cookies.txt换成：

bili-dl --cookies-from-browser chrome -F "视频URL"

命令执行后，工具会把接口返回的所有媒体流信息列出来，大致长这样：

ID EXT RESOLUTION FPS │ FILESIZE TBR PROTO │ VCODEC VBR ACODEC MORE INFO 616 mp4 3840x2160 60 │ ~1.2GiB 8000k https │ av01.0.12M.08 7227k video only 615 mp4 3840x2160 60 │ ~1.1GiB 7500k https │ avc1.640834 6800k video only 302 mp4 1280x720 60 │ ~180MiB 1200k https │ avc1.64001F 1100k video only 140 m4a audio only │ ~20MiB 130k https │ audio only mp4a.40.2 129k

只看这一份列表，就可以判断这个视频是否支持4K下载。ID为616的分辨率是3840x2160，说明拿到的源确实是4K。不同的ID对应不同编码格式，比如AV1和H.265，这个选择会影响后续播放时的兼容性，具体选哪种编码后面细说。

确认完格式信息，再看一眼文件大小预估，心里有数之后就可以进入下一步正式的下载。

3.2 第二步：执行下载命令并完成音视频合并

确认4K源可用之后，执行下载命令。核心命令是：

bili-dl --cookies cookies.txt \ -f "bestvideo[height<=2160]+bestaudio" \ --merge-output-format mp4 \ -o "D:/BiliBackup/%(uploader)s/%(title)s.%(ext)s" \ "视频URL"

逐个参数拆开说，别复制完就完事，知道每个参数为什么这么写，将来出问题才有判断依据。

-f是格式选择参数，bestvideo[height<=2160]+bestaudio的意思很直白：选择最好的视频轨，分辨率不超过2160p（也就是4K以内），加上最好的音频轨，然后进行合并。height<=2160这个限制很关键，它能帮你过滤掉B站偶尔出现的8K源，因为8K体积太大了，对大部分人的存储和播放设备都不友好。如果视频本身没有4K源，这个规则会自动降到1080p，不会报错。

--merge-output-format mp4指定合并后的封装格式为MP4。B站的DASH流里，视频轨通常是MP4或MKV容器，音频轨可能是m4a，合并时可以指定输出为MP4，兼容性最好。这里的MP4只是封装容器的选择，不影响视频流内部的编码格式，所以不用担心转码损失画质。

执行过程中终端会实时显示下载进度、网速、已下载的大小。视频轨和音频轨是分别下载的，所以你会看到两次下载进度，最后工具自动调用ffmpeg完成合并。整体耗时取决于网速和视频长度，一个二十多分钟的视频，一般几分钟到十几分钟不等。

下载完成后可以顺手验证一下输出文件的完整性和时长：

ffprobe -v error -show_entries format=duration,size -of default=noprint_wrappers=1 "输出文件.mp4"

这个命令会输出视频的总时长和文件体积，可以和网页端的时长对照一下，确认合并没有丢帧、没有截断。

3.3 第三步：文件归档、完整性校验与增量备份

下载完成不等于备份完成。文件躺在下载目录里没有任何意义，真正有价值的是它能被稳定地取用、检索、长期保存。所以第三步要做的，是归档和校验。

我的做法分三步走。第一步是确认文件名和目录符合规范。用输出模板自动生成的命名已经基本达标，但偶尔会出现标题包含特殊字符的情况，比如包含井号、竖线、冒号。Windows对这类字符有限制，建议在下载命令里加上两个保险参数：

bili-dl --cookies cookies.txt \ -f "bestvideo[height<=2160]+bestaudio" \ --merge-output-format mp4 \ --windows-filenames \ --trim-filenames 200 \ -o "D:/BiliBackup/%(uploader)s/%(title)s.%(ext)s" \ "视频URL"

--windows-filenames会自动替换掉Windows文件系统中的非法字符，--trim-filenames 200可以截断超长的文件名，避免因为路径超过255字符限制导致写入失败。

第二步是完整性校验。文件名好看不代表文件没损坏，我一般在归档前跑一遍ffprobe，检查时长和码率是否正常。如果文件很大，还可以顺便生成一个哈希值作为备份记录：

certutil -hashfile "视频文件.mp4" SHA256

把哈希值记录到一个清单文件里，以后怀疑文件损坏时重新计算对比就知道结果。这个习惯对长期保存特别有价值，数据静默损坏是真实存在的，尤其是放在机械硬盘和网盘里的文件。

第三步是增量备份。这个思路很简单：每天新增的视频数量是有限的，不需要每次全量重下，只需要同步新增和变化的部分。最简单的做法是维护一个已下载BV号清单，新视频下载前先对照清单去重。也可以直接利用目录结构，按月或按周做增量同步。

如果本地有NAS，建议直接把下载目录挂载到NAS的同步任务里，或者用rsync做单向增量同步：

rsync -avP D:/BiliBackup/ /volume1/BiliBackup/

这样一个小小的同步任务，能让备份真正达到“即便本地磁盘坏了，文件还在NAS里”的安全级别。

3.4 批量备份场景：整个收藏夹一次带走

单集下载只是基本功，批量才是bili-dl真正闪光的地方。很多时候你想备份的是整个收藏夹，或者某个UP主的大批量视频，不可能一个URL一个URL地复制粘贴。

批量操作的思路很简单：把所有需要下载的视频URL或BV号写进一个文本文件，每行一个，然后用--batch-file参数交给工具处理：

bili-dl --cookies cookies.txt \ -f "bestvideo[height<=2160]+bestaudio" \ --merge-output-format mp4 \ --batch-file urls.txt \ -o "D:/BiliBackup/%(uploader)s/%(title)s.%(ext)s"

工具会逐行处理列表，遇到下载失败的视频会记录错误并跳过，不会因为单个异常中断整个批次。配合--continue参数，中断后重新执行命令会从断点继续，已下载完成的部分不会重复下载。

批量下载时我强烈建议先跑一个干跑模式，只列出信息不下载：

bili-dl --cookies cookies.txt --batch-file urls.txt --skip-download

这样可以提前发现哪些视频的4K源不可用或者Cookie过期，避免批量下载跑到一半才报错。

批量归档还有一个额外的好处：配合输出模板里的%(uploader)s字段，几十上百个视频会按UP主自动归类，不需要任何手动整理。备份完整个收藏夹，你在本地获得的就是一个结构清晰的视频库。

4. 常见问题与排查技巧实录

4.1 高频问题速查表

把我在实际操作中遇到的高频问题整理成一张表，方便直接对号入座：

这张表基本覆盖了90%的日常问题。下面挑几个最典型的详细展开，因为它们的排查过程比较有代表性。

4.2 4K选项突然消失：Cookie失效的应对

这个问题的典型表现是：昨天还能列出4K格式，今天再执行-F就没有3840x2160的选项了，最高只有1080p。

第一反应不应该是怀疑视频被限码或者工具坏了，而是去检查Cookie。B站的Cookie失效场景比你想象的频繁：跨设备登录、修改密码、账号风控、浏览器清理数据，都会导致旧的Cookie失效。

排查步骤很简单，先重新导出一次Cookie，再做一次-F测试。如果4K选项回来了，说明就是Cookie过期。如果重新导出依然没有4K，再检查账号本身是否有4K权限——B站的4K清晰度与大会员挂钩，部分特殊内容（如某些纪录片、番剧）可能还有额外限制。

还有一个容易被忽略的情况：浏览器插件导出的Cookie文件可能是JSON格式，而bili-dl识别的是Netscape格式。如果你的导出选项里能选格式，一定要选Netscape HTTP Cookie File。JSON格式的Cookie文件看起来有内容，但工具解析不了，表现出来就是“登录态失效”的假象。

4.3 音画不同步与文件合并失败的处理

合并失败是第二个高频坑，报错信息通常是找不到ffmpeg或者ffmpeg执行返回非零退出码。先说找不到ffmpeg，这个很简单，验证一下ffmpeg -version是否能正常输出，不行就重新安装并配置PATH。

但ffmpeg存在却返回错误，问题往往出在版本兼容性上。B站的4K视频有一部分是AV1编码，老版本ffmpeg对AV1的解码或者封装支持不完善，合并时可能直接失败或者把时间戳处理乱，音画就不同步了。解决办法是升级ffmpeg到较新版本，尤其是Windows用户，建议直接下载gyan.dev提供的全量编译版，比精简版覆盖的编码格式全。

另外有一种情况是下载过程中视频轨和音频轨的时长不一致，比如视频轨下了一半网络崩了，工具做了断点续传，但分段拼接出问题，导致合并出来的文件音画错位。这种就只能删掉临时文件重新下载，没有太好的捷径。所以前面提到的--continue参数虽然能续传，但如果续传的是大文件，我反而建议先删除未完成的临时文件再重下，避免拼接异常带来的隐藏问题。

4.4 下载中断与断点续传

B站视频动辄几个GB，中途掉线非常正常。我用过的下载工具里，很多在线解析站不支持断点，一旦中断只能从头再来，体验极差。

bili-dl本身支持断点续传机制，默认情况下下载中断后重新执行相同命令，已经完成的部分会直接跳过，从断点继续。这里有个实用的参数组合：

bili-dl --continue \ --retries 5 \ --fragment-retries 5 \ --batch-file urls.txt \ -o "D:/BiliBackup/%(uploader)s/%(title)s.%(ext)s"

--retries控制整体下载失败时的重试次数，--fragment-retries控制单个分片失败时的重试次数。B站的DASH流分片数量很多，偶发一两个分片请求超时很常见，设置合理的重试次数能显著提高大文件的下载成功率。

如果网络环境不太稳定，还可以加-N参数降低下载并发数。B站的接口对高并发请求有限制，并发太高反而会被限速甚至触发风控，调低到4或8是更稳妥的选择。

4.5 命名与归档的独家心得

最后分享几个我在归档整理上踩过的坑，这些细节常规教程不会写。

第一个坑是Windows路径长度。D:/BiliBackup/UP主名/视频标题.mp4看着不长，但某些视频标题特别长，加上UP主名字和目录前缀很容易超过255个字符的限制。Windows对这个限制卡得很死，超过就会报错。解决思路是在下载命令里加--trim-filenames参数主动截断，而不是等到报错了再去手工改文件名。

第二个坑是BV号在文件名里的作用。有些视频标题是重复的，比如“直播录屏”“日常vlog”这种命名，不同视频可能重名。归档时最好把关键标识写进文件名里。我的输出模板会再带一个BV号字段：

-o "D:/BiliBackup/%(uploader)s/%(title)s_%(id)s.%(ext)s"

%(id)s对应的就是视频的BV号，这样即使标题完全一致，文件也不冲突，而且以后想反查B站原始链接也方便。

第三个坑无关技术，是个习惯问题。下载完成后先别急着删临时文件，我的做法是随机在播放器里拖几条时间轴，确认开头、中间、结尾三段的音画同步都没问题，再清理临时文件。这步检查花不了一分钟，但能省去日后整理媒体库时才发现文件损坏的麻烦。

第四个坑是外挂字幕和封面。做视频归档不只是下载视频文件本身，B站视频通常还有封面图和字幕轨。bili-dl支持--write-subs和--write-thumbnail参数，建议加进日常命令里，封面和外挂字幕一并归档，对后续做媒体库索引帮助很大。

备份这件事，工具能力只占一半，另一半是目录规范和维护习惯。我的做法是每周花十分钟做一次增量同步，把新增视频下载进NAS对应目录后跑一遍校验脚本，确认信息无误就归档。这套流程跑顺之后，是不需要每次思考“怎么下载”的。如果你已经有囤了不少B站4K视频，不妨从这个周末开始，拿一个收藏夹练手，跑通一次完整流程，之后自然就顺手了。