1. 为什么我最终选择了 bilibili-downloader 而不是浏览器插件先说结论如果你只是偶尔存一两个短视频浏览器插件确实够用但一旦涉及 4K 画质、批量下载、字幕同步、充电专属内容这些需求插件基本就歇菜了。我自己折腾过不下十种方案从 Chrome 扩展商店里那些一键下载的插件到各种在线解析网站最后稳定下来的还是 bilibili-downloader 这类命令行工具。原因不复杂——它把 B 站的视频流、音频流、字幕、弹幕拆得明明白白你能拿到什么、拿到什么规格全在参数里写着不跟你玩玄学。很多人第一次接触 B 站下载会有一个误区以为网页上能播 4K下载下来就一定是 4K。实际上 B 站网页端播放 4K 是有条件的登录账号、大会员状态、视频本身是否提供 4K 源三者缺一不可。而下载工具能不能拿到 4K取决于它请求的接口返回了哪些清晰度选项。bilibili-downloader 的逻辑是直接调用 B 站的播放地址接口把返回的dash流里所有可用的视频轨和音频轨列出来你选哪个它就下哪个。这就意味着只要你的账号有权限、视频有 4K 源它就能拿到真正的 4K 流而不是网页播放器那种经过二次处理的画面。还有一个很现实的问题B 站的视频和音频是分开传输的。你在网页上看视频播放器自动帮你把视频轨和音频轨合在一起了但下载工具拿到的是两条独立的流。bilibili-downloader 默认会分别下载视频和音频然后调用 ffmpeg 做合并。这个设计一开始让我觉得麻烦后来才发现是好事——你可以只下音频当播客听也可以只下视频轨做素材灵活性比那些一键下载的插件高得多。至于为什么不用那些在线解析网站原因更简单一是画质压缩严重很多网站所谓的4K其实是把 1080p 拉伸上去的二是广告和跳转太多点三次才能拿到下载链接三是隐私问题你不知道它把你的请求日志拿去干什么了。bilibili-downloader 跑在本地请求直接发往 B 站服务器中间不经过第三方这一点对我来说很重要。2. 环境准备Python、ffmpeg 和 Cookie 这三样缺一不可2.1 Python 版本选择与虚拟环境隔离bilibili-downloader 是一个 Python 项目所以第一步是确保你的机器上有 Python。我建议用 3.9 到 3.11 之间的版本太老的版本3.7 以下有些依赖库装不上太新的版本3.12偶尔会遇到某些包还没适配。Windows 用户去 Python 官网下载安装包时记得勾选Add Python to PATH否则后面在命令行里敲python会提示找不到命令。装好之后强烈建议用虚拟环境隔离依赖。我见过太多人因为全局环境里装了几十个包版本冲突导致工具跑不起来。操作很简单python -m venv bili-env # Windows bili-env\Scripts\activate # macOS / Linux source bili-env/bin/activate激活后命令行前面会出现(bili-env)的标识说明你在这个独立环境里操作装什么包都不会污染系统环境。这一步看起来多余但等你以后同时用好几个 Python 工具时就知道虚拟环境有多省心了。2.2 ffmpeg 的安装与验证ffmpeg 是合并视频轨和音频轨的关键工具没有它你下载下来的就是两个分离的文件播放器打开要么没声音要么没画面。Windows 用户去 ffmpeg 官网下载压缩包解压后把bin目录添加到系统环境变量 Path 里。macOS 用户用 Homebrew 一行命令搞定brew install ffmpeg。Linux 用户用 apt 或 yum 装就行。装完之后一定要验证ffmpeg -version如果输出了版本信息说明配置成功。如果提示不是内部或外部命令那就是 Path 没配好回去检查环境变量。这个坑我踩过当时以为装好了结果下载完视频合并那一步报错排查了半天才发现是 ffmpeg 没在 Path 里。2.3 Cookie 的获取与有效期管理这是整个流程里最容易被忽略、也最容易出问题的一步。B 站的高清视频1080P 以上和充电专属内容都需要登录状态才能访问所以你必须把浏览器的 Cookie 提供给下载工具。获取方法是在浏览器里登录 B 站按 F12 打开开发者工具切到 Network 标签刷新页面找到任意一个请求在 Request Headers 里找到Cookie字段把那一长串值复制出来。注意Cookie 里包含你的登录凭证不要分享给任何人也不要用来源不明的工具去解析它。Cookie 是有有效期的通常几天到几周不等。如果你发现之前能下载的视频突然提示 403 或需要登录大概率就是 Cookie 过期了重新获取一次即可。我自己的习惯是每次批量下载前先测试一个视频确认 Cookie 还有效再开始大批量操作避免下到一半全部失败。3. 安装 bilibili-downloader 与核心参数拆解3.1 安装过程中的依赖问题处理在虚拟环境激活的状态下进入项目目录执行pip install -r requirements.txt正常情况下几分钟就装完了。但如果你在国内网络环境下遇到某个包下载超时可以换用国内镜像源pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple我遇到过几次httpx或aiohttp这类网络库编译失败的情况通常是因为系统缺少编译工具链。Windows 用户如果报错提到 Microsoft Visual C 14.0 is required去装一个 Visual Studio Build Tools 就行。macOS 用户一般不会遇到这个问题因为 Xcode Command Line Tools 已经自带了。3.2 清晰度代码对照为什么你选的 4K 可能不是真 4Kbilibili-downloader 在列出可用流的时候会显示一串数字代码这些代码对应不同的清晰度。很多人看到数字就直接选最大的但其实需要理解背后的含义代码清晰度说明6240P极低画质基本不用16360P流畅画质32480P清晰画质64720P高清画质801080P高清需登录1121080P高码率 1080P需大会员1161080P6060帧 1080P需大会员1204K超清需大会员关键点在于代码 120 才是真正的 4K有些视频虽然标着4K但实际提供的最高流只有 112 或 116。工具会把所有可用选项列出来你看到 120 就说明这个视频确实有 4K 源。如果只看到 80那就算你账号是大会员也拿不到 4K因为 UP 主上传的就是 1080P。3.3 音频流的选择逻辑视频轨选完之后还要选音频轨。B 站的音频流通常有 30216、30232、30280 这几个代码分别对应不同的码率。30280 是最高码率约 192Kbps30232 是中等约 128Kbps30216 是最低约 64Kbps。如果你对音质有要求选 30280如果只是随便听听30232 也够用。我一般直接选最高的反正音频文件不大多占不了多少空间。4. 实战从单视频下载到批量任务编排4.1 单个视频的完整下载流程假设你要下载一个 BV 号为BV1xx411c7mD的视频基本命令是这样的python bili_downloader.py -u https://www.bilibili.com/video/BV1xx411c7mD -c 你的Cookie值工具会先请求视频信息列出所有可用的视频轨和音频轨然后你根据提示选择。下载完成后它自动调用 ffmpeg 合并最终输出一个完整的 MP4 文件。整个过程不需要你手动干预但第一次用的时候建议盯着输出日志看一遍了解它每一步在做什么。如果你不想交互式选择也可以用参数直接指定清晰度python bili_downloader.py -u 视频URL -c Cookie -q 120 -a 30280这样它就直接下载 4K 视频轨和最高码率音频轨省去手动选择的步骤。批量脚本里用这种方式最方便。4.2 批量下载多个视频的脚本写法手动一个个下太慢了我通常会把要下载的 URL 写到一个文本文件里每行一个然后用循环处理while read line; do python bili_downloader.py -u $line -c Cookie -q 120 -a 30280 sleep 3 done urls.txt那个sleep 3很重要。B 站对请求频率是有风控的如果你连续快速请求轻则返回 412 错误重则临时封禁你的 IP。加个几秒的间隔模拟人类操作节奏能大幅降低被风控的概率。我自己的经验是间隔 3 到 5 秒比较稳妥下载几十个视频从来没出过问题。4.3 字幕和弹幕的单独处理bilibili-downloader 除了下载视频本身还支持把字幕和弹幕单独导出。字幕通常是 JSON 格式里面包含每条字幕的时间戳和文本内容。如果你要做视频笔记或者翻译这个功能很实用。弹幕导出后是 XML 格式可以用专门的弹幕播放器加载也可以自己写脚本做词频分析。提示字幕文件的语言代码要和视频对应有些视频有多个语言的字幕轨下载时注意选择。5. 那些让我折腾半天的坑与对应的解决思路5.1 下载到一半报 403Cookie 失效的典型表现这个错误我遇到过至少五次。表现是前几个视频下载正常突然某个视频开始报 403 Forbidden。一开始我以为是那个视频有特殊限制后来发现是 Cookie 在请求过程中过期了。B 站的 Cookie 有效期不是固定的有时候几个小时就失效有时候能撑好几天。解决办法就是重新获取 Cookie然后从失败的那个视频继续下载。为了避免重复下载已经完成的文件我会在脚本里加一个判断如果目标文件已存在就跳过。5.2 合并后的视频音画不同步这个问题通常出现在下载 60 帧视频的时候。原因是视频轨和音频轨的时间基准不一致ffmpeg 默认的合并参数没有做时间对齐。解决办法是在合并命令里加上-async 1参数让 ffmpeg 自动调整音频的时间戳。如果你用的是工具自带的合并功能可以检查一下它的 ffmpeg 调用参数里有没有这一项。没有的话手动合并一次就行ffmpeg -i video.m4s -i audio.m4s -c copy -async 1 output.mp45.3 充电专属视频的下载限制充电专属视频需要你给对应的 UP 主充过电才能访问。工具本身不绕过这个限制它只是用你的账号权限去请求。如果你没充过电请求会返回权限不足的错误。这一点没什么好说的尊重创作者的劳动成果是基本前提。另外即使你充过电充电视频的 Cookie 有效期可能比普通视频更短下载时尽量一次性完成。5.4 文件名乱码与特殊字符处理B 站的视频标题里经常包含 emoji、特殊符号、甚至换行符直接拿来做文件名会导致各种问题。Windows 系统对文件名有字符限制某些符号不允许出现在文件名里。我的做法是在脚本里加一层清洗把标题里的特殊字符替换成下划线长度截断到 100 个字符以内。这样虽然文件名没那么好看但至少不会因为命名问题导致下载失败。6. 下载之后的画质验证与二次处理6.1 如何确认下载的确实是 4K下载完成后别急着删原始文件。用 ffprobe 检查一下视频的实际分辨率ffprobe -v error -select_streams v:0 -show_entries streamwidth,height -of csvsx:p0 output.mp4如果输出是3840x2160那就是真 4K。如果是1920x1080说明你下载的其实是 1080P 流可能视频本身就没有 4K 源也可能是清晰度代码选错了。这个验证步骤我每次批量下载后都会跑一遍确保没有下错规格。6.2 把 1080P 修复到 4K 的现实预期热词里有人问1080p 视频修复到 4k 要多久时间这里说句实话真正的画质修复需要 AI 超分辨率模型逐帧处理一个 10 分钟的视频用消费级显卡跑大概需要几十分钟到几个小时不等。而且效果取决于模型质量和原始素材不是所有 1080P 都能修复成看起来像真 4K 的效果。如果你只是想让视频在 4K 屏幕上播放时不那么模糊用 ffmpeg 做个简单的拉伸也行但那只改变分辨率数字不增加实际细节。6.3 下载文件的归档与命名规范我自己的归档习惯是按 UP 主名字建文件夹里面再按发布时间排序文件名格式是日期_标题_清晰度.mp4。这样以后要找某个视频直接按时间或关键词搜索就行。另外建议保留一份原始的.m4s文件至少一周万一合并后的文件有问题还能重新合并不用重新下载。7. 关于工具选型和使用边界的一些个人体会用了大半年 bilibili-downloader最大的感受是命令行工具的学习曲线确实比插件陡但一旦跑通效率和可控性完全不是一个级别。插件你只能点一个按钮它给你什么你就拿什么命令行工具你可以精确控制下载哪个流、用什么参数合并、文件怎么命名、任务怎么编排。对于偶尔下载一两个视频的普通用户插件可能更省事但对于需要批量处理、对画质有要求、或者要做二次创作的人来说花半个小时把命令行工具配好后面省下的时间远超这个投入。另外提醒一句下载下来的视频自己看、做笔记、做素材参考都没问题但不要二次上传到其他平台也不要用作商业用途。B 站的视频版权属于 UP 主下载工具只是帮你把在线内容保存到本地不改变版权归属。这一点在任何一个视频平台上都是一样的道理。最后分享一个我常用的小技巧如果你经常下载同一个 UP 主的视频可以把 UP 主的空间 URL 直接传给工具它会自动解析出该 UP 主的所有视频列表然后你选择要下载哪些。这比一个个复制视频链接快多了尤其是面对一个更新了几百个视频的 UP 主时效率提升非常明显。
bilibili-downloader 命令行工具：4K 视频批量下载与 ffmpeg 合并实战
1. 为什么我最终选择了 bilibili-downloader 而不是浏览器插件先说结论如果你只是偶尔存一两个短视频浏览器插件确实够用但一旦涉及 4K 画质、批量下载、字幕同步、充电专属内容这些需求插件基本就歇菜了。我自己折腾过不下十种方案从 Chrome 扩展商店里那些一键下载的插件到各种在线解析网站最后稳定下来的还是 bilibili-downloader 这类命令行工具。原因不复杂——它把 B 站的视频流、音频流、字幕、弹幕拆得明明白白你能拿到什么、拿到什么规格全在参数里写着不跟你玩玄学。很多人第一次接触 B 站下载会有一个误区以为网页上能播 4K下载下来就一定是 4K。实际上 B 站网页端播放 4K 是有条件的登录账号、大会员状态、视频本身是否提供 4K 源三者缺一不可。而下载工具能不能拿到 4K取决于它请求的接口返回了哪些清晰度选项。bilibili-downloader 的逻辑是直接调用 B 站的播放地址接口把返回的dash流里所有可用的视频轨和音频轨列出来你选哪个它就下哪个。这就意味着只要你的账号有权限、视频有 4K 源它就能拿到真正的 4K 流而不是网页播放器那种经过二次处理的画面。还有一个很现实的问题B 站的视频和音频是分开传输的。你在网页上看视频播放器自动帮你把视频轨和音频轨合在一起了但下载工具拿到的是两条独立的流。bilibili-downloader 默认会分别下载视频和音频然后调用 ffmpeg 做合并。这个设计一开始让我觉得麻烦后来才发现是好事——你可以只下音频当播客听也可以只下视频轨做素材灵活性比那些一键下载的插件高得多。至于为什么不用那些在线解析网站原因更简单一是画质压缩严重很多网站所谓的4K其实是把 1080p 拉伸上去的二是广告和跳转太多点三次才能拿到下载链接三是隐私问题你不知道它把你的请求日志拿去干什么了。bilibili-downloader 跑在本地请求直接发往 B 站服务器中间不经过第三方这一点对我来说很重要。2. 环境准备Python、ffmpeg 和 Cookie 这三样缺一不可2.1 Python 版本选择与虚拟环境隔离bilibili-downloader 是一个 Python 项目所以第一步是确保你的机器上有 Python。我建议用 3.9 到 3.11 之间的版本太老的版本3.7 以下有些依赖库装不上太新的版本3.12偶尔会遇到某些包还没适配。Windows 用户去 Python 官网下载安装包时记得勾选Add Python to PATH否则后面在命令行里敲python会提示找不到命令。装好之后强烈建议用虚拟环境隔离依赖。我见过太多人因为全局环境里装了几十个包版本冲突导致工具跑不起来。操作很简单python -m venv bili-env # Windows bili-env\Scripts\activate # macOS / Linux source bili-env/bin/activate激活后命令行前面会出现(bili-env)的标识说明你在这个独立环境里操作装什么包都不会污染系统环境。这一步看起来多余但等你以后同时用好几个 Python 工具时就知道虚拟环境有多省心了。2.2 ffmpeg 的安装与验证ffmpeg 是合并视频轨和音频轨的关键工具没有它你下载下来的就是两个分离的文件播放器打开要么没声音要么没画面。Windows 用户去 ffmpeg 官网下载压缩包解压后把bin目录添加到系统环境变量 Path 里。macOS 用户用 Homebrew 一行命令搞定brew install ffmpeg。Linux 用户用 apt 或 yum 装就行。装完之后一定要验证ffmpeg -version如果输出了版本信息说明配置成功。如果提示不是内部或外部命令那就是 Path 没配好回去检查环境变量。这个坑我踩过当时以为装好了结果下载完视频合并那一步报错排查了半天才发现是 ffmpeg 没在 Path 里。2.3 Cookie 的获取与有效期管理这是整个流程里最容易被忽略、也最容易出问题的一步。B 站的高清视频1080P 以上和充电专属内容都需要登录状态才能访问所以你必须把浏览器的 Cookie 提供给下载工具。获取方法是在浏览器里登录 B 站按 F12 打开开发者工具切到 Network 标签刷新页面找到任意一个请求在 Request Headers 里找到Cookie字段把那一长串值复制出来。注意Cookie 里包含你的登录凭证不要分享给任何人也不要用来源不明的工具去解析它。Cookie 是有有效期的通常几天到几周不等。如果你发现之前能下载的视频突然提示 403 或需要登录大概率就是 Cookie 过期了重新获取一次即可。我自己的习惯是每次批量下载前先测试一个视频确认 Cookie 还有效再开始大批量操作避免下到一半全部失败。3. 安装 bilibili-downloader 与核心参数拆解3.1 安装过程中的依赖问题处理在虚拟环境激活的状态下进入项目目录执行pip install -r requirements.txt正常情况下几分钟就装完了。但如果你在国内网络环境下遇到某个包下载超时可以换用国内镜像源pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple我遇到过几次httpx或aiohttp这类网络库编译失败的情况通常是因为系统缺少编译工具链。Windows 用户如果报错提到 Microsoft Visual C 14.0 is required去装一个 Visual Studio Build Tools 就行。macOS 用户一般不会遇到这个问题因为 Xcode Command Line Tools 已经自带了。3.2 清晰度代码对照为什么你选的 4K 可能不是真 4Kbilibili-downloader 在列出可用流的时候会显示一串数字代码这些代码对应不同的清晰度。很多人看到数字就直接选最大的但其实需要理解背后的含义代码清晰度说明6240P极低画质基本不用16360P流畅画质32480P清晰画质64720P高清画质801080P高清需登录1121080P高码率 1080P需大会员1161080P6060帧 1080P需大会员1204K超清需大会员关键点在于代码 120 才是真正的 4K有些视频虽然标着4K但实际提供的最高流只有 112 或 116。工具会把所有可用选项列出来你看到 120 就说明这个视频确实有 4K 源。如果只看到 80那就算你账号是大会员也拿不到 4K因为 UP 主上传的就是 1080P。3.3 音频流的选择逻辑视频轨选完之后还要选音频轨。B 站的音频流通常有 30216、30232、30280 这几个代码分别对应不同的码率。30280 是最高码率约 192Kbps30232 是中等约 128Kbps30216 是最低约 64Kbps。如果你对音质有要求选 30280如果只是随便听听30232 也够用。我一般直接选最高的反正音频文件不大多占不了多少空间。4. 实战从单视频下载到批量任务编排4.1 单个视频的完整下载流程假设你要下载一个 BV 号为BV1xx411c7mD的视频基本命令是这样的python bili_downloader.py -u https://www.bilibili.com/video/BV1xx411c7mD -c 你的Cookie值工具会先请求视频信息列出所有可用的视频轨和音频轨然后你根据提示选择。下载完成后它自动调用 ffmpeg 合并最终输出一个完整的 MP4 文件。整个过程不需要你手动干预但第一次用的时候建议盯着输出日志看一遍了解它每一步在做什么。如果你不想交互式选择也可以用参数直接指定清晰度python bili_downloader.py -u 视频URL -c Cookie -q 120 -a 30280这样它就直接下载 4K 视频轨和最高码率音频轨省去手动选择的步骤。批量脚本里用这种方式最方便。4.2 批量下载多个视频的脚本写法手动一个个下太慢了我通常会把要下载的 URL 写到一个文本文件里每行一个然后用循环处理while read line; do python bili_downloader.py -u $line -c Cookie -q 120 -a 30280 sleep 3 done urls.txt那个sleep 3很重要。B 站对请求频率是有风控的如果你连续快速请求轻则返回 412 错误重则临时封禁你的 IP。加个几秒的间隔模拟人类操作节奏能大幅降低被风控的概率。我自己的经验是间隔 3 到 5 秒比较稳妥下载几十个视频从来没出过问题。4.3 字幕和弹幕的单独处理bilibili-downloader 除了下载视频本身还支持把字幕和弹幕单独导出。字幕通常是 JSON 格式里面包含每条字幕的时间戳和文本内容。如果你要做视频笔记或者翻译这个功能很实用。弹幕导出后是 XML 格式可以用专门的弹幕播放器加载也可以自己写脚本做词频分析。提示字幕文件的语言代码要和视频对应有些视频有多个语言的字幕轨下载时注意选择。5. 那些让我折腾半天的坑与对应的解决思路5.1 下载到一半报 403Cookie 失效的典型表现这个错误我遇到过至少五次。表现是前几个视频下载正常突然某个视频开始报 403 Forbidden。一开始我以为是那个视频有特殊限制后来发现是 Cookie 在请求过程中过期了。B 站的 Cookie 有效期不是固定的有时候几个小时就失效有时候能撑好几天。解决办法就是重新获取 Cookie然后从失败的那个视频继续下载。为了避免重复下载已经完成的文件我会在脚本里加一个判断如果目标文件已存在就跳过。5.2 合并后的视频音画不同步这个问题通常出现在下载 60 帧视频的时候。原因是视频轨和音频轨的时间基准不一致ffmpeg 默认的合并参数没有做时间对齐。解决办法是在合并命令里加上-async 1参数让 ffmpeg 自动调整音频的时间戳。如果你用的是工具自带的合并功能可以检查一下它的 ffmpeg 调用参数里有没有这一项。没有的话手动合并一次就行ffmpeg -i video.m4s -i audio.m4s -c copy -async 1 output.mp45.3 充电专属视频的下载限制充电专属视频需要你给对应的 UP 主充过电才能访问。工具本身不绕过这个限制它只是用你的账号权限去请求。如果你没充过电请求会返回权限不足的错误。这一点没什么好说的尊重创作者的劳动成果是基本前提。另外即使你充过电充电视频的 Cookie 有效期可能比普通视频更短下载时尽量一次性完成。5.4 文件名乱码与特殊字符处理B 站的视频标题里经常包含 emoji、特殊符号、甚至换行符直接拿来做文件名会导致各种问题。Windows 系统对文件名有字符限制某些符号不允许出现在文件名里。我的做法是在脚本里加一层清洗把标题里的特殊字符替换成下划线长度截断到 100 个字符以内。这样虽然文件名没那么好看但至少不会因为命名问题导致下载失败。6. 下载之后的画质验证与二次处理6.1 如何确认下载的确实是 4K下载完成后别急着删原始文件。用 ffprobe 检查一下视频的实际分辨率ffprobe -v error -select_streams v:0 -show_entries streamwidth,height -of csvsx:p0 output.mp4如果输出是3840x2160那就是真 4K。如果是1920x1080说明你下载的其实是 1080P 流可能视频本身就没有 4K 源也可能是清晰度代码选错了。这个验证步骤我每次批量下载后都会跑一遍确保没有下错规格。6.2 把 1080P 修复到 4K 的现实预期热词里有人问1080p 视频修复到 4k 要多久时间这里说句实话真正的画质修复需要 AI 超分辨率模型逐帧处理一个 10 分钟的视频用消费级显卡跑大概需要几十分钟到几个小时不等。而且效果取决于模型质量和原始素材不是所有 1080P 都能修复成看起来像真 4K 的效果。如果你只是想让视频在 4K 屏幕上播放时不那么模糊用 ffmpeg 做个简单的拉伸也行但那只改变分辨率数字不增加实际细节。6.3 下载文件的归档与命名规范我自己的归档习惯是按 UP 主名字建文件夹里面再按发布时间排序文件名格式是日期_标题_清晰度.mp4。这样以后要找某个视频直接按时间或关键词搜索就行。另外建议保留一份原始的.m4s文件至少一周万一合并后的文件有问题还能重新合并不用重新下载。7. 关于工具选型和使用边界的一些个人体会用了大半年 bilibili-downloader最大的感受是命令行工具的学习曲线确实比插件陡但一旦跑通效率和可控性完全不是一个级别。插件你只能点一个按钮它给你什么你就拿什么命令行工具你可以精确控制下载哪个流、用什么参数合并、文件怎么命名、任务怎么编排。对于偶尔下载一两个视频的普通用户插件可能更省事但对于需要批量处理、对画质有要求、或者要做二次创作的人来说花半个小时把命令行工具配好后面省下的时间远超这个投入。另外提醒一句下载下来的视频自己看、做笔记、做素材参考都没问题但不要二次上传到其他平台也不要用作商业用途。B 站的视频版权属于 UP 主下载工具只是帮你把在线内容保存到本地不改变版权归属。这一点在任何一个视频平台上都是一样的道理。最后分享一个我常用的小技巧如果你经常下载同一个 UP 主的视频可以把 UP 主的空间 URL 直接传给工具它会自动解析出该 UP 主的所有视频列表然后你选择要下载哪些。这比一个个复制视频链接快多了尤其是面对一个更新了几百个视频的 UP 主时效率提升非常明显。
