本地视频下载工具搭建：yt-dlp与ffmpeg批量下载及音频提取实战

1. 为什么我要自己搭一套视频下载工具

先说结论：市面上能用的视频下载工具我几乎试了个遍，最后稳定留在电脑里的，是一套基于开源项目二次配置的本地方案。原因很简单——在线下载站广告多、限速狠、动不动就失效；浏览器插件功能单一，批量任务基本歇菜；而命令行工具虽然强大，但参数记不住，每次用都要翻文档。

我平时的工作流里，经常需要把一些公开课、技术分享、纪录片片段存到本地，方便离线反复看，也方便做笔记时截图引用。手机端缓存虽然方便，但导出麻烦，格式也受限。所以我的核心需求就三条：能下视频也能单独抽音频、支持批量任务、画质和音质尽量保留原始水平。

这套方案我用了大半年，从最初的单视频测试，到后来一次性处理几十个链接的合集，中间踩了不少坑，也总结出一些让下载成功率大幅提升的配置技巧。下面我把整个搭建思路、核心参数、实操步骤和排错经验完整拆开讲，哪怕你之前没碰过命令行，跟着走也能跑通。

提示：本文所有操作均针对公开可访问的网络内容，请遵守相关平台的服务条款，仅将工具用于个人学习、研究等合理场景，不要用于任何商业传播或侵权行为。

2. 工具选型：为什么是这套组合而不是别的

2.1 核心下载引擎的选择逻辑

视频下载这件事，底层拼的是对各类流媒体协议的支持能力。目前公开内容平台普遍采用HLS（HTTP Live Streaming）或DASH（Dynamic Adaptive Streaming over HTTP）协议，视频和音频是分开传输的，下载完还需要合并。所以一个合格的下载引擎必须同时具备三个能力：协议解析、分片下载、音视频合流。

我最终选定的核心引擎是yt-dlp，它是 youtube-dl 的活跃分支，更新频率高，对各类站点的适配速度快。选它而不是其他工具，主要看中这几点：

• 站点支持广：内置提取器覆盖上千个平台，B站自然在列，而且维护者响应很快，平台改版后通常几天内就能修复。
• 格式选择灵活：可以通过参数精确指定要什么画质、什么编码、什么容器格式，而不是只能选“高清”“超清”这种模糊档位。
• 后处理能力强：内置调用 ffmpeg 做合并、转封装、抽音频，不需要自己写脚本拼接。
• 批量与归档：支持从文件读取 URL 列表，支持断点续传，支持下载归档记录，避免重复劳动。

至于图形界面，我试过几款，要么更新滞后导致解析失效，要么捆绑一堆无关功能。最后我选择命令行 + 少量配置文件的方式，虽然一开始要记几个参数，但一旦配好，后续就是复制粘贴链接的事，效率反而最高。

2.2 辅助组件的搭配

光有下载引擎还不够，实际使用中还需要两个关键配角：

ffmpeg是音视频处理的瑞士军刀。下载下来的视频流和音频流是分离的，必须靠它合并成完整文件；如果想单独提取音频，也是用它转码成 mp3 或 m4a。安装时注意要装完整版，不要装精简版，否则可能缺少某些编码器。

配置文件是我强烈建议新手一开始就建立的。yt-dlp 支持通过配置文件预设常用参数，比如输出路径模板、默认画质偏好、并发分片数等。这样每次调用就不用敲一长串参数，直接yt-dlp 链接就能按你的习惯下载。

2.3 为什么不推荐在线下载站和浏览器插件

在线下载站的问题在于：你粘贴链接后，它是在别人的服务器上帮你解析和下载，然后再传给你。这中间有两个风险——一是速度受限于对方服务器带宽，高峰期慢得离谱；二是你的下载行为完全暴露在第三方日志里，隐私性差。而且这类站点为了生存，往往塞满广告和跳转，体验极差。

浏览器插件的问题则是能力天花板低。受限于浏览器沙箱环境，插件很难调用 ffmpeg 做合流，所以要么只能下低清合并版，要么下下来音视频分离你还得自己处理。批量任务更是基本不支持，下个合集要一个个点，效率太低。

