4. 视频数据接口：视频列表获取、视频详情查询、视频评论数据、视频点赞数据

好，咱们直接进入正题。视频数据接口，说白了就是抖音生态里最核心的「内容抓手」。你想想看，用户刷抖音，刷的是什么？就是视频。所以，搞懂怎么拿视频列表、查详情、扒评论、抓点赞，这是基本功中的基本功。

我个人习惯把视频接口分成四层：列表层（知道有什么）、详情层（知道是什么）、互动层（知道大家怎么说）、行为层（知道大家怎么反应）。今天咱们一层一层剥开。

4.1 视频列表获取：从「刷到」到「拿到」

视频列表接口，通常是用户首页推荐流、关注页、或者某个话题聚合页的基础。抖音的推荐算法很复杂，但接口本身其实不复杂。

我遇到过不少新手，一上来就想着「我要爬全站视频」。嗯，这个想法很危险。抖音对列表接口的限流非常严格，尤其是未登录状态。你想想看，如果随便一个匿名请求就能拿到海量视频，那平台还怎么玩？

避坑指南： 我曾经因为并发太高，直接把一个测试账号的推荐接口给封了。后来发现，抖音对同一IP、同一设备ID的请求频率有隐式限制。建议每次请求间隔至少1-2秒，并且带上合理的User-Agent和设备指纹。

来看一个典型的视频列表请求结构（伪代码）：

// 视频列表请求示例
GET /api/recommend/feed?type=0&count=20&cursor=0
Headers:
  - Cookie: sessionid=xxx
  - User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 14_0)
  - X-Requested-With: XMLHttpRequest

Response:
{
  "status_code": 0,
  "cursor": 123456,
  "has_more": true,
  "items": [
    {
      "aweme_id": "7201234567890123456",
      "desc": "今天天气真好",
      "author": { ... },
      "statistics": { ... }
    }
  ]
}

注意那个 cursor 字段。它不是简单的页码，而是一个时间戳或偏移量。抖音用游标分页，而不是传统的 page/page_size。为什么？因为用户刷视频是连续的，游标能保证不重复、不遗漏。

小技巧： 我个人习惯把每次返回的 cursor 存下来，下次请求直接带上。如果 has_more 为 false，说明到底了。别傻乎乎地一直请求，浪费流量还可能被封。

4.2 视频详情查询：一条视频的「身份证」

拿到视频ID之后，下一步就是查详情。这个接口相对简单，但信息量巨大。一条视频的详情，包含了作者信息、音乐信息、话题标签、地理位置、甚至商品链接。

我记得有一次做竞品分析，需要统计某个垂类的视频平均时长。就是通过详情接口，把每个视频的 duration 字段拉下来，然后做聚合。嗯，数据量大了之后，记得用异步请求，别阻塞主线程。

// 视频详情请求
GET /api/aweme/detail?aweme_id=7201234567890123456

Response:
{
  "aweme_id": "7201234567890123456",
  "desc": "今天天气真好",
  "create_time": 1690000000,
  "duration": 15000,  // 毫秒
  "author": {
    "uid": "123456789",
    "nickname": "张三",
    "follower_count": 10000
  },
  "music": {
    "id": "987654321",
    "title": "热门BGM"
  },
  "statistics": {
    "play_count": 50000,
    "like_count": 3000,
    "comment_count": 200,
    "share_count": 150
  },
  "video": {
    "width": 720,
    "height": 1280,
    "play_addr": { "url_list": [...] }
  }
}

这里有个坑：play_addr 里的视频链接有时效性。你拿到链接后如果不及时处理，过几分钟就失效了。我曾经因为这个踩过坑，下载到一半链接过期，气得我直接写了个重试机制。

核心字段速查表：
字段含义用途
aweme_id视频唯一ID所有后续操作的凭证
create_time发布时间戳分析发布时间规律
duration视频时长(毫秒)内容长度分析
statistics统计数据用户画像核心指标
play_addr播放地址下载或转存

4.3 视频评论数据：用户真实声音的「金矿」

评论数据，是我个人认为最有价值的数据之一。为什么？因为点赞和播放只是「行为」，而评论是「态度」。一条评论里可能包含用户的情感倾向、消费意图、甚至是对产品的吐槽。

评论接口也是游标分页，但比视频列表复杂一点。它通常支持按热度排序和按时间排序。我建议做用户画像分析时，两种排序都拿。热评代表大众情绪，最新评论代表实时反馈。

// 评论列表请求
GET /api/aweme/comment/list?aweme_id=7201234567890123456&cursor=0&count=20&sort=hot

Response:
{
  "status_code": 0,
  "cursor": 500,
  "has_more": true,
  "comments": [
    {
      "cid": "1000001",
      "text": "这个视频太有意思了",
      "create_time": 1690000100,
      "user": {
        "uid": "2000001",
        "nickname": "李四"
      },
      "digg_count": 100,
      "reply_comment": null
    }
  ]
}

注意 reply_comment 字段。如果一条评论是回复别人的，这个字段会带上被回复的评论ID。做舆情分析时，这个字段可以用来构建「评论树」，分析对话的深度和走向。

避坑指南： 我曾经在抓评论时，发现有些评论的 text 字段是空的。后来排查发现，是抖音对敏感词做了「星号替换」。嗯，这个没办法，只能接受。另外，评论接口的限流比视频列表更严格，建议每次请求后 sleep 2-3秒。

4.4 视频点赞数据：最直接的「投票」

点赞数据，说白了就是用户用指尖投票。一条视频的点赞数，直接反映了它的受欢迎程度。但点赞数据接口，其实有两个维度：视频维度的点赞总数和用户维度的点赞列表。

视频维度的点赞总数，在详情接口的 statistics.like_count 里就能拿到。但如果你想看「谁点了赞」，那就需要另一个接口了。

// 视频点赞用户列表（部分平台支持）
GET /api/aweme/digg/list?aweme_id=7201234567890123456&cursor=0&count=20

Response:
{
  "status_code": 0,
  "cursor": 300,
  "has_more": true,
  "users": [
    {
      "uid": "3000001",
      "nickname": "王五",
      "avatar": "https://..."
    }
  ]
}

说实话，这个接口现在越来越难调了。抖音对「谁点了赞」这个信息保护得比较严。我建议你如果不是做特别精细的用户行为分析，直接用详情里的 like_count 就够了。

实战经验： 我个人在做用户画像时，会把点赞数据作为「兴趣权重」的输入。比如，一个用户点赞了10条美妆视频，那他的美妆兴趣标签权重就加10。点赞比评论更轻量，但样本量更大，适合做粗粒度的兴趣分类。

4.5 四个接口的协同使用策略

好了，四个接口都讲完了。但实际项目中，它们不是孤立的。我一般会这样搭配使用：

  1. 先拿列表：通过推荐或搜索接口，拿到一批视频ID。
  2. 再查详情：对每个视频ID，调详情接口，拿到完整的统计数据和元信息。
  3. 然后扒评论：对高互动视频（评论数>100），调评论接口，做情感分析。
  4. 最后看点赞：如果需要做用户兴趣分析，调点赞用户列表（如果接口可用）。

你想想看，这样一套组合拳下来，你不仅知道「什么视频火」，还知道「为什么火」、「谁在讨论」、「谁在支持」。这才是真正的用户画像数据基础。

嗯，今天就先到这里。下一章我会讲「用户数据接口」，包括粉丝列表、关注列表、个人信息等。到时候咱们再聊怎么把这些数据串起来，构建一个完整的用户画像模型。

← 上一章 📖 返回目录 下一章 →