# 如何为新发现的 Instagram 评论建立登记表

保存每条评论的稳定ID，以及你首次观察到它的时间。将每次后续导出文件中的ID与已保存的ID比较。只要某个ID尚未出现过，就将它加入评论登记表，即使它的发布时间早于上次检查。将发布时间、采集时间和首次观察时间分开保存。记录采集缺口，因为来源排序和结果数量限制可能导致部分评论未被采集到。这种方法可以找出你新发现的评论，但不能证明你已找到上次运行后发布的每一条评论。

登记表是一份已保存的列表，每个已知评论ID各占一条记录。导出文件是存放已采集记录的文件。本指南说明如何为已知的公开 Instagram 帖子和 Reels 建立这份登记表。Reel 是 Instagram 的一种视频格式。采集范围是顶层评论，也就是直接评论帖子本身的内容，不包括其他评论下的回复。

一位读者曾公开提问，能否只采集最新的评论，例如过去一小时内发布的评论。这个问题包含两种不同需求：查找发布时间较近的评论，以及查找现有登记表中缺少的记录。下面的方法解决第二种需求。一个公开问题不能证明有多少人存在这种需求。[读者提问，发布于2021年6月22日；检索于2026年8月11日；仅一个问题，未经核实的产品使用情况](https://www.reddit.com/r/webscraping/comments/o5yu4e/scraping_only_the_most_recent_comments_on_an/)。

## 1. 确定帖子和采集限制

先列出一份已知公开帖子的URL清单。URL就是网页地址。比较不同次运行时，请使用同一份清单，或记录清单的每次变更。一次运行是指采集程序使用一组输入执行一次。

采集前，请写明以下选择：

1. 列出要检查的公开帖子。
2. 选择检查间隔。
3. 说明你的用途能接受多长延迟或多大覆盖缺口。
4. 设置每篇帖子最多保存的评论数。
5. 选择评论排序方式。
6. 记录所有发布日期筛选条件。
7. 为每次采集分配一个标识，并将它与导出文件一起保存。

上限是你要求最多保存的记录数，并不保证一定返回这么多结果。采集间隔说明你计划何时再次检查，但不能证明两次检查之间的每条评论都会出现在结果中。

如果你的用途要求证明每条新评论都已采集到，这种方法无法提供该证明。它可以提供已观察到的评论记录，以及可见的采集限制。

Chronometrica 的 Instagram Comments Scraper 是一个 Actor，即托管运行的采集程序。已核查的公开接口约定说明了已知公开帖子的输入、顶层评论记录、日期筛选条件和每篇帖子的数量上限。文档未列出“自上次运行以来”或“仅新评论”的输入项。你需要通过自己的比较流程找出尚未出现过的ID。[Instagram Comments Scraper，核查于2026年10月25日；文档说明适用于公开数据采集，本指南未进行运行测试](https://apify.com/chronometrica/instagram-comments-scraper)。

本指南使用公开记录，不获取私密账户记录或仅账户所有者可见的报告。不要将登记表描述为完整的账户通知历史，或某位用户的完整 Instagram 评论历史。

## 2. 分别保存登记表和观察日志

保存两张表。表以行保存记录，以列保存各个命名字段的值。键是用于识别一条记录的值，也可以由多个值组合而成。

评论登记表使用 `commentId` 作为键。文档中的接口约定将此字段定义为顶层评论的稳定 Instagram ID。请将ID存为文本，以确保其中的字符完全不变。

观察日志记录你在哪些采集中见到了该ID。使用 `commentId` 与采集标识的组合作为键。这样，同一条评论可以出现在多次采集中，而不会被计为多条不同评论。

以下表格列出建议保存的字段。`first_seen_at` 和 `collection_ref` 等字段属于你自己的流程，并非 Actor 额外输出的字段。

| 登记表字段 | 保存内容 | 规则 |
| --- | --- | --- |
| `commentId` | 来源提供的稳定评论ID | 每个已知ID在登记表中只保留一条记录 |
| `postUrl` | 公开帖子的规范地址 | 保留来源中的值 |
| `postId` | 来源提供的帖子ID，如有 | 缺失值保持缺失 |
| `postShortCode` | 帖子地址中的短代码 | 核对帖子身份时使用 |
| `createdAt` | 来源提供的评论发布时间 | 与观察时间分开保存 |
| `first_seen_at` | 你的流程首次收录该ID的时间 | 只设置一次，重新处理时保持不变 |
| `first_seen_collection_ref` | 首次收录该ID的采集标识 | 保留与来源证据的关联 |
| `original_text` | 首次收录记录中的文本 | 不得在未说明的情况下替换 |

| 观察日志字段 | 保存内容 | 规则 |
| --- | --- | --- |
| `commentId` | 与登记表匹配的评论ID | 不要按文本内容匹配 |
| `collection_ref` | 本次采集的标识 | 导入同一导出文件时沿用此标识 |
| `collectedAt` | 该行中 Actor 记录的采集时间 | 不要替换为导入时间 |
| `text` | 本次采集返回的文本 | 保留带日期的各个版本 |
| `raw_export_ref` | 未经修改的导出文件的引用 | 确保可以追溯到来源行 |
| `text_change` | 你的比较结果 | 标记与上一次保存文本的差异 |

同时保留完整的原始导出文件。JSON是一种用于结构化记录的文本格式。保留原始JSON，有助于你在建表后核查各项值。

### 区分三种时间

`createdAt` 记录来源所述的评论发布时间。它可以是 null，表示无法获取。

`collectedAt` 记录 Actor 采集该评论的时间，采用UTC。UTC是通用的时间标准。请保留来源行中的这个时间。

`first_seen_at` 记录你的登记表首次收录该评论ID的时间。请在方法说明中写明这条规则。如果你今天导入一份较早的导出文件，其采集时间仍是之前的时间，而登记表首次收录该ID的时间是今天。除非按你声明的规则，这两个时间确实相同，否则不要让它们看起来相同。

已核查的输出文档还列出了作者信息、点赞数和回复数。回复数不是回复文本。请区分计数为零与计数无法获取。请区分 `ownerVerified` 为 false 与 null。作者ID缺失不代表作者ID为零，也不会使有效的评论ID失效。[公开构建版本0.1.21，核查于2026年10月25日；文档列有字段和null处理规则，并非当前运行结果](https://api.apify.com/v2/acts/chronometrica~instagram-comments-scraper/builds/default)。

这份登记表统计的是不同评论的数量，不是不同账户数或人数。如果你还需要一份经过核查的工作文件，[公开评论样本指南](/zh-Hans/articles/%E4%B8%BA%E8%AE%BA%E6%96%87%E5%AF%BC%E5%87%BA%E5%85%AC%E5%BC%80instagram%E8%AF%84%E8%AE%BA%E5%88%B0excel/)介绍了另一套导出和导入流程。请将这项工作与判断某个ID是否为新发现的ID分开处理。

## 3. 使用小规模输入检查一篇帖子

先从一篇已知的公开帖子开始，将上限设为10条。使用所提供的输入：

```json
{"collectAllAvailable":false,"commentSortMode":"default","maxCommentsPerPost":10,"postUrls":["https://www.instagram.com/reel/DZu6dkVyImf/"]}
```

3. 使用小规模输入检查一篇帖子

将示例中的 Reel 地址替换为你要采集的公开帖子或 Reel 地址。请替换示例地址，不要将你的地址添加在它旁边。

`postUrls` 包含目标地址。`maxCommentsPerPost` 限制每篇帖子保存的不重复顶层评论数。`commentSortMode` 选择排序方式。值 `default` 保留 Instagram 的默认排序。`collectAllAvailable` 为 false 时，数量上限继续生效。

所提供的输入已通过静态结构校验。结构规范定义可接受的输入字段和值类型。这项检查确认的是输入格式。本指南未执行采集运行，此检查也不能确认当前是否可用。[公开输入约定，核查于2026年10月25日；仅进行静态校验，未执行付费运行](https://api.apify.com/v2/acts/chronometrica~instagram-comments-scraper/builds/default)。

自行运行后，请执行以下步骤：

1. 保存完整、准确的输入和采集标识。
2. 保留未经修改的导出文件。
3. 将返回的每个帖子地址和短代码与请求的帖子核对。
4. 对照原始记录核查评论ID、文本和时间。
5. 将无法确认评论身份或无法确认与目标帖子匹配的记录单独保存。
6. 将已确认可收录的ID加入初始登记表。

输出文档允许 `postId` 为 null。请核查现有的帖子地址和短代码，不要编造帖子ID。缺少 `commentId` 时，无法与登记表可靠匹配。请将该行保留为待解决记录，即收录前仍需审核的记录。文本相同不能弥补ID缺失。

将首次采集作为登记表的起点。其中的ID对这份登记表而言都是新发现的ID。但这些ID的出现不能证明评论是最近发布的。

## 4. 按ID比较下一份导出文件

对于每次后续采集，将已确认可收录的评论ID与本次更新前的登记表比较。

1. 如果登记表中没有该ID，新增一条评论记录。
2. 按你声明的首次收录规则设置其 `first_seen_at`。
3. 保留来源中的 `createdAt`，无法获取时也保留 null。
4. 添加观察记录，并附上采集标识和 `collectedAt`。
5. 如果该ID已存在，保留登记表中的记录，并添加新的观察记录。
6. 将其文本与上一次保存的文本比较。
7. 将发生变化的文本保存为另一个带日期的版本，并标记差异。

“新发现”指登记表之前不知道这个ID。“重复”指本次采集更新前，登记表已知道这个ID。这两个标签都不取决于评论的发布日期。

两条评论可以文字完全相同，但ID不同。请保留两条评论。同一个ID可以出现在多次采集中。请在登记表中保留一条记录，并保存多次观察的关联信息。

如果已知ID的文本出现差异，请保留以往报告中使用过的早期文本。比较只能确认已保存的记录之间存在差异，不能单凭这一点确认是谁改动了文本，也不能确认改动原因。

将更新结果与其采集标识关联保存。重新处理时，沿用该结果，不要把原先新增的ID再次报告为新发现。重新处理是指再次处理同一份已保存的导出文件。

指标历史使用不同的统计单位：一次已保存的计数读数。[Instagram 快照指南](/zh-Hans/articles/instagram-%E6%8C%87%E6%A0%87%E5%BF%AB%E7%85%A7%E5%AF%BC%E5%85%A5%E9%87%8D%E8%AF%95/)说明了这个独立问题。在本指南中，之后再次观察到同一条评论，只是为同一条评论增加了证据，并不会增加一条不同评论。

## 5. 演算延后发现的情况

以下演算示例为原创虚构内容，并非 Actor 输出、客户结果或测试结果。所有时间均为同一个虚构日期内的UTC时间。假设登记表在所述检查时间收录各份导出文件。

10:00，第一份有数量限制的导出文件包含C1和C2。这两个ID都加入了空登记表。

11:00，第二份导出文件包含C2和C3。来源给出的C3发布时间是09:30。它在首次检查前就已发布，但第一份导出文件没有包含它。

| 采集 | 导出的ID | 新发现的ID | 重复ID |
| --- | --- | --- | --- |
| 第一次，10:00 | C1, C2 | C1, C2 | 无 |
| 第二次，11:00 | C2, C3 | C3 | C2 |

登记表中的数量计算如下：

- 首次更新后：0条已知的不同评论 + 2条新评论 = 2条已知的不同评论。
- 第二次更新：2条已知的不同评论 + 1条新评论 = 3条已知的不同评论。
- 第二份导出文件：1个重复ID + 1个新发现的ID = 2个不同的导出ID。

登记表现已包含C1、C2和C3。这表示3条已知的不同评论，不表示3个人。

| 评论ID | 首次观察时间 | 本示例使用的发布时间 | 第二次采集的结果 |
| --- | --- | --- | --- |
| C1 | 10:00 | 未说明 | 未观察到 |
| C2 | 10:00 | 未说明 | 重复ID |
| C3 | 11:00 | 09:30 | 新发现的ID |

C3保留 `createdAt` 为09:30，`first_seen_at` 为11:00。不要将它描述为10:00之后发布的评论。C1和C2的“未说明”表示此虚构示例没有提供发布时间，并不表示午夜或零。

C1仍保留在登记表中。它未出现在第二份导出文件中，不能证明它被删除或受到内容审核处理。本示例没有确定它缺席的原因。

两次采集共有4条观察记录：2条观察记录 + 2条观察记录 = 4条观察记录。登记表中则有3条不同评论。这两个总数衡量的内容不同。

现在使用同一采集标识重新处理第二份导出文件。预期登记表结果如下：

- 3条已有的不同评论 + 0条新评论 = 3条已知的不同评论。
- 新增首次观察记录为0条。
- 对于相同的评论与采集组合键，新增观察记录为0条。

C3的首次观察时间仍是11:00。重新处理文件不会产生一次新的发现。

## 6. 使用日期筛选，并明确重叠区间

Actor 文档将 `commentsFrom` 和 `commentsUntil` 定义为评论日期筛选条件。它们不会按登记表中的首次观察时间筛选。[公开输入约定，核查于2026年10月25日；文档列有日期输入项，未列出“自上次运行以来”开关，也未进行运行测试](https://api.apify.com/v2/acts/chronometrica~instagram-comments-scraper/builds/default)。

如果使用日期筛选条件，请在不同采集时间窗口之间保留明确的重叠区间。重叠是指下一个日期窗口包含前一个窗口的一部分。请比较ID，防止这些重复记录在登记表中生成新条目。

根据你的用途选择并记录重叠区间。冻结的来源证据没有确定一种适用于所有情况的安全重叠时长。

虚构的C3说明了仍然存在的风险。如果后续请求排除10:00之前发布的评论，就会排除发布时间为09:30的C3。即使登记表从未见过这条评论，它仍然不会被发现。

重叠区间可以纳入较早发布的评论，但不能证明已经完整发现所有评论。所选窗口之外的评论仍可能不出现在结果中。

排序设置也有限制。`newest` 和 `oldest` 按日期对已采集的顶层评论样本排序。它们不能证明每条符合条件的评论都已进入样本。默认排序也不能证明采集按时间顺序进行。

将 `collectAllAvailable` 设为 true 会取消数量上限。根据文档，运行仍可能在公开数据流结束、时间耗尽或来源出现故障时停止。因此，取消上限不能证明已完整覆盖来源，还可能使费用大幅增加。检查登记表方法时，请继续保留数量限制。

## 7. 记录每篇请求帖子的缺口

为每次采集附上覆盖情况说明。覆盖范围是指已保存的结果能够支持说明的那部分请求来源。将请求的帖子清单与每份导出文件核对，也要检查没有产生任何可收录行的请求。

| 覆盖项目 | 记录内容 |
| --- | --- |
| 采集标识 | 所用的运行及未经修改的导出文件 |
| 请求的帖子 | 准确、完整的目标帖子清单 |
| 输入限制 | 数量上限、排序方式、日期筛选条件和结果限制设置 |
| 返回的记录 | 原始行和已确认可收录的不重复评论ID |
| 待解决记录 | 缺少身份标识，或尚未确认与目标帖子匹配 |
| 失败情况 | 已记录的采集失败情况及受影响的帖子 |
| 覆盖限制 | 已知的数量上限影响及其他缺失的背景信息 |

不要将未知状态当作成功结果。如果无法确认采集为何停止，请记录原因为未知。

请区分以下失败状态：

- 未返回任何行：该结果中没有观察到评论。这不能证明帖子有零条评论。
- 缺少评论身份标识：保留原始行以供审核。不要按文本或作者姓名匹配。
- 尚未确认与目标帖子匹配：在确认其目标帖子前，将该行保留为待解决记录。
- 已知达到数量上限：将上限报告为覆盖限制。不要将它当作帖子的评论总数。
- 已知ID在后续结果中缺席：保留登记表中的记录。不要断言评论被删除或受到内容审核处理。
- 时间无法获取：保持缺失状态。不要用发布时间或首次观察时间代替。
- 输入发生变更：记录变更。数量上限、排序方式或日期窗口不同，都会改变比较范围。

输出文档列有公开的点赞数和回复数。零表示已知数量为零。Null表示无法获取。回复数缺失或非零，都不提供回复文本。保留原始记录时，请保留这些含义。

## 8. 使用更新结果前先检查

每次采集分别提供四类结果：新发现的ID、重复ID、文本变化情况，以及尚未解决的覆盖问题。文本发生变化的ID也可能是重复ID。这些组别存在重叠，不要将它们作为互不重叠的评论数量相加。

仅在完成以下检查后接受本次更新：

1. 将每个已收录ID追溯到其来源帖子和原始导出文件。
2. 确认新ID在更新前不在登记表中。
3. 确认较早的发布时间保持不变。
4. 确认已知ID保留原来的首次观察时间。
5. 确认发生变化的文本保留了带日期的各个版本。
6. 使用同一采集标识重新处理同一导出文件。
7. 确认重新处理后，新增的不同评论数为零，新增首次观察记录数也为零。
8. 检查每篇请求的帖子是否都有结果或明确记录的缺口。

以上是对你自身流程的检查建议，并非为本文执行采集运行后得到的结果。

## 选择下一步采集操作

先从一篇已知的公开帖子开始，使用所提供的10条上限。使用 [Instagram Comments Scraper，核查于2026年10月25日；文档说明支持采集公开顶层评论，本指南未进行运行测试](https://apify.com/chronometrica/instagram-comments-scraper)。保留首次导出文件，按ID比较后续导出文件，并在扩大采集范围前重新处理该后续导出文件。

公开的 Export Instagram Comments to CSV Task 是一个已保存的输入预设。已核查的页面只能证明它已公开展示。我们未通过已登录的账户核查其保存的设置，也未运行该任务。使用前请检查其设置。

重新处理检查通过，且覆盖情况说明满足你已声明的需求后，再继续定期采集。如果剩余缺口无法接受，请调整采集范围，或寻找另行核实的数据源。报告结果时，应说明这些是在已记录限制范围内新发现的评论。

## 来源和延伸阅读

- [Instagram Comments Scraper 公开页面，接口约定核查于2026年10月25日；仅有文档说明的适用性，未执行付费运行，也未测量可靠性](https://apify.com/chronometrica/instagram-comments-scraper)
- [公开默认构建版本0.1.21，核查于2026年10月25日；静态输入与输出约定及README，无运行结果](https://api.apify.com/v2/acts/chronometrica~instagram-comments-scraper/builds/default)
- [Export Instagram Comments to CSV Task，核查于2026年10月25日；仅确认公开页面存在，未通过已登录账户核查保存的输入，也未运行该任务](https://apify.com/chronometrica/instagram-comments-scraper/examples/export-instagram-comments-to-csv)
- [关于采集最新评论的提问，发布于2021年6月22日；检索于2026年8月11日；仅一个公开问题，无需求量估计，也无经核实的产品使用情况](https://www.reddit.com/r/webscraping/comments/o5yu4e/scraping_only_the_most_recent_comments_on_an/)