本地工具方案虽然前期配置花十分钟，但后续每一次使用都是直接、快速、可控的，长期来看时间成本反而最低。

3. 环境搭建：从零开始的完整步骤

3.1 安装核心引擎与依赖

不同操作系统的安装方式略有差异，我分别说明。先确认你的系统里有没有 Python 环境，yt-dlp 本质是一个 Python 程序，虽然官方也提供独立可执行文件，但有 Python 环境会更方便后续更新。

Windows 用户：推荐直接用官方提供的独立 exe 文件，下载后放到一个固定目录，比如D:\tools\yt-dlp\，然后把这个目录加入系统环境变量 PATH。ffmpeg 同理，下载完整包后把bin目录加入 PATH。验证方法是打开命令提示符，输入yt-dlp --version和ffmpeg -version，能输出版本号就说明配置成功。

macOS 用户：如果装了 Homebrew，两条命令搞定：brew install yt-dlp和brew install ffmpeg。Homebrew 会自动处理依赖和 PATH，最省心。

Linux 用户：大多数发行版的仓库里都有，但版本可能偏旧。我建议用 pip 安装最新版：python3 -m pip install -U yt-dlp。ffmpeg 用系统包管理器安装即可。

注意：安装完 ffmpeg 后一定要重启终端，让 PATH 生效。我见过不少人装完直接运行命令报“ffmpeg not found”，其实就是终端没刷新环境变量。

3.2 配置文件的关键参数解读

配置文件的位置有讲究。Windows 下放在%APPDATA%\yt-dlp\config.txt，macOS 和 Linux 放在~/.config/yt-dlp/config。如果目录不存在就手动创建。这个文件里每一行是一个参数，不需要写--前缀（但写了也能识别）。

我的配置文件核心内容如下，逐条解释为什么这么设：

# 输出路径模板：按UP主/标题分类，避免文件堆在一起 -o "~/Downloads/%(uploader)s/%(title)s.%(ext)s" # 默认画质偏好：优先选1080p，如果不存在则选最接近的 -f "bv*[height<=1080]+ba/b[height<=1080]" # 合并容器格式：mp4兼容性最好 --merge-output-format mp4 # 并发分片数：提高下载速度，但别设太高以免被限流 -N 8 # 重试次数：网络波动时自动重试 --retries 10 # 断点续传：大文件下载中断后不用重来 --continue # 嵌入字幕和元数据 --embed-subs --embed-metadata # 下载归档：记录已下载的视频ID --download-archive ~/.config/yt-dlp/archive.txt

这里重点说三个参数。输出路径模板里的%(uploader)s和%(title)s是变量，会自动替换成实际值。我习惯按 UP 主建文件夹，这样找起来方便。画质选择表达式里的bv*表示最佳视频流，ba表示最佳音频流，+表示合并。[height<=1080]是筛选条件，防止下载 4K 导致文件过大。并发分片数设 8 是我实测下来速度和稳定性的平衡点，设太高反而容易触发平台的限流机制。

3.3 验证安装是否成功

配置完成后，找一个短视频链接做测试。在终端输入：

yt-dlp -F "视频链接"

这个命令会列出该链接所有可用的格式，包括分辨率、编码、文件大小等信息。如果能看到格式列表，说明解析正常。然后执行实际下载：

yt-dlp "视频链接"

观察输出日志，正常流程是：解析页面 → 选择格式 → 下载视频流 → 下载音频流 → 调用 ffmpeg 合并 → 输出最终文件。如果卡在某一步，后面的排错章节有对应解决方案。

4. 核心实操：视频、音频、批量任务的完整流程

4.1 下载单个视频并指定画质

虽然配置文件里设了默认画质，但有时候需要临时调整。比如某个视频我只想要 720p 省空间，或者某个视频有 4K 我想收藏。这时候用-f参数覆盖默认值。

先列出格式：

yt-dlp -F "视频链接"

输出会类似这样：

ID EXT RESOLUTION FPS | PROTO | SIZE 30080 mp4 1920x1080 30 | https | 150M video only 30032 mp4 1280x720 30 | https | 80M video only 30280 m4a audio only | https | 10M audio only

