/youtube/live 默认 5 分钟缓存会快速耗尽 search.list 的 100 次/日配额
路由地址
/youtube/live/:username/:embed?
完整路由地址
/youtube/live/@GawrGura
相关文档
https://docs.rsshub.app/routes/youtube#youtube-live-username-embed
预期是什么?
配置有效的 YOUTUBE_KEY 后,/youtube/live 应当能够在默认缓存配置下持续获取频道的直播状态,而不会因为 RSS 阅读器正常轮询而在一天的大部分时间内耗尽 YouTube search.list 配额。 如果上游配额确实已经耗尽,也希望 RSSHub 能保留并返回明确的 quotaExceeded 错误,方便定位问题,而不是将上游错误转换成后续访问 undefined.data 时产生的 TypeError。 理想情况下,可以避免或显著减少每次缓存过期时对 search.list 的调用;至少也应在文档中说明该路由与 YouTube 默认 Search Queries 配额之间的限制。
实际发生了什么?
当前 master 中,/youtube/live 的 getLive() 会在缓存未命中时调用:
该结果使用默认 CACHE_EXPIRE=300,即缓存 5 分钟。 RSSHub 本身并不是每 5 分钟主动执行一次后台任务;但如果 RSS 阅读器持续请求该路由,那么每次缓存过期后的第一个请求都会产生一次新的 search.list 调用。单个频道理论上最多产生: 86400 / 300 = 288 次 search.list / 天 YouTube Data API 从 2026-06-01 起为 search.list 使用独立的 Search Queries 配额。默认额度为 100 次/天,每次 search.list 消耗 1 次 Search
Query: https://developers.google.com/youtube/v3/docs/search/list https://developers.google.com/youtube/v3/revision_history#june-01-2026 https://developers.google.com/youtube/v3/determine_quota_cost
因此,在一个频道持续以 5 分钟间隔访问的情况下: 第 100 次调用:约 8 小时 15 分 第 101 次调用:约 8 小时 20 分,开始超过每日配额 这还没有计算多个 /youtube/live 频道共同使用同一个 Google Cloud project 的情况。多个 API key 如果属于同一个 project,也不会增加该 project 的每日额度。 这个问题不要求频道当时真的存在直播,因为 search.list 在返回空结果时同样会消耗配额。配额通常在 Pacific Time 午夜重置。
另外,目前 Google API wrapper 会捕获错误并返回 undefined。因此上游的 HTTP 403 quotaExceeded 可能最终表现为类似下面的错误,而不是明确的配额错误: Cannot read properties of undefined (reading 'data')
这不是指 2026 年的新配额机制突然降低了原有的可调用次数。旧机制下 search.list 每次消耗 100 个通用 quota units,默认 10,000 units/day 实际上同样大约只能调用 100 次。核心问题是默认 5 分钟刷新周期一直与默认搜索配额不相容;现在独立的 Search Queries 指标使问题更加容易观察。
===========
作为不使用 search.list 的参考,我目前在 asmr-tg-backup 中采用以下方式: 使用 YouTube 官方频道 Atom feed 获取新出现的 video ID: https://www.youtube.com/feeds/videos.xml?channel_id=<UC...>
持久化去重,只对新发现或仍处于 active 状态的 ID 做增量 metadata probe,而不是每轮重新搜索整个频道。
dev 分支中的会员直播观察实验会比较 Atom feed、频道 /streams 页面和派生的 UUMO... playlist,并对新 ID 做浅层探测,同时设置退避和冷却: https://github.com/dreaifekks/asmr-tg-backup/blob/dev/docs/youtube-membership-dev.md#L1-L56
需要说明的是,UUMO... playlist、频道网页和 yt-dlp extractor 都不是 YouTube Data API 的稳定公开契约。这个实验也是默认关闭、匿名、仅元数据的观察器,不使用 cookies 或登录凭据,也不读取或下载会员内容。因此它只能作为“先发现 ID,再增量探测”的设计参考,不能直接作为 RSSHub 的稳定替代实现。
部署
自建
部署相关信息
OS:Linux, Docker: v28.0.4, Docker Compose: v2.34.0, Node: v24.18.0
额外信息
Google Cloud Console quota:
Queries per day: 10,000
Search Queries per day: 100
Search Queries per minute: 100
Expected upstream error after exhaustion:
HTTP 403
reason: quotaExceeded
这不是重复的 issue
- 我已经搜索了 现有 issue,以确保该错误尚未被报告。
Source: DIYgod/RSSHub