# 按最热门或最新顺序抽取 YouTube 评论样本

使用 Top（最热门）获取按来源端排序的精选评论，使用 Newest（最新）获取按来源端近期顺序排列的评论，也可以同时使用两种排序，扩大有明确范围限制的样本。保留每个样本的排序标签及其限制。这些列表都由来源端选定。两者都不是随机样本，也都不代表每一位观众的意见。

“最热门”指来源端在 Top 排名中列出的评论。这是来源端的排名，不是观看量指标，也不是经过认证的相关性评分或互动评分。“最新”指来源端的近期排序。仅凭这一顺序，无法确定评论发布至今的准确时长。

Actor 是托管运行的数据采集程序。Actor 负责采集公开记录，分析由你完成。Task 是保存好的输入预设。公开 Task 只是初始输入，并不意味着分析会自动运行。

本方法说明来源端排序如何改变研究样本。它不标记垃圾评论，不梳理回复树，不将未获回答的问题加入待处理队列，也不对课程评论评分。本方法不涵盖直播聊天消息。

## 先写下研究问题

步骤 1. 先写下分析问题，再选择排序方式。

如果问题关注按来源端排序的精选评论，就使用“最热门”。如果问题关注来源端近期排序中的评论，就使用“最新”。如果两个问题都重要，就将样本分成 2 层。层是样本中预先声明的一部分。这里按检索顺序分层。

排序方式决定哪些评论进入样本。选择与研究问题相符的排序方式。不要只因某种排序支持你预期的结论，就选择它。

步骤 2. 明确已知视频、观测时间、每种模式的上限，以及仅涵盖顶层评论的范围。

这里的上限是顶层评论数量上限，即 `maxCommentsPerVideo`。记录获取每个列表的具体时刻。来源端的排序日后可能改变。之后获取的列表不再是同一个样本。

比较“最热门”和“最新”时，应使用相同的上限。上限不同，会让主题占比难以比较。

关闭回复采集。回复是顶层评论下的评论。回复会改变你的计数单位。回复记录不计入顶层评论上限。本方法未测试回复。请在笔记中记录这一限制。

## 设置当前输入

