用 yt-dlp 归档自己频道时，我踩到的三个坑

我在 2023 年底开始把自己频道的历史视频做本地归档，起因是有一个 2019 年的视频被平台判定为「不适合广告」，申诉没通过，我不想再赌第二次。环境是 macOS 14，yt-dlp 2024.04 版本，频道一共 180 多条视频，总时长大约 40 小时，最高 1080p。

第一步不是下载，而是先把元数据和视频清单落盘。直接 -f bestvideo+bestaudio 一把梭会让我没法判断哪些已经下过、哪些是重传过的版本。我的做法是先跑一遍只写信息：

yt-dlp --flat-playlist --dump-json \
  "https://www.youtube.com/@你的频道/videos" \
  > channel.jsonl

拿到 id、upload_date、duration、title 之后，我再用一个小脚本生成下载列表，文件名统一成 日期_id_标题，这样即使标题改了也能按 id 去重。下载命令本身：

yt-dlp -f "bv*[height<=1080]+ba/b[height<=1080]" \
  --merge-output-format mp4 \
  --write-subs --sub-langs "zh-Hans,en" \
  --write-info-json \
  -o "%(upload_date)s_%(id)s_%(title).80s.%(ext)s" \
  -a list.txt

这里第一个坑：--write-subs 只写「可用」字幕，自动生成的字幕要加 --write-auto-subs，而且自动字幕的 zh-Hans 经常根本不存在，只有 zh-Hans-orig 之类的变体。我一开始以为字幕丢了下游工具坏了，查了半天 --list-subs 才发现是语言代码对不上。

第二个坑是限速和 429。180 条视频如果并发开太高，中途会出现一批 HTTP Error 429，yt-dlp 会重试但重试次数用完后直接跳过，列表继续往下走，结果是「看起来跑完了，其实缺了十几条」。我后来的做法是加 --sleep-requests 1.5、--limit-rate 8M，并且把退出码和日志里的 ERROR 单独 grep 出来，第二天再补跑。代价是整体时间拉长到接近一天，但比事后对账省心。

第三个坑跟归档质量有关：--write-info-json 写的是「下载那一刻」的元数据，播放量、评论数是会变的。如果目的是做长期记录，最好每次跑都单独存一份带时间戳的 json，而不是覆盖。我现在的目录结构是 videos/ 放媒体，meta/2024-05-01/ 放当天抓的元数据，按日期分层。

边界也说清楚：这套流程只适合自己频道这种量级，几千条视频时 --flat-playlist 也会被分页卡住，需要自己处理 continuation；另外会员限定、直播回放、地区限制的内容，yt-dlp 拿到的格式列表可能和网页端不一致，别拿归档结果当「平台一定有这样的清晰度」的证据。

我现在比较纠结的是字幕：自动字幕在口音重的段落错得离谱，手工校对 40 小时不现实。你们归档时是只留原始字幕，还是会跑一遍 ASR 重新生成？