前面的数字 ID 就是格式代码。想下 1080p 视频加音频，就写：

yt-dlp -f "30080+30280" "视频链接"

如果想偷懒，用表达式让工具自动选：

yt-dlp -f "bv*[height=1080]+ba" "视频链接"

bv*表示最佳视频，ba表示最佳音频，height=1080是精确匹配 1080p。如果该分辨率不存在，命令会报错，这时候把=改成<=就能选最接近的。

实操心得：B站的 1080p 高码率视频有时候需要登录才能解析。如果发现格式列表里最高只有 480p，大概率是没带登录凭证。解决办法是用--cookies-from-browser参数读取浏览器已登录的 Cookie，具体用法在排错章节展开。

4.2 只提取音频的三种场景

有时候我们只需要音频，比如存一段讲座录音、一首背景音乐。yt-dlp 提供了很灵活的处理方式。

场景一：直接下载平台提供的音频流。有些平台本身就提供 m4a 音频格式，直接选它即可：

yt-dlp -f "ba" "视频链接"

这样下载的是原始音频流，没有经过二次转码，音质损失最小。

场景二：下载后转成 mp3。如果设备只支持 mp3，或者想要更通用的格式，用后处理参数：

yt-dlp -f "ba" --extract-audio --audio-format mp3 --audio-quality 0 "视频链接"

--audio-quality 0表示最高音质，ffmpeg 会用最高码率转码。注意这是有损转码，原始音频如果是 aac，转成 mp3 会再损失一次，所以除非必要，我一般保留 m4a 格式。

场景三：从已下载的视频里抽音频。如果视频已经下好了，不想重新下载，直接用 ffmpeg 提取：

ffmpeg -i "已下载的视频.mp4" -vn -acodec copy "输出音频.m4a"

-vn表示不要视频流，-acodec copy表示音频编码直接复制不转码，速度极快且无损。

4.3 批量下载合集的正确姿势

批量任务是这套方案真正拉开效率差距的地方。假设你要下载一个系列课程，有几十个链接。手动一个个下显然不现实。

方法一：从文件读取 URL 列表。新建一个文本文件urls.txt，每行一个链接，然后：

yt-dlp -a urls.txt

配合配置文件里的归档参数，已经下过的会自动跳过，中断后重新运行也只下没完成的。

方法二：直接下载整个合集页面。如果链接是一个合集或播放列表页面，yt-dlp 会自动识别并下载全部：

yt-dlp --yes-playlist "合集链接"

如果只想下其中几个，用--playlist-items指定序号：

yt-dlp --playlist-items 1-5,8,10 "合集链接"

方法三：限制下载速度避免被限流。批量下载时如果全速跑，很容易触发平台的流量控制，导致后续请求被拒绝。加一个限速参数：

yt-dlp -a urls.txt --limit-rate 2M

2M表示每秒最多 2MB，这个速度对单个视频来说不算慢，但能有效降低被限流的概率。我实测下来，限速后批量任务的成功率从七成提升到九成以上。

4.4 输出文件的组织与命名

下载下来的文件如果全堆在一个文件夹里，找起来很痛苦。配置文件里的输出模板就是解决这个问题的。除了前面提到的按 UP 主分类，还可以加入日期、视频 ID 等变量。

常用的模板变量：

• %(title)s：视频标题
• %(uploader)s：UP 主名称
• %(upload_date)s：上传日期，格式为 YYYYMMDD
• %(id)s：平台视频 ID
• %(ext)s：文件扩展名
• %(playlist)s：所属合集名称
• %(playlist_index)s：在合集里的序号

我自己的模板是：

-o "~/Downloads/%(uploader)s/%(playlist)s/%(playlist_index)02d - %(title)s.%(ext)s"

02d表示序号补零到两位，这样文件按名称排序时顺序正确。如果视频不属于任何合集，%(playlist)s会变成NA，也不会报错。