这里使用的 [YouTube Comments Actor](https://apify.com/chronometrica/youtube-comments-scraper) 公开构建版本为 1.1.6。它接受以下范围内的输入。

- `startUrls` 接受 1 至 100 个已知公开视频的网址或视频 ID。
- `maxCommentsPerVideo` 接受 1 至 1,000 的整数。
- `commentSortMode` 接受 `top`、`newest` 或 `both`。
- `includeReplies` 可以开启或关闭。
- 开启回复采集时，`maxRepliesPerComment` 接受 1 至 100 的整数。

使用一个已知的公开视频。不要使用私享视频。此 Actor 不会替你搜索视频。

2026 年 10 月 13 日，[YouTube Audience Comment Research Task](https://apify.com/chronometrica/youtube-comments-scraper/examples/youtube-audience-comment-research) 保存了以下初始输入：

```json
{
  "startUrls": ["https://www.youtube.com/watch?v=dQw4w9WgXcQ"],
  "maxCommentsPerVideo": 250,
  "commentSortMode": "both",
  "includeReplies": true,
  "maxRepliesPerComment": 10
}
```

设置当前输入

该输入使用一个已知的歌曲视频，上限为 250，模式为 `both`，开启回复采集，每条评论最多采集 10 条回复。请将歌曲视频替换为你选定的一个已知公开视频。

首次试采集时，使用一个已知的公开视频。将 `maxCommentsPerVideo` 设为 2，将 `commentSortMode` 设为 `both`，将 `includeReplies` 设为 false。

在 `both` 模式下，两种排序共用这一个顶层评论数量上限。上限为 2，表示在“最热门”和“最新”之间分配这 2 个名额，并不是采集 2 条最热门记录，再加 2 条最新记录。文档还说明，`both` 在同一次运行中，对每个评论 ID 只保留 1 条记录。

之后进行明确的比较时，做法有所不同。分别运行一次，获取一个最热门列表和一个最新列表。为两次运行声明相同的上限，并让观测时间具有可比性。此时，每个上限分别适用于一次运行，不是 `both` 模式下的共享分配。

## 分别读取数据记录和运行摘要

数据集中保存的每条记录都是一条公开评论或回复。关闭回复采集后，每条记录应对应一条顶层评论。

| 字段 | 含义 |
| --- | --- |
| `videoId` | 视频的公开 ID |
| `videoUrl` | 视频的公开网址 |
| `commentId` | 评论的公开 ID |
| `sortMode` | 该条已保存记录中保留的排序标签 |
| `text` | 公开评论的文本 |
| `publishedTimeText` | 来源端提供的相对时间文字，如有 |
| `publishedAt` | 来源端提供的准确发布时间，如有 |
| `updatedAt` | 来源端提供的更新时间，如有 |
| `authorChannelId` | 评论作者的公开频道 ID |
| `status` | 该条记录的结果状态 |
| `scrapedAt` | Actor 保存该条记录的时间 |

`publishedAt` 可以为 null。null 表示值缺失，不表示 0。`publishedTimeText` 不是准确时间。`scrapedAt` 是采集时间。绝不能将 `scrapedAt` 复制为发布时间。

`parentCommentId`、`isReply` 和 `replyDepth` 也是数据契约中规定的字段。本方法仅处理顶层评论，不使用这些字段。

OUTPUT 运行摘要不是评论记录。从数据记录中读取评论文本，从 OUTPUT 中读取运行计数和停止原因。

| 摘要字段 | 读取的内容 |
| --- | --- |
| `inputsReceived` | 本次运行收到的输入 |
| `uniqueVideosPlanned` | 计划处理的去重后视频数量 |
| `duplicateVideosSkipped` | 已跳过的重复视频输入 |
| `videosAttempted` | 本次运行尝试处理的视频 |
| `videosWithRows` | 已写入数据记录的视频 |
| `commentsWritten` | 已写入的顶层评论记录数 |
| `repliesWritten` | 已写入的回复记录数 |
| `rowsWritten` | 已写入的全部记录数 |
| `statusCounts` | 按采集结果统计各视频或输入的数量，不统计数据集记录数。对照运行中，`ok` 的计数为 1，数据集记录数为 2。 |
| `stopReasonCounts` | 按停止原因统计的数量 |
| `failedInputDetails` | 处理失败或不可用的输入 |

一次经过核查的对照运行使用 `both` 处理了 `educationalvideo_uQrJ0TkZlc`。它保存了 2 条不重复的顶层评论记录，文本均非空。其中一条的 `sortMode` 与另一条的 `sortMode` 分别为 `top` 和 `newest`。两条记录的 `status` 均为 `ok`，`publishedAt` 均为 null。OUTPUT 报告 `commentsWritten` 为 2，`repliesWritten` 为 0。停止原因为 `requested_comment_limit_reached`。

这 2 条记录对应 2 个不同的评论 ID。此次运行表明，`both` 可以从该来源返回记录，并保留 `sortMode`。它不能证明样本是随机的，不能证明获取了全部评论，也不能确定评论发布至今的准确时长。它不能证明所有视频的排序行为都相同，也不能说明分别运行“最热门”和“最新”时的重合情况。此次运行未测试回复。`repliesWritten` 为 0 不构成回复测试。此次运行也未测试是否完整覆盖全部评论。

本文未使用该对照运行中的任何评论原文。回复总数或点赞数不能证明你已获取全部评论。处理失败或不可用的输入会出现在 OUTPUT 中。不要为这些输入编造评论记录。

## 先测试试采集，再选择导出方式

步骤 3. 用小规模的 `both` 试采集测试一个已知视频。

检查 `videoId` 和 `videoUrl` 是否与该视频一致。检查 `text` 是否非空。检查是否存在 `commentId` 和 `sortMode`。检查 OUTPUT 中的停止原因。达到共享上限时，预期的停止原因是 `requested_comment_limit_reached`。

如果 `publishedAt` 为 null，就将发布至今的时长保留为未知。不要填 0，也不要填采集时间。标为“最新”的 `sortMode` 记录的是该评论从最新排序中检索而来。只有来源端给出实际日期时，才能据此确定发布至今的时长。

步骤 4. 选择一次覆盖范围更广的导出，或 2 个独立列表。

如果你希望一次导出覆盖范围更广、但仍有明确范围限制的数据，并且会读取停止原因和计数，就使用 `both`。该导出结果仍是一个有明确范围限制的来源列表。

要明确比较“最热门”和“最新”，应分别运行一次。记录表是某种模式保存的原始列表，并附有该次输入和观测时间。运行一次，获取有明确范围限制的最热门记录表；再运行一次，获取有明确范围限制的最新记录表。两次运行使用相同的预先声明上限，并让观测时间具有可比性。

这些配对运行是你之后要做的工作。经过核查的对照运行只有一次，使用的是 `both`。不要将该对照运行报告为配对列表的重合结果。

步骤 5. 对每张记录表分别去重，再根据这些独立记录表构建并集。

去重是指对每个已核实的身份只计数一次。去重键由 `videoId` 加 `commentId` 组成，而不是评论文字。2 条评论即使文本相同，也可能有不同的 ID。

并集是出现在任一记录表中的、不重复的已核实 ID 的集合。交集是同时出现在两张记录表中的已核实 ID 的集合。将归属保留为 `{top}`、`{newest}` 或 `{top, newest}`。

只有 2 张独立记录表都包含同一个 ID 时，才能将其归属标为 `{top, newest}`。在单次 `both` 运行中，去重只保留 1 条记录和 1 个 `sortMode`。仅凭这 1 个标签，无法判断它是否还属于另一种排序。不要猜测。保留原始记录表，让归属始终可以核查。

如果 ID 缺失，就将其保留为未确定。不要把 ID 缺失的情况计为 0。不要凭记忆重建丢失的归属信息。

## 使用同一套编码规则，再比较集合

步骤 6. 在每一层中使用相同的编码规则。

编码规则是判断某个主题是否出现的书面标准。在标记记录之前，先写下规则。[对最热门和最新评论使用相同的判断标准](/zh-Hans/articles/%E6%A3%80%E6%9F%A5%E4%B8%A4%E4%BD%8Dreddit%E8%AF%84%E8%AE%BA%E7%BC%96%E7%A0%81%E5%91%98%E7%9A%84%E4%B8%80%E8%87%B4%E6%80%A7/)。将原始文本、来源上下文和标记一同保留。

计算任何比例之前，先核对以下 4 项。

- 计划输入：你预先声明的视频和模式。
- 未知 ID：无法确定的身份标识。这些身份应保留为未确定。
- 有效文本：可以进行编码的非空文本。
- 状态缺口：`status` 不为 `ok` 的记录，以及任何运行失败的模式。

分母是符合条件、可纳入比例计算的评论数量。只使用 ID 已知且文本有效的评论。单独报告未知情况的数量。未知不等于 0。

主题计数统计的是样本中的评论，不是人数。它不代表未发言观众的意见，也不是人口统计结果。

步骤 7. 根据各独立列表中的 ID 计算交集和并集。

先报告检索结果中的出现总次数，再报告去重后剩余的不同 ID 数量。这里的重合仅指这些有明确范围限制的列表在这些时间点的重合，不代表这些评论占该视频全部评论的比例。

如果某种模式运行失败，缺失的列表不能视为成功获取的空列表。不要将该模式记为 0 条评论。比较结果仍是未知。来源的可用性可能在不同运行之间发生变化。编码前，先读取 `failedInputDetails` 和 `stopReasonCounts`。

步骤 8. 写出与排序方式及研究问题相符的结论。

某个主题在最热门评论中很常见，可能反映了来源端排序后呈现的精选评论情况。这一结果来自来源端排名，不是观看次数，也不是经过认证的评分。某个主题在最新评论中很常见，可能反映了来源端最新排序中的近期活动。如果 `publishedAt` 为 null，这不能证明评论发布至今的准确时长。

一次观测不能证明某个主题有所增加，也不能证明它有所减少。保存抽样笔记、输入和停止原因。之后的读者应能重复你的抽样选择。

当采集受到限制时，一些读者需要一种有明确范围限制的方法来研究真人评论。[这篇公开帖子](https://www.reddit.com/r/youtube/comments/1qcpg66/youtube_limits_api_comment_analysis_my_bad/)描述了这一需求。本文未核实其中声称的数量限制。不要将该说法视为官方 API 当前的行为。此 Actor 使用不同的方法，不使用你的 YouTube API 密钥。如果你还使用官方 API，请自行查阅该 API 当前的官方一手文档。选择“最热门”或“最新”可以满足这种抽样需求，但不保证获取全部评论。

## 逐步分析一组虚构记录表

本节的记录表是虚构的，用于讲解计数。它不是 Actor 的运行结果，也不是那次包含 2 条记录的对照运行。这里不声称展示任何真实评论文本。

虚构的最热门记录表包含评论 ID A、B 和 C。虚构的最新记录表包含 B、D 和 E。这 5 个 ID 都有来源身份标识和可编码的文本。

| ID | 在最热门记录表中 | 在最新记录表中 | 归属 |
| --- | --- | --- | --- |
| A | 是 | 否 | `{top}` |
| B | 是 | 是 | `{top, newest}` |
| C | 是 | 否 | `{top}` |
| D | 否 | 是 | `{newest}` |
| E | 否 | 是 | `{newest}` |

检索结果中依次出现 A、B、C、B、D 和 E，共出现 6 次。不同的 ID 是 A、B、C、D 和 E，共有 5 条不同的评论。B 在每张记录表中各出现一次，因此 B 是重复出现的评论。在并集中只对 B 计数一次，并保留它的两种归属。重复出现不等于垃圾评论。本方法不判断评论是否为垃圾评论。

并集为 `{A, B, C, D, E}`。交集为 `{B}`。仅属于最热门列表的集合为 `{A, C}`。仅属于最新列表的集合为 `{D, E}`。

如果一次 `both` 导出在保存 B 时只保留了 `sortMode` 为 `top` 的标签，就无法证明 B 也属于最新列表。只有独立的记录表才能表明 B 同时出现在两者中。

计算任何主题占比之前，先核对这个虚构示例。

| 核查项 | 此虚构示例中的结果 | 对比例计算的影响 |
| --- | --- | --- |
| 计划输入 | 1 个视频，独立的最热门和最新记录表，上限相同 | 可以比较这 2 层 |
| 未知 ID | 无。A 至 E 均已知 | 没有将未确定的 ID 计为 0 |
| 有效文本 | 全部 5 条文本均可编码 | 全部 5 条均可计入分母 |
| 状态缺口 | 无。两种模式均未失败 | 两个列表均不是获取失败的列表 |

先确定编码规则。只有评论询问如何开始任务时，才标记为“设置问题”主题。对每个 ID 都使用相同的规则。在这个虚构示例中，只有 A、B 和 D 符合规则，C 和 E 不符合。

| 集合 | 符合规则的 ID | 计入分母的 ID | 比例 | 百分比 |
| --- | --- | --- | --- | --- |
| 最热门 | A, B | A, B, C | 2/3 | 66.7% |
| 最新 | B, D | B, D, E | 2/3 | 66.7% |
| 并集 | A, B, D | A, B, C, D, E | 3/5 | 60% |

这 2 层占比的平均值为 `(66.7 + 66.7) / 2`，等于 66.7%，并不等于并集中的占比 60%。并集只对重合的 B 计数一次。对各层百分比取平均，不能得到去重后并集中的占比。

在这个虚构示例中，两种排序的结果均为 66.7%。这一致性仅涉及这 5 条评论，不能证明全部观众中有 60% 存在设置问题。

陈述结论之前，先展示 ID、归属、编码规则和分母。这里能够得出的结论范围很窄。在这个虚构示例中，2 种有明确范围限制的排序样本中，主题占比相同；去重后，并集中符合该主题的评论为 5 条中的 3 条。

以下 2 项限制仍然适用。如果 `publishedAt` 为 null，B 的准确日期仍然未知。它属于最新列表这一事实不能提供该日期，`scrapedAt` 也不能提供。如果另一个视频的最新模式运行失败，就不能将该视频视为只有最热门评论的总体。比较结果将是未知。运行失败的模式不等于成功获取了空结果的模式。

## 下一步

选定 1 个分析问题，声明排序方式和上限，并在对结果进行编码之前，保留每种模式的记录表。打开 [YouTube Comments Actor](https://apify.com/chronometrica/youtube-comments-scraper) 和 [YouTube Audience Comment Research Task](https://apify.com/chronometrica/youtube-comments-scraper/examples/youtube-audience-comment-research)。将歌曲视频替换为一个已知的公开视频。试采集时，将共享的 `maxCommentsPerVideo` 设为 2，将 `commentSortMode` 设为 `both`，将 `includeReplies` 设为 false。

## 来源和延伸阅读

- [YouTube Comments Actor](https://apify.com/chronometrica/youtube-comments-scraper)
- [YouTube Audience Comment Research Task](https://apify.com/chronometrica/youtube-comments-scraper/examples/youtube-audience-comment-research)
- [关于评论分析采集限制的公开帖子](https://www.reddit.com/r/youtube/comments/1qcpg66/youtube_limits_api_comment_analysis_my_bad/)