我正在为一项副项目工作，它需要在 API 上提供 YouTube 文本。使用 FastAPI 作为后端，当然。认为难点是 API 设计和缓存，这就不足为奇了。

然而实际上，FastAPI 部分只花了整整一天时间。使用 Pydantic 模型生成的响应，异步端点，Redis 缓存层，完成。

然而实际上花费了两个星期的生命却是如何可靠地获取文本。

我开始使用 youtube-transcript-api Python 包。 在笔记本电脑上很棒。 部署到 VPS，持续了一天就开始接到 429（禁止）错误，最后无论 YouTube 都阻止了我的 IP。 好酷。

所以，然后我进入了兔洞。 利用代理的旋转，指数反弹，重试逻辑，使用无头浏览器作为备选。 我在那里基本上可以工作，但每隔几天都会有一个失败的尝试出现。

有些我意料之外的事实：

  • 时标实际上比我预期的更有价值。 我最初只想要原始文字，但是当你有每个段落的起始和终止时间时，你就能做一些事情，如将相应的视频片段与链接的搜索结果关联在一起。
  • 自动生成字幕很原始。 YouTube 的语音识别对技术术语不断混淆。 "Fastapi" 变成了 "Fast a p i" 这种类型的东西。
  • 边界情况极为庞大。 私有视频，年龄限制，不可用的字幕，期望的字幕语言不正确，区域锁定。 每一种情况都有不同的失败方式，YouTube 的错误响应并不有帮助。

实际上，API 端点本身简直如画：

响应 JSON 包含的文本段 + 时标

如果我再次开始这个项目，我将花费零时间试图自行构建提取层。 那才是最脆弱的地方，而不是 FastAPI 提供的外围包。

有人面临与 YouTube 数据问题一样的问题吗？ 我们都用什么方式处理可靠性一端呢？

编辑：感谢 DM， 这是我正在使用的api。