注意：Windows 系统对文件名里的某些字符有限制，比如:、?、*等。yt-dlp 默认会自动替换这些字符，但如果你自定义了模板，最好加上--restrict-filenames参数，把所有特殊字符都转成下划线，避免下载失败。

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

5.1 解析失败与格式缺失

问题表现：运行命令后提示 “Unable to extract” 或格式列表里只有低清选项。

排查思路：先确认 yt-dlp 是不是最新版。平台改版后，旧版提取器会失效。更新命令：

yt-dlp -U

如果是通过包管理器安装的，可能需要用对应的更新命令，比如brew upgrade yt-dlp或python3 -m pip install -U yt-dlp。

如果更新后仍然失败，大概率是登录凭证问题。B站的高清视频需要登录才能解析，解决办法是让 yt-dlp 读取浏览器的 Cookie：

yt-dlp --cookies-from-browser chrome "视频链接"

把chrome换成你实际使用的浏览器，支持 firefox、edge、safari 等。这个参数会从浏览器数据库里读取已登录的 Cookie，不需要手动导出。

避坑技巧：如果浏览器开了多个用户配置，可能需要指定配置文件路径。另外，某些浏览器在运行时会锁定 Cookie 数据库，导致读取失败。解决办法是先完全退出浏览器再运行命令。

5.2 下载中断与合并失败

问题表现：下载到一半卡住，或者视频和音频下载完了但合并报错。

排查思路：先检查 ffmpeg 是否在 PATH 里。运行ffmpeg -version，如果提示找不到命令，说明环境变量没配好。Windows 用户特别注意，下载 ffmpeg 后要把bin目录加入 PATH，而不是把 exe 文件单独拷出来。

如果 ffmpeg 正常，但合并仍然失败，可能是磁盘空间不足或文件权限问题。检查输出目录是否有写入权限，以及剩余空间是否大于视频体积的两倍（因为要同时保留视频流和音频流临时文件）。

断点续传：配置文件里已经加了--continue，大部分中断场景重新运行命令就能接着下。但如果临时文件损坏，可能需要加--no-continue强制重新下载。

5.3 批量任务中的限流与重试

批量下载最怕的就是下到一半被平台限流，后续请求全部返回错误。我的经验是做好三件事：

第一，控制并发。配置文件里的-N 8是单视频的分片并发数，批量任务时建议降到 4 甚至 2。分片并发太高，短时间内发出大量请求，很容易被识别为异常流量。

第二，加请求间隔。用--sleep-requests 1让每次请求之间间隔 1 秒，虽然整体速度慢一点，但稳定性大幅提升。如果是特别敏感的平台，可以设到 2 到 3 秒。

第三，开启重试和归档。--retries 10让失败请求自动重试，--download-archive记录已完成的视频 ID。这样即使中途中断，重新运行也只会处理未完成的部分，不会重复下载。

实操心得：我一般把批量任务放在晚上跑，限速 1M，并发 2，请求间隔 2 秒。虽然慢，但第二天早上起来基本都能下完，而且很少出现失败。追求速度反而容易触发风控，得不偿失。

5.4 音画不同步与转码问题

偶尔会遇到下载的视频音画不同步，尤其是从某些编码格式转封装后。这通常是因为视频流和音频流的时间戳基准不一致，ffmpeg 合并时没有正确对齐。

解决办法是加--ffmpeg-location指定 ffmpeg 路径（如果系统里有多个版本），并在合并参数里强制重新编码时间戳：

yt-dlp --postprocessor-args "ffmpeg:-async 1" "视频链接"

-async 1会让 ffmpeg 调整音频流的时间戳来匹配视频流。如果问题依然存在，可以尝试换一种容器格式，比如从 mp4 换成 mkv，mkv 对时间戳的容错性更好。

另一个常见问题是转码后文件体积暴涨。比如把 aac 音频转成 wav，体积可能翻十倍。如果不是必须，尽量用copy模式避免重新编码。

6. 进阶技巧：让下载效率再上一个台阶

6.1 用别名简化常用命令

如果你经常需要执行某些固定组合的命令，可以在终端里设置别名。比如我在.bashrc或.zshrc里加了这几条：

