# Chronometrica 与 Apidojo Tweet Scraper：X 关键词和日期研究工具对比

如果你需要为每次关键词查询采集限量样本，且保存的查询详情能满足研究要求，可以选择 Chronometrica X Search Scraper。经文档核查的优势包括：包含起止日期的日历日期输入、实际生成的完整查询、行位置，以及每次查询的独立结果状态。如果你需要更丰富的作者、位置、媒体、最低互动量、语言或查询向导筛选条件，可以选择 Apidojo Tweet Scraper V2。[Chronometrica 文档](https://apify.com/chronometrica/x-search-scraper) · [Apidojo 文档](https://apify.com/apidojo/tweet-scraper)

选择工具前，先明确必须采集什么。采集少量帖子供审阅，与采集所有匹配帖子，需要不同的控制条件。两种需求可以使用相同的关键词和日期，但需要不同的证据来判断是否成功。

本文由 Chronometrica 发布，使用了于 2026年10月20日核查的公开产品资料。本文未开展实际的数据采集。推荐依据是文档中说明的输入和输出，不主张任何速度、成本、覆盖范围、准确性或可靠性优势。

Actor 是托管运行的采集程序。本次比较要回答的实用问题是：哪个 Actor 能提供所需的筛选条件和记录，让你能够验收指定日期范围内的关键词样本。

## 根据样本验收要求选择

一条公开的买家需求要求按关键词采集特定时段内的 X 数据。这说明买家需要按日期范围采集数据，但不能据此认定买家需要完整的历史档案，或需要精确统计所有匹配帖子。本文选择比较这两款产品，是我们的编辑决定。这条需求不是经过验证的产品基准测试。[公开买家需求](https://www.reddit.com/r/webscraping/comments/19bekjv/is_there_a_current_solution_to_scrap_tweets)

选择 Actor 前，先写一段简短的验收要求。例如：“每个关键词最多需要 10 条带日期的帖子，并保留足够的搜索上下文，以便检查每个样本。”这能为选择提供实用依据。你可以检查输入是否表达了需求，以及输出是否保留了相应证据。

| 决策要点 | Chronometrica X Search Scraper | Apidojo Tweet Scraper V2 |
| --- | --- | --- |
| 关键词和日期搜索 | 内置日历日期输入，包含起止日期 | 关键词搜索及起止时间控制 |
| 经核查的适用需求 | 需要明确查询记录和行位置的限量样本 | 需要更多明确筛选条件的搜索 |
| 相关控制条件 | 1–20 次查询；每次查询保存 1–1,000 行 | 高级语法；作者、媒体、位置、互动量、语言及查询向导筛选条件 |
| 选择规则 | 样本上限和查询记录满足研究要求时选择 | 需要用这些筛选条件界定样本时选择 |

此表汇总了已核查的公开文档。文档未提及某项功能，不代表该功能不存在。关键词和日期筛选是两者共有的功能。[Chronometrica 文档](https://apify.com/chronometrica/x-search-scraper) · [Apidojo 文档](https://apify.com/apidojo/tweet-scraper)

Apidojo 文档中的大规模采集政策不支持单条推文获取。这一限制不影响本文针对多结果搜索的选择。[Apidojo 文档](https://apify.com/apidojo/tweet-scraper)

Chronometrica 的主要限制是保存行数上限。如果你需要所有匹配帖子，而任意一次查询需要保存的行数超过 1,000 行，Chronometrica 就无法满足该要求。即使需求低于此上限，也仍需提供覆盖范围的证据。输入允许设置某个数量，并不能证明来源会返回所有匹配帖子。[Chronometrica 文档](https://apify.com/chronometrica/x-search-scraper)

## 为什么 Chronometrica 适合限量关键词样本

Chronometrica 为保存的行保留搜索上下文。`inputQuery` 记录用户提供的查询。`executedQuery` 记录实际生成的完整查询。`searchMode` 记录所选模式。`resultPosition` 记录某行在该次查询中的观测位置。这些字段能将保存的帖子与返回该帖子的搜索关联起来。[Chronometrica 文档](https://apify.com/chronometrica/x-search-scraper)

比较关键词时，这种关联很重要。两次查询可以使用相同的日期范围和行数上限，却返回不同数量的合格行。请分别保留这些结果状态。否则，合并导出后，可能无法看出哪次查询达到了上限，哪次返回的行数较少。

Chronometrica 文档还说明了按查询进行的 `OUTPUT` 统计，即每次查询报告的结果状态。请结合保存的行查看这些信息。行数据文件说明你采集到了什么。查询结果状态有助于判断采集是否满足要求。[Chronometrica 文档](https://apify.com/chronometrica/x-search-scraper)

请仅在上述上下文中使用 `resultPosition`。它是一次查询中的观测值，不是固定排名、质量分数，也不能证明帖子能代表该主题。保留它是为了审阅样本顺序。不要用它衡量帖子的重要性。[Chronometrica 文档](https://apify.com/chronometrica/x-search-scraper)

如果研究人员需要有限数量的帖子来阅读、标注或比较，这种方式很合适。这些记录有助于研究人员说明观测到了什么。但研究人员仍须判断，这些观测是否支持预定分析。

## 采集前明确日期范围

Chronometrica 接受可选的 `startTime` 和 `endTime` 输入，使用包含起止日期的日历日期。文档说明，其处理流程会添加可见的日期筛选条件，并再次检查返回帖子的日期。使用这类内置日期输入时，不要在同一请求中再添加 `since:` 或 `until:` 运算符。[Chronometrica 文档](https://apify.com/chronometrica/x-search-scraper)

包含起止日期，意味着请求范围涵盖指定的两个日历日期。但你仍须定义研究所用的时区。仅有日历日期，无法说明本地统计日具体包含哪些小时。

运行搜索前，先记录所用时区。必要时，将预定的起止边界转换为协调世界时（UTC）。UTC 是比较时间戳时通用的时间基准。请核对研究日期对应的转换结果。检查返回的帖子时，使用这些已核对的时间戳。

请一起保留请求的两部分信息：原始的、包含起止日期的日历日期范围，以及验收行数据时使用的精确时间戳范围。这样，其他读者既能理解输入，也能理解你如何判断某条帖子是否属于研究范围。

初次检查时，选择一种日期控制方式。如果内置日期输入能表达需求，就使用它。如果改用高级查询运算符，请先检查生成的查询，再验收结果。不要在未检查两种方式如何影响查询的情况下混用它们。

更完整的日期检查方法，请参阅[如何按关键词和日期搜索 X 帖子](/zh-Hans/articles/%E6%8C%89%E5%85%B3%E9%94%AE%E8%AF%8D%E5%92%8C%E6%97%A5%E6%9C%9F%E6%90%9C%E7%B4%A2-x-%E5%B8%96%E5%AD%90/)。本文解决的是产品选择问题：哪个 Actor 的筛选条件和输出记录适合你的采集要求。

## 准备一份便于检查的小规模输入

Chronometrica 文档支持 1–20 次查询，以及 `latest`、`top`、`photos` 和 `videos` 模式。每次查询可设置的保存行数上限为 1–1,000 行。请先设置较小的上限，以便逐行检查保存的数据。[Chronometrica 文档](https://apify.com/chronometrica/x-search-scraper)

以下输入请求为 1 个关键词保存最多 10 行数据，日期范围为 2026年1月。它使用内置日期输入和 `latest` 模式。

```json
{
  "queries": [
    "artificial intelligence"
  ],
  "searchMode": "latest",
  "maxItemsPerQuery": 10,
  "startTime": "2026-01-01",
  "endTime": "2026-01-31"
}
```

准备一份便于检查的小规模输入

这份输入已通过本地检查，检查依据是缓存的公开 JSON Schema。JSON Schema 用于定义允许的输入字段和值。提供的所有字段名均存在于该模式中。这只能确认输入结构有效，不能证明实时来源可用，也不保证返回 10 行。[Chronometrica 公开输入模式](https://apify.com/chronometrica/x-search-scraper)

公开的 [X Twitter Search API Dataset Task](https://apify.com/chronometrica/x-search-scraper/examples/x-twitter-search-api-dataset) 提供了一份起始预设。Task 是为 Actor 保存的输入预设。核查时，该页面返回了 HTTP 200，表示页面响应成功。这项检查没有确认其当前保存的输入。

每次运行前，请打开 Task 输入并应用预定设置。将示例关键词和日期替换为研究所需的值。首次检查时，保持较小的上限。上面的示例是输入示例，不是采集结果。

## 按 5 个步骤检查验收条件

使用以下步骤，判断所选 Actor 是否能产生可用的样本。

1. 写明采集要求。列出每次查询的关键词、日历日期、所用时区，以及可接受的样本量。说明你需要的是示例、限量的对比样本，还是所有匹配帖子。请在查看结果前完成这一步。定义行数据的验收条件，包括必需的作者、媒体或其他筛选条件。
2. 选择控制条件，并设置较小的上限。根据文档，选择筛选条件满足要求的 Actor。选择内置日期输入或高级查询运算符。检查 Chronometrica 时，可以从上面的小规模输入开始。使用任何日期控制组合时，先检查生成的查询，再验收结果。
3. 检查实际查询和帖子日期。阅读 `executedQuery`，并与 `inputQuery` 比较。确认生成的查询表达了预定的关键词和日期范围。对每一行合格数据，检查帖子的创建时间戳 `createdAt`。将其与已核对的时间戳范围比较，检查两个日历日期边界。[Chronometrica 文档](https://apify.com/chronometrica/x-search-scraper)
4. 查看每次查询的结果状态。将保存行数与请求上限及报告的结果状态比较。查询达到上限时，将其标记为已达上限。有证据支持时，将结果标记为部分结果。明确保留原因不明的数量缺口。未知值保持为未知，不要用零替代缺失数据。
5. 分别验收并导出每次查询的样本。保留 `resultPosition`，并记录观测时间，即采集样本的时间。它与帖子的创建时间不同。保留原始日期请求，以及有关已达上限或部分结果查询的备注。只有在能够说明请求内容、观测结果和适用限制后，才开始分析。

某次查询保存的行数较少，不一定意味着整个 X 上的匹配帖子较少。其结果状态只能作为这次采集的证据。如果无法表达某个必需的筛选条件，请先重新确定产品选择，再采集更大的样本。

验收检查还提供了明确的停止规则。当必需的控制条件有效，且保存的记录能支持预定用途时，你可以继续。如果其中任一检查不通过，仅扩大采集规模无法解决问题。

## 一个包含 2 个关键词的虚构决策示例

此示例为虚构内容。它不是 Actor 测试、实时数据集、买家原话，也不是实测成本结果。

一名研究人员希望采集 1月与 2 个关键词相关的帖子：“artificial intelligence”和“machine learning”。目的是收集示例，供人工审阅。研究人员接受每次查询最多保存 10 行，并在采集前记录所用时区。

不考虑其他限制时，请求的最大样本量为：

`2 queries × 10 rows per query = at most 20 saved rows`

在这个虚构结果中，第 1 次查询返回了 10 行带日期的合格数据。第 2 次查询在其公开来源不再提供结果前，返回了 6 行带日期的合格数据。研究人员保留了：

`10 + 6 = 16 observed rows`

研究人员还保留了 2 次查询各自的结果状态。第 1 次查询达到了上限。第 2 次在未达到上限时停止。合并行数据时，不能丢失这个区别。

对于这一需求，Chronometrica 是合适的选择。研究人员接受限量样本，并需要原始查询、生成的查询、行位置及独立的结果状态。这些记录使研究人员能够对照既定要求审查采集结果。[Chronometrica 文档](https://apify.com/chronometrica/x-search-scraper)

研究人员可以描述观测到的 16 行数据的内容，但不能据此断定第 1 个主题在整个 X 上出现得更频繁。行数上限和不同的查询结果状态，无法确定总体频率，即每个主题在全部帖子中出现的频率。

如果要求改为采集 1月的所有匹配帖子，研究人员必须单独评估这一新要求。小样本采集成功，不能证明采集完整。如果获取全部结果的需求超过 Chronometrica 的单次查询上限，这个 Actor 就无法满足要求。

## 将查询记录与帖子观测数据分开保存

使用一张查询控制表记录请求及其结果状态。这是你自己的研究记录，并非对 Actor 导出格式的描述。每次查询都应保留原始关键词文本、包含起止日期的日期请求、所用时区、所选模式、请求上限、保存行数和报告的结果状态。

单独保存帖子观测数据，并以 `postId` 和 `executedQuery` 为键。键是一组用于标识记录的值。保留每条帖子与实际生成并返回该帖子的查询之间的关联。

保留文档中列出的搜索上下文字段：`inputQuery`、`executedQuery`、`searchMode` 和 `resultPosition`。保留 `createdAt`，用于日期检查。将观测时间添加到研究记录中。[Chronometrica 文档](https://apify.com/chronometrica/x-search-scraper)

同一条帖子可能出现在多个查询样本中。出现这种情况时，请保留这些查询关联。它们说明帖子为什么进入各个样本。如果之后统计去重后的帖子数，请单独解释该计算，不要与保存的查询观测记录数混为一谈。

这种结构有助于避免一个常见错误：把所有导出行当作无需说明的单一总数。合并文件可能同时包含已达上限的样本、仅采集到部分结果的样本和重复帖子。查询记录让你能够先解释这些差异，再得出结论。

如果后续需要分析哪些词共同出现，请参阅 [X 帖子关键词共现分析](/zh-Hans/articles/%E7%BB%99%E5%AE%9Ax%E5%B8%96%E5%AD%90%E6%A0%B7%E6%9C%AC%E7%9A%84%E5%85%B3%E9%94%AE%E8%AF%8D%E5%85%B1%E7%8E%B0%E5%88%86%E6%9E%90/)。先确定哪些观测数据可用，再对这个明确界定的样本应用分析方法。

## 需要可供审阅的样本时，选择 Chronometrica

当 Chronometrica 的单次查询限量样本和明确的查询记录能满足研究要求时，可以选择它。它适合本文核查的需求：在指定日期范围内采集限量关键词样本，并保存足够的上下文，以便检查每次查询的结果。

从 [Chronometrica X Search Scraper](https://apify.com/chronometrica/x-search-scraper) 开始。扩大采集规模前，先应用上述输入和验收检查。选择时，始终考虑必需筛选条件所决定的工具切换条件，以及保存行数上限。最终的研究结论不得超出观测数据能够支持的范围。

## 来源和延伸阅读

- [Chronometrica X Search Scraper — 公开文档和输入模式；证据核查日期为 2026年10月20日，缓存构建版本为 0.1.30；支持本文所述的输入限制、包含起止日期的日期控制、搜索上下文字段，以及按查询进行的 OUTPUT 统计；示例已通过输入结构检查，本文未开展实际的数据采集](https://apify.com/chronometrica/x-search-scraper)
- [Apidojo Tweet Scraper V2 — 公开文档和输入模式；证据核查日期为 2026年10月20日，缓存构建版本为 0.0.1557；支持本文所述的搜索控制条件和单条推文政策；依据是文档证据，并非同等条件下的性能对比测试](https://apify.com/apidojo/tweet-scraper)
- [Chronometrica X Twitter Search API Dataset Task — 公开预设页面，核查日期为 2026年10月20日；返回 HTTP 200；页面可用不能确认当前保存的输入，也不能证明采集成功；运行前请检查并应用预定设置](https://apify.com/chronometrica/x-search-scraper/examples/x-twitter-search-api-dataset)
- [按关键词和时间段采集数据的公开需求 — 纳入了 2026年10月20日核查的证据；支持买家需要按日期范围采集数据这一判断；选择比较这两款产品是编辑决定，该需求不能证明完整历史覆盖、产品性能、成本或采集成功](https://www.reddit.com/r/webscraping/comments/19bekjv/is_there_a_current_solution_to_scrap_tweets)