不用爬虫也能监控 YouTube 播放列表：实战方案

很多团队在做内容库维护时，最怕的就是播放列表里的视频突然变成“私有”或者被删了，等发现的时候，视频标题和频道信息早就没了。这种场景如果靠写爬虫去刷页面，不仅不稳定，还容易被封 IP。

在公司内部落地这套监控逻辑时，我们发现最稳妥的办法是通过 API 做快照对比，而不是简单的数量统计。

一、建立基准快照
第一次扫描时必须记录完整的元数据，包括：

• 播放列表 ID、标题、所有者及隐私状态
• 每个条目的 playlistItemId 和 videoId（这两个 ID 含义不同，前者代表在列表中的位置，后者才是视频本身）
• 标题、频道、缩略图、添加日期及位置

二、处理分页抓取
调用 playlistItems.list 时，绝对不能只读第一页。必须写一个循环，直到 nextPageToken 为空为止，否则大列表的缺失视频很容易被漏掉。

三、对比维度与状态判定
不要只比对标题，因为标题会改。真正的监控逻辑应该是：

• 检查 ID 缺失： 之前的 videoId 在本次快照中找不到了
• 状态变更： 视频变成了私有、地区限制或年龄限制
• 位置漂移： 视频在列表中的顺序发生了变化
• 重复项： 同一个 videoId 出现了多次

三、关于“不可用”状态的细节
视频不可用 $\neq$ 视频被删除。在存储时，要把“实时可用性信号”和“历史元数据”分开存。这样当某个视频因为临时权限问题无法访问时，我们依然能通过快照知道它之前叫什么，而不是直接把它标记为永久删除。

四、避免通知疲劳
这是最容易踩坑的地方。如果一个视频消失了，每天扫描一次就发一次告警，同事们很快就会屏蔽通知。正确的做法是：同一个缺失项在未修复前，只更新其最后一次观察时间，将其视为同一个“事件”持续跟踪，而不是每次都触发新告警。

五、读写分离
监控流程必须是只读的。不要在监控脚本里直接写删除或替换逻辑，把“发现问题”和“修复问题”分成两个工作流。

一个简单的逻辑闭环是这样的：

{
  "scan_id": "20231027_001",
  "playlist_id": "PLxxxx",
  "timestamp": "2023-10-27T10:00:00Z",
  "items": [
    {
      "playlist_item_id": "item_123",
      "video_id": "vid_abc",
      "status": "available",
      "position": 1
    }
  ]
}

每次扫描后，将当前 JSON 与上一次的快照进行 Diff，只有差异项才进入告警队列。