yt-dlp 收窄并弃用 Bun 支持：问题不在版本号，而在供应链和维护风险

yt-dlp 在 2026 年 5 月 20 日的 GitHub issue #16766 里，给 Bun 画了一条很窄的线：作为 ejs 兼容 JavaScript 运行时，只支持 Bun 1.2.11 到 1.3.14。

同时，这项支持被标记为 deprecated。

这句话容易被读错。deprecated 不是“已经移除”，也不是“今天开始不能用”。更准确的理解是：还能用，但不要再把它当成稳定长期方案来设计。

我更在意的不是版本号本身，而是 yt-dlp 为什么在这里踩刹车。它指向的不是普通兼容性小修，而是开源维护者对供应链安全和未来维护成本的提前止损。

yt-dlp 具体改了什么

公告给出的变化很直接：Bun 的最低支持版本从 1.0.31 提到 1.2.11；最高支持版本卡在 1.3.14。

这是一上一下两道闸门。

对开发者来说，最现实的动作有三个。

如果你的 yt-dlp/ejs 构建链路里用了 Bun，先把版本锁在 1.2.11–1.3.14。不要让 CI 自动滚到更新版本。

如果你还在 1.0.x 或 1.1.x，升级不是为了追新，而是为了避开 lockfile 和测试兼容问题。

如果团队正在评估把 Bun 放进这条链路，采购或迁移决策最好延后。至少等 yt-dlp/ejs 后续发布真正落地，再看 Bun 1.3.14 之后的版本能否重新通过测试和构建行为证明自己。

这里的重点是“支持矩阵变窄”。不是 yt-dlp 宣布和 Bun 分手，而是维护者把风险边界写清楚了。

为什么 lockfile 成了底线

公告里最硬的一条理由，是旧版 Bun 在构建 ejs 包时会忽略 lockfile。

lockfile 不是装饰。它把依赖解析结果固定下来，让同一套项目在不同机器、不同时间尽量拿到同样的包版本。

在 npm 生态里，这是一条基本防线。依赖包会更新，间接依赖会漂移，安装行为也可能被脚本影响。lockfile 解决不了所有供应链问题，但少了它，构建过程会更难复现，也更难审计。

yt-dlp 没有说 Bun 已经造成安全事故，也没有把任何 npm 攻击归因给 Bun。这个边界要守住。

它真正表达的是：如果一个运行时在构建 ejs 时绕开 lockfile，维护者就没法放心把它放进默认支持路径。

这和 Node.js、pnpm、Yarn 这些工具链长期强调 lockfile、完整性校验、可复现安装是同一类逻辑。快当然重要，开发体验也重要。但进入维护者的支持清单后，规则就变了。

维护者看的不是演示速度，而是出问题后能不能复现、能不能定位、能不能把责任边界讲清楚。

这也是这次调整和普通“最低版本升级”的区别。普通升级多半是为了新 API 或修 bug；这次最低版本线背后，是供应链控制能力。

更难的是 1.3.14 之后谁来背书

yt-dlp 把 Bun 1.3.14 设为上限，原因也写得很清楚：项目方认为 1.3.14 是原 Zig 代码库构建的最后版本。

公告还提到，Bun 最近用 Rust 并借助 Claude 进行了重写，并使用了类似 “vibe-coded” 的表述。

这句话很容易被放大，但不该被写成结论过头的指控。现有信息不能证明 Bun 1.3.14 之后存在安全漏洞，也不能证明 AI 辅助写代码必然不可靠。

目前只能看出一件事：yt-dlp 维护者不愿为 Bun 新路线承担兼容性和稳定性背书。

这很现实。

兼容一个 JavaScript 运行时，不只是“能跑”两个字。测试失败要排查，用户报错要复现，依赖解析行为变化要解释。出了问题，用户往往先找当前项目，而不是先去分清 yt-dlp、ejs、Bun 三者的责任边界。

可这三者本来就是不同项目。

Bun 要证明自己的新实现可靠，应该靠版本行为、测试结果和长期稳定性。yt-dlp 能做的，是决定自己愿意支持到哪里。量力而行，不丢人。

接下来最该看的也不是口水争论，而是三件具体事：

• 下一次 yt-dlp 和/或 ejs 发布时，是否按公告执行 Bun 1.2.11–1.3.14 的范围；
• EJS wiki 是否同步更新这条支持边界；
• Bun 1.3.14 之后的版本，能否用可复现构建和测试兼容重新进入维护者信任区。

回到开头那条线：Bun 没有被立即踢出门，但门已经变窄了。

这对使用者反而是有用的信息。它提醒你，别把“还能跑”误读成“适合长期押注”。在构建链路里，能跑只是起点，可控才是底线。