一张由Ilograph绘制的交互式架构图，把yt-dlp这个常被简单理解为"YouTube下载工具"的项目，拆成了初始化、提取、下载、后处理四层，顺带公开了一批过去只有维护者才清楚的细节：核心类YoutubeDL对应的文件约218KB，是全代码库里最大的单一文件；覆盖YouTube、Vimeo、TikTok等平台的站点提取器超过970个；而YouTube自己的提取逻辑里，专门为对抗反机器人挑战设了两个独立子包。
这几个数字放在一起，能推翻大多数人对它的想象——它不是一个写完就能用很久的脚本，而是一套需要持续投入工程资源、跟着YouTube反爬策略不断迭代的对抗系统。目前能核实这些细节的信源只有这张图本身，官方README能印证的是extractor/downloader/postprocessor三层架构和YoutubeDL的中枢地位，具体文件大小和提取器数量还没有第二个信源交叉验证过。
一张图，先把规模摆出来
这张图把yt-dlp从入口到落地的路径讲得很直白：命令行参数进来后，先由YoutubeDL挑选提取器、拿到格式列表和元数据，再按协议选下载器，最后交给后处理器链条完成转码、写元数据、合并音视频。三层职责分得很清楚，这也是它相比上游项目最大的结构性优势。
分支谱系：一次"弃坑—重启"的接力
原文只说yt-dlp是youtube-dl的"功能增强分支"，但真实路径多了一环：youtube-dl停滞后，中间还有过youtube-dlc这个短暂接棒者，如今也已不再活跃，yt-dlp才是从那之后真正接住维护工作的一支。
这种"弃坑—重启—再分叉"在开源维护接力里并不罕见，只是很少有项目把接力棒交到第三棒还能跑起来。yt-dlp能跑通，靠的是SponsorBlock去广告片段、浏览器cookie直接提取（--cookies-from-browser）这类实打实的功能迭代，社区口碑长期正面倾向它，也是维护活跃度差异的直接体现。
真正烧钱的不是下载，是猜YouTube的谜语
架构图里最能说明问题的，是YouTube提取器里专门设立的jsc/和pot/两个子包——它们唯一的任务，就是应对YouTube持续升级的反机器人挑战。
下载视频从来不难，难的是每次都要重新猜对YouTube这一版的谜面
InnerTube API返回的格式列表本身没有秘密，秘密在n参数和签名的解密算法上——它随着YouTube播放器的每次改版而变化，yt-dlp只能靠内置的纯Python JS解释器现场逆向。这不是一次性攻克的技术难题，而是一场只要对方还在更新就必须持续投入的拉锯。
- 结论.970+提取器和918行级别的核心类不是负担的证明，而是它至今仍是最可靠下载工具之一的原因。
- 风险.图中披露的具体文件大小和提取器数量只有单一信源，用来判断项目健康度时需要留一道核查空间。
对普通用户来说，这套系统能不能继续用，取决于维护者是否有足够精力跟上YouTube下一轮反爬升级；对依赖yt-dlp做视频归档或二次开发的下游项目，核心架构一旦维护跟不上，风险会直接传导过去。接下来最值得盯的，不是yt-dlp又加了什么新功能，而是YouTube的pot/挑战下一次升级时，这个由社区接力维护的项目还能不能按时交出反制方案。