我大概从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站视频的方案不少我几乎都试过做个客观对比。方案上手难度4K支持批量能力稳定性我的评价录屏软件低看源画质无一般有明显画质损失基本不适合备份浏览器开发者工具手动抓包高可以无低适合学习不适合日常使用在线解析网站低不稳定无低有隐私和失效风险不推荐浏览器插件中看实现弱中可选但批量能力受限命令行下载器中高完整强高我的主力方案本文主角命令行工具的优势在于确定性和可控性。它不做任何图形界面的猜测你能看到它请求了什么接口、拿到了什么格式、合并到了哪一步。出了问题错误信息直接打在终端里排查路径是透明的。批量下载、断点续传、输出模板、自动合并这些核心功能全都有而且完全没有在线解析网站那种“今天能下明天就不能”的不确定性。我用的是bilibili-downloader这条技术路线的工具下文统一简称bili-dl。它本质上是把yt-dlp这类成熟下载核心封装成一套更贴合B站场景的命令行接口对4K、杜比音轨、封面、字幕、弹幕都有专门处理。接下来所有操作都以这个工具为核心展开。2. 动手前的准备工作2.1 下载工具本体的安装这一步没什么难度难的是选对应你系统的安装方式。Windows用户建议直接下载release目录里编译好的exe文件放到一个固定目录把该目录加入PATH环境变量就能在任意终端里调用bili-dl命令。macOS和Linux用户更推荐用包管理器直接安装。macOS上用Homebrew最省事一条命令搞定brew install bili-dlLinux上则看发行版Debian/Ubuntu系可以用源码装也可以直接用二进制文件。装完之后验证一下版本bili-dl --version能正常输出版本号说明安装成功。这里有个很重要的习惯建议固定一个版本使用不要每次升级盲跟最新版。视频网站接口变动频繁有时候最新版反而和新接口不兼容装完的版本如果跑得稳就先用着。2.2 ffmpeg与媒体处理依赖B站4K资源是DASH流视频轨和音频轨分离所以bili-dl在下载完成后需要调用ffmpeg把两条轨道合并成一个完整的MP4文件。ffmpeg是整个链路中不可或缺的一环没有它你会得到一堆无法直接播放的碎片文件。ffmpeg的安装同样简单Windows用户可以在官网下载编译好的release包解压后把bin目录加入PATH。macOS用户直接brew install ffmpegLinux用户用发行版自带的包管理器安装即可。装好之后验证一下ffmpeg -version如果输出版本信息就可以继续下一步。注意ffmpeg的版本不要太老建议4.4以上因为太老的版本对某些编码格式比如AV1、HEVC的支持不完整合并时可能出现音画不同步或者编码错误。2.3 获取并配置登录态Cookie这是整个准备工作中最关键的一步没有Cookie4K选项根本不会出现在清晰度列表里。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[height2160]bestaudio \ --merge-output-format mp4 \ -o D:/BiliBackup/%(uploader)s/%(title)s.%(ext)s \ 视频URL逐个参数拆开说别复制完就完事知道每个参数为什么这么写将来出问题才有判断依据。-f是格式选择参数bestvideo[height2160]bestaudio的意思很直白选择最好的视频轨分辨率不超过2160p也就是4K以内加上最好的音频轨然后进行合并。height2160这个限制很关键它能帮你过滤掉B站偶尔出现的8K源因为8K体积太大了对大部分人的存储和播放设备都不友好。如果视频本身没有4K源这个规则会自动降到1080p不会报错。--merge-output-format mp4指定合并后的封装格式为MP4。B站的DASH流里视频轨通常是MP4或MKV容器音频轨可能是m4a合并时可以指定输出为MP4兼容性最好。这里的MP4只是封装容器的选择不影响视频流内部的编码格式所以不用担心转码损失画质。执行过程中终端会实时显示下载进度、网速、已下载的大小。视频轨和音频轨是分别下载的所以你会看到两次下载进度最后工具自动调用ffmpeg完成合并。整体耗时取决于网速和视频长度一个二十多分钟的视频一般几分钟到十几分钟不等。下载完成后可以顺手验证一下输出文件的完整性和时长ffprobe -v error -show_entries formatduration,size -of defaultnoprint_wrappers1 输出文件.mp4这个命令会输出视频的总时长和文件体积可以和网页端的时长对照一下确认合并没有丢帧、没有截断。3.3 第三步文件归档、完整性校验与增量备份下载完成不等于备份完成。文件躺在下载目录里没有任何意义真正有价值的是它能被稳定地取用、检索、长期保存。所以第三步要做的是归档和校验。我的做法分三步走。第一步是确认文件名和目录符合规范。用输出模板自动生成的命名已经基本达标但偶尔会出现标题包含特殊字符的情况比如包含井号、竖线、冒号。Windows对这类字符有限制建议在下载命令里加上两个保险参数bili-dl --cookies cookies.txt \ -f bestvideo[height2160]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[height2160]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 高频问题速查表把我在实际操作中遇到的高频问题整理成一张表方便直接对号入座问题现象常见原因解决方案列出格式时没有4K选项未配置Cookie或Cookie已失效重新导出Cookie确认账号为大会员下载报“HTTP Error 403”请求头缺失或IP风控配好Cookie和UA控制并发数视频轨和音频轨合并失败ffmpeg未安装或版本过旧安装新版ffmpeg并确认PATH生效文件名包含非法字符导致报错Windows文件系统限制加--windows-filenames参数下载速度极慢或频繁中断默认并发过高触发限速调整下载线程数开启断点续传没有声音或只有声音选了纯视频轨或纯音频轨用bestvideobestaudio组合格式文件播放时卡顿或花屏视频轨下载不完整重新下载校验时长和体积这张表基本覆盖了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视频不妨从这个周末开始拿一个收藏夹练手跑通一次完整流程之后自然就顺手了。