MeTube：用浏览器管理 yt-dlp 下载任务的开源方案

它解决什么问题

下载 YouTube 视频或整张播放列表，通常意味着复制 URL 到某个在线服务，或者打开终端敲 yt-dlp 命令。前者有隐私和速度限制，后者对不熟悉命令行的人不友好。MeTube 把 yt-dlp 封装成一个自托管的网页服务，用户可以在浏览器里粘贴链接、选择格式、启动下载，然后关闭页面，任务在服务器后台继续。它面向的是那些需要在 NAS 或 VPS 上批量下载媒体，并希望有一个可视化界面来管理队列的人。订阅功能让它可以定期检查指定频道或播放列表的新内容，自动把新视频加入下载队列，这比手动逐个检查要省事得多。

工作机制：从网页到文件的路径

MeTube 本身不实现视频解析，它依赖 yt-dlp 作为后端引擎。用户在网页上提交 URL，MeTube 将请求转化为 yt-dlp 命令，并管理下载进程。仓库布局显示，它用 Python 编写，通过 Docker 镜像分发，默认监听 8081 端口。下载任务的状态保存在 STATE_DIR 指定的目录中，包括 queue.json、pending.json、completed.json 和 subscriptions.json 这几个文件。这意味着即使容器重启，队列和已完成记录也不会丢失。下载的临时文件默认放在 /downloads，但 README 建议将 TEMP_DIR 指向 SSD 或 RAM 文件系统以提升性能，同时提醒使用 RAM 文件系统会导致下载无法恢复。这个设计把下载过程拆成临时存储和最终存储两步，便于处理大文件或中断恢复。

部署：一条 Docker 命令起步

部署 MeTube 最直接的方式是 Docker。README 给出的命令是：docker run -d -p 8081:8081 -v /path/to/downloads:/downloads ghcr.io/alexta69/metube。镜像支持 amd64 和 arm64，适合常见的 NAS 或树莓派。Compose 文件同样简单，指定端口和挂载卷即可。所有配置通过环境变量传入，例如 PUID 和 PGID 控制运行用户，默认都是 1000，这解决了容器内文件权限与宿主机不一致的常见问题。UMASK 默认 022，这意味着创建的文件默认权限是 644，目录是 755。如果要调整下载并发数，设置 MAX_CONCURRENT_DOWNLOADS，默认是 3，超过这个数的任务会排队等待。这些变量覆盖了运行时、下载行为和存储路径，大部分情况下无需修改代码。

订阅：自动化检查的细节

订阅是 MeTube 区别于普通网页封装器的功能。用户订阅一个频道或播放列表后，MeTube 会定期检查新内容并自动加入下载队列。检查间隔由 SUBSCRIPTION_DEFAULT_CHECK_INTERVAL 控制，默认 60 分钟。每次检查最多获取的条目数由 SUBSCRIPTION_SCAN_PLAYLIST_END 限制，默认 50，按最新优先。为了防止状态文件无限膨胀，SUBSCRIPTION_MAX_SEEN_IDS 默认存储 50000 个视频 ID，超过后最旧的会被遗忘。这个上限意味着如果订阅的频道更新极快，超过 50000 条后，早期视频可能被重复下载。实际使用中，这个限制对大多数个人频道绰绰有余，但如果你订阅的是新闻机构或每日多更的频道，需要留意这个边界。

配置 yt-dlp 选项的三种途径

MeTube 允许通过 YTDL_OPTIONS 环境变量传入 JSON 对象，直接覆盖 yt-dlp 的行为。更灵活的方式是使用 YTDL_OPTIONS_FILE 指向一个 JSON 文件，该文件被监控，修改后自动重载，无需重启容器。第三种是 YTDL_OPTIONS_PRESETS，定义命名的选项集合，用户可以在下载界面中为每个任务选择预设。这个设计把高级用户的定制需求和普通用户的简单操作分开。例如，你可以预设一个“仅音频”选项，设置 format 为 bestaudio，然后在 UI 里一键选择。但要注意，这些选项会合并到 yt-dlp 命令中，如果预设里写了互相冲突的参数，可能会导致下载失败。README 没有提供错误处理的细节，所以调试时可能需要查看日志。

存储与目录的灵活性

MeTube 提供了细粒度的目录控制。DOWNLOAD_DIR 是默认下载位置，AUDIO_DOWNLOAD_DIR 可以单独指定音频文件的存放路径。CUSTOM_DIRS 默认开启，允许每个下载任务指定子目录，配合 CREATE_CUSTOM_DIRS 可以自动创建不存在的目录。CUSTOM_DIRS_EXCLUDE_REGEX 默认排除以点或 @ 开头的目录，避免在 UI 的下拉建议中显示隐藏目录。DEFAULT_FOLDER 可以预设一个常用目录，但用户仍可修改。DOWNLOAD_DIRS_INDEXABLE 如果设为 true，下载目录会暴露在 Web 服务器上，这意味着其他人可以直接访问已下载的文件，除非有额外的认证层。默认是 false，这是安全的选择。如果你希望下载的文件能通过 HTTP 直接访问，需要手动开启并确保网络环境可信。

限制与不适用场景

MeTube 的局限在于它完全依赖 yt-dlp。如果 yt-dlp 因为站点结构变化而失效，MeTube 本身无法修复，只能等待上游更新。另一个问题是并发下载默认只有 3，虽然可以调高，但每个下载都会占用磁盘 I/O 和带宽，在低配 NAS 上可能拖垮其他服务。TEMP_DIR 的配置也值得注意，如果设置为 tmpfs，下载中断后无法恢复，因为临时文件在内存中。此外，MeTube 没有内置用户认证，默认情况下任何能访问 8081 端口的人都可以提交下载任务。虽然可以通过反向代理加认证，但 README 没有提供官方方案。对于需要多用户隔离或细粒度权限控制的场景，MeTube 并不合适。

替代方案与差异

与 MeTube 类似的工具是 Tube Archivist，它也提供 YouTube 下载和订阅管理，但 Tube Archivist 更侧重于建立个人媒体库，包含元数据索引、搜索和播放功能，而 MeTube 只负责下载文件，不管理媒体库。另一个区别是 Tube Archivist 通常与 Elasticsearch 配合，资源占用更高，而 MeTube 的依赖更轻，只运行一个容器。如果你只需要把视频下载到磁盘，不关心后续的组织和播放，MeTube 更简单。如果需要完整的媒体管理体验，Tube Archivist 的功能更丰富，但部署和维护成本也更高。选择取决于你是把下载视为终点，还是视为一个更大工作流的一部分。

编辑结论

MeTube 适合需要从浏览器批量下载视频、管理订阅更新，并且愿意接受 Docker 部署方式的个人或小团队。它的核心价值在于把 yt-dlp 的命令行能力包装成可操作、可持久化的服务。不适合追求极致下载速度、需要细粒度控制每个任务或完全离线运行的用户，因为它的行为依赖 yt-dlp 的更新和网络可达性。部署前应确认 Docker 环境支持多架构镜像，并规划好下载目录和状态目录的存储位置。若需要同时下载多个大文件，务必根据磁盘 I/O 调整 MAX_CONCURRENT_DOWNLOADS 和 TEMP_DIR。先在一个临时目录试运行，验证权限和下载流程，再投入正式使用。MeTube 的维护成本较低，但需关注 yt-dlp 的更新节奏，因为站点解析逻辑变化会影响下载成功率。

官方来源

1. Official README
2. Project repository
3. Release notes