用 yt-dlp 只拉音频归档时，我修好了两处参数

频道里有一批只适合听的内容：访谈、播客式的长视频、直播回放。我打算只留音轨，用 128k 的 m4a 存着，这样 300 多条视频预计占几十 GB，比存完整视频省得多。环境是 Debian 12，yt-dlp 版本 2024 年下半年某个 release，Python 3.11，输出到一块外接盘。

第一次跑，我图省事，直接写了这么一行：

yt-dlp -x --audio-format m4a -o "%(id)s.%(ext)s" \
  --batch-file ids.txt

结果有两个问题：一是输出目录里混进了 .webm 和 .m4a 两份文件，二是偶尔有文件只有几百字节。第一个问题是因为 -x 默认会保留原始音频文件，需要显式加 -k 的反面，也就是 --no-keep-video 之外还要处理 --audio-format 的临时文件，最直接的是加上 --no-part 之外再确认 --paths 的落点。我最后用的是：

yt-dlp -x --audio-format m4a --audio-quality 0 \
  -o "%(upload_date)s-%(id)s.%(ext)s" \
  --download-archive done.txt \
  --sleep-requests 1 --limit-rate 2M \
  --batch-file ids.txt

第二个问题更隐蔽。几百字节的文件是直播回放里那些「正在直播中」的条目，yt-dlp 拿到的只是占位信息，实际音轨还没生成。我的处理是先过滤掉 live_status 不为 not_live 的条目，用 --match-filter "live_status != is_live"，隔几天再补跑一次。

为什么这么做：--download-archive 是断点续跑的唯一可靠依据，比拿文件名去比对稳；--sleep-requests 和 --limit-rate 是给频道后台和带宽留余量，代价是 300 条要跑一晚上，但比被限速或触发风控再回头查日志划算。

会失效的地方：--match-filter 对已下架或私有视频不生效，它们会直接报错中断 batch，得配合 --ignore-errors；upload_date 在首播内容上可能为空，文件名会变成 NA-xxx.m4a，我后来改成用 %(id)s 打头、日期放后面；外接盘是 exFAT，长文件名偶尔截断，这个只能靠 id 保证唯一。

你们归档纯音频时，是怎么处理直播回放这类「先有壳后有肉」的条目的？