alias ytd='yt-dlp' alias ytd-a='yt-dlp -f ba -x --audio-format m4a' alias ytd-1080='yt-dlp -f "bv*[height<=1080]+ba"' alias ytd-list='yt-dlp -a urls.txt --limit-rate 2M --sleep-requests 1'

这样以后下音频就敲ytd-a 链接，下 1080p 就敲ytd-1080 链接，批量就敲ytd-list，效率提升明显。Windows 用户可以在 PowerShell 的 profile 文件里设置类似的函数。

6.2 定时检查更新与自动归档

yt-dlp 更新频繁，建议设置一个每周提醒。我是在日历里加了个 recurring 事件，每周一早上检查更新。更新命令很简单：

yt-dlp -U

如果是 pip 安装的，用python3 -m pip install -U yt-dlp。保持最新版能避免绝大多数解析失败问题。

归档文件也要定期清理。archive.txt会记录所有下载过的视频 ID，时间长了会变得很大。如果确认某些内容不再需要保留记录，可以手动编辑删除对应行。但注意删除后重新下载同一视频时，工具会认为它是新的，会再次下载。

6.3 字幕与弹幕的处理

B站的字幕和弹幕是分开的。字幕可以用--write-subs下载，弹幕则需要额外的工具转换。yt-dlp 支持下载弹幕 XML 文件：

yt-dlp --write-subs --sub-langs "zh-Hans" --write-auto-subs "视频链接"

下载下来的字幕是 srt 或 ass 格式，播放器可以直接加载。如果想把字幕嵌入视频文件，加--embed-subs参数，ffmpeg 会把字幕作为软字幕轨道封装进去，播放时可以开关。

弹幕 XML 文件可以用第三方工具转成 ass 字幕，然后在播放器里加载，就能实现类似在线观看的弹幕效果。不过这个流程稍微复杂，适合有折腾精神的用户。

6.4 存储规划与文件管理

下载多了之后，存储管理就成了问题。1080p 视频一小时大约 1 到 2 GB，如果批量下载课程，很容易占满硬盘。我的做法是：

• 分级存储：常看的放在 SSD，归档的放在机械硬盘或外置存储。
• 定期清理：每月检查一次下载目录，把看完的、不再需要的删掉。
• 统一命名：靠输出模板保证文件名规范，方便搜索和排序。
• 备份归档文件：archive.txt记录了下载历史，换电脑时拷过去就能避免重复下载。

如果下载量特别大，可以考虑用--max-filesize限制单文件体积，超过指定大小的自动跳过，避免无意中下载了超大文件占满空间。

7. 我踩过的几个典型坑

第一个坑是盲目追求最新版。有段时间我每次看到更新就升，结果某次新版本引入了一个 bug，导致合并功能异常。后来我改成稳定版策略：除非遇到解析失败，否则不主动升级。升级前也会先用一个短视频测试，确认没问题再批量使用。

第二个坑是并发数设太高。刚开始用的时候觉得-N 16肯定最快，结果下载速度没提升多少，反而频繁触发限流，批量任务失败率很高。后来降到 8，再降到 4，发现速度差别不大，但稳定性天差地别。现在的配置是单视频 8，批量 2，基本没再遇到限流问题。

第三个坑是忽略磁盘空间。有一次批量下载一个大型合集，下到一半磁盘满了，临时文件损坏，重新下载又因为归档记录不完整导致部分视频重复下载。从那以后我养成了下载前先看剩余空间的习惯，并且给下载目录单独分了一个区。

第四个坑是Cookie 读取失败。有次用--cookies-from-browser一直报错，折腾半天才发现是浏览器开了两个用户配置，默认读的是没有登录的那个。解决办法是用--cookies-from-browser chrome:Profile 1指定具体的配置文件路径。这个细节官方文档里写得不明显，但实际使用中很容易遇到。

这套方案到现在我用了大半年，累计下载了上千个视频和音频文件，整体成功率在九成以上。剩下的失败案例基本都能通过更新版本或调整 Cookie 解决。如果你也在找一套稳定、可控、可批量操作的本地下载方案，希望这些经验能帮你少走弯路。