加载失败
该讨论围绕 yt-dlp 新增对 YouTube 完整支持时对外部 JavaScript 运行时的依赖（为了解析或解码 YouTube 在客户端生成的签名/挑战）展开。评论细致讨论了实操命令与标志（例如 --remote-components ejs:github）、solver 源（yt-dlp/ejs 仓库）、以及可选的 JS 运行时（Deno、QuickJS、Node、Bun）的性能与沙箱安全权衡。更广泛的背景连带 YouTube 的反爬/反广告策略、可能的 DRM（如 Widevine）、设备 attestation（TPM/WEI）和平台封闭化风险，且讨论在工程实现、法律/托管风险与长期文化保存（archive）三条主线间交织。
多位用户报告 yt-dlp 在遇到 YouTube 的 JS 挑战时会在运行时下载 solver（日志例："[youtube] [jsc:deno] Downloading challenge solver lib script from https://github.com/yt-dlp/ejs/releases/..."），常见的调用示例包含 --remote-components ejs:github 和 --cookies-from-browser。社区提出多种实务变通：从包管理器安装（Arch/extra、AUR 的 yt-dlp-ejs）、从缓存复制 solver（~/.cache）、或用 make 目标打包预置组件以应对受限/白名单环境。还有具体问题被指出：例如在 IPv6-only 环境下对 GitHub 的下载会失败（需要 yt-dlp 改用 IPv4 或手动镜像），以及部分安装模式会自动一起安装 deno 和 solver，从而减轻手工准备的需求。
项目文档推荐 Deno，因为它能在默认配置下以受限权限运行（例如禁止文件系统或网络），并且支持通过 --remote-components ejs:npm 下载依赖；因此成为官方首选的外部 runtime。替代方案包括 QuickJS（纯 C、可移植，但基准显示通常比 V8 慢约 10–50x，样例测得 v8 ~0.25s 而 quickjs ~2.2s）、Bun（不提供权限限制，脚本有完整文件/网络访问）以及可作为不安全回退的 Node（可用 --js-runtimes node）。安全观点分歧明显：有人指出运行时层面的沙箱并不牢靠，建议在受限环境用 OS 级别沙箱或 VM（如 firecracker）来隔离，而不是只依赖 Deno 的权限机制。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
大量评论反映 YouTube 前端近来对非 Chromium 浏览器和拦截广告的用户越来越不友好：有报告称 Firefox + uBlock 会导致白屏、视频延迟启动或需要刷新才能播放，A/B 测试会弹出“关闭广告拦截器”的提示。还有人指出 YouTube 对 VPN 的打击非常激烈，需要循环多个服务器才能避免“sign in to confirm you're not a bot”的提示；即便是付费 Premium 用户，也有人感到非 Chrome 浏览器体验显著差。另一些技术细节被提出：AV1 优先导致不少设备回退到 CPU 解码，用户建议临时用 h264ify 强制 H.264 以恢复 GPU 硬件解码。
许多用户长期用 yt-dlp 做个人/专题归档（有用户自述保存数万视频），理由包括作者删片、地域或时限下架等不可控行为。纯下载只是第一步：评论里提到需要把封面/缩略图写入 ID3、用统一路径/模板组织文件（例如 -o '%(uploader)s/%(upload_date)s - %(title)s [%(id)s].%(ext)s'），以及用工具如 TubeArchivist 做索引、搜索与在线播放，才算完整的归档方案。社区也分享了同步到手机、用脚本补元数据甚至调用小型 LLM 辅助识别艺术家名字等实战经验，凸显出“存储容易、索引和重用难”的现实问题。
很多评论担心这类调整是通往更严格 DRM 和平台封闭化的前兆：Widevine 等 DRM 已被用于高分辨率流媒体，L1 级别依赖硬件密钥和设备 attestation，运营方可通过黑名单剔除被破解的设备。讨论指出，一旦把解密链条绑在受信任硬件（TPM、受控 GPU、HDCP）或平台级 attestation（如 WEI）上，普通工具和屏幕录制都会失效；即便还有模拟/模拟孔（analog hole）或 HDMI 采集，质量与便利性都会受限。反过来一些人认为这种完全封闭化在短期内成本与兼容性代价很高，但长期看存在逐步收紧的风险。
评论普遍对 yt-dlp 维护者表示赞赏，把他们比作在与平台抗争的“草根军队”，同时也强调维护工作主要靠志愿者、经费不足。历史上存在对类似项目的 DMCA 或下架尝试（有案例通过 EFF 的介入驳回），因此社区对法律与托管风险很敏感。维护者明确表示不愿以 Selenium/无头浏览器作为首选（把那看作“失败的承认”），更倾向于小巧的 JS solver 路线或统一的 remote-component 方案（如 yt-dlp-ejs / 打包预置），并呼吁更多捐助与工程投入。
部分评论把访问收紧归因于 AI 公司或爬虫大规模抓取 YouTube 作为训练数据，认为异常、大量的随机访问会逼得平台加严反爬/验证策略。也有反对意见指出就 Google 的规模而言，少数爬虫对其总体带宽是微不足道的，更多是平台想控制第三方对内容的访问和商业化路径，或者是为降低成本与防止滥用而采取的策略。讨论因此在“技术原因”和“商业/政策动机”之间展开，既有对滥用者的指责，也有对平台本身策略动机的怀疑。
yt-dlp: 一个功能丰富的命令行音/视频下载器，是 youtube-dl 的分支 (fork)，通过解析网站或模拟客户端协议来获取流媒体源并支持数千个站点。
Deno: 由 Node.js 创始人发起的 JavaScript/TypeScript 运行时，默认强调安全性（可限制文件系统、网络等权限），被 yt-dlp 推荐用于以受限权限执行外部 JS solver。
QuickJS: Fabrice Bellard 开发的轻量级、可嵌入的 JavaScript 引擎（纯 C 实现），便于移植但在基准测试中通常显著慢于 V8（Node/Deno 所用引擎）。
EJS (yt-dlp/ejs): yt-dlp 的 remote components 组件仓库，包含解 YouTube JS 签名/挑战用的 solver 脚本（例如 yt.solver.lib.min.js），可通过 --remote-components ejs:github 或 ejs:npm 拉取。
Widevine: Google 的 DRM 方案，用于加密流媒体与控制播放权限，存在不同安全级别（如 L1/L3），常涉及硬件密钥和设备 attestation，从而限制直接抓取原始码流。
HLS / DASH: 常见的分段自适应流媒体协议（HLS 为 Apple 推广，DASH 为 MPEG 标准），浏览器端通常需要 JS 层来处理分段请求、寻址与自适应码率切换。
TPM (Trusted Platform Module): 受信任平台模块，芯片级安全硬件，用于存储密钥并提供平台证明（attestation），在讨论绑定硬件的 DRM 或平台认证时常被提及。