TikTok评论采集这件事，我踩过最窝囊的一个跟头，是脚本跑完了、表格生成了、数据看着挺齐整，交上去之后被人指着一条视频问：“下面这三十多条回复呢？”我打开那条视频一看，一级评论确实都在，但每条评论底下挂着的对话一条都没抓到。没报错，没中断，采集“成功”了，但只拿到了半棵树。后来我才搞明白，TikTok的评论区和大多数平台一样，一级评论和二级回复压根是两套东西，用只拉一层的接口去覆盖全部数据，结果只能是看起来完整、实际上缺了一大块。
那个“评论数”把你骗了，它不全是评论
TikTok视频页显示的评论数，很多人默认就是一级评论的条数，翻页翻到 has_more 变成 0 就算齐了。这个理解是错的。据Scavio在2026年做的一组实测，他们拿九条视频把一级评论接口翻到底，返回了3458行，去重之后只剩2855条不重复的记录，而接口自己报的总数是5360——真正拿到手的只有53.3%。差的那一半，几乎全是回复。
这意味着什么？TikTok给你的那个总数，把楼中楼也算了进去，但一级评论接口本身翻不到楼中楼。它是一扇只通往一楼的走廊，二楼得另开一扇门。更隐蔽的是，分页游标并不是干净的指针，翻页过程中会反复递回已经见过的行，那组数据里重复率达到了17.4%，六百多行是重复写入的。如果你不先去重，拿行数当进度，会误以为自己采了64.5%，实际上比这还少。
这里有一个地方需要说明一下。缺得多不多，跟视频本身火不火关系不大，跟评论区聊得深不深关系最大。Scavio那组数据里，一级评论占比最低的两条视频只有46.4%和35.0%，恰好是回复活动最重的两条。反过来，一条没什么人接话的视频，只抓一层可能漏得不多。但做VOC或者舆情的人都知道，真正有信息量的追问、反驳、产品细节，恰恰都长在回复里。漏掉回复，等于把评论区里最有讨论价值的那一段整段切掉了。
一级和二级，是两个端点，两套参数
TikTok的评论接口设计得很直白，但也正因为直白，很多人第一次对接的时候会以为“一个接口应该能搞定所有事”。实际上 video/comments 和 video/comments/replies 是两个独立的端点，后者需要把前者的 cid 传进去才能拉出楼中楼。Apify的TikTok评论Actor也是这个逻辑，一级评论和回复分开采集，includeReplies 打开之后，每个父评论的回复单独拉取，repliesPerComment 控制拉多少条，和顶层的 commentsPerVideo 是两个互不干扰的配额。
回复接口里有两个字段很关键：parent_id 和 root_id。parent_id 指向它直接回复的那条评论，一级评论的这个字段是 null；root_id 指向它所在的整个回复串的根，也就是最初那条一级评论。没有这两个字段，你手里只是一堆散落的回复文本，分不清谁在跟谁说话。Chromebook的评论导出工具和八爪鱼的处理方式也印证了这一点：用「根评论编号」和「父评论编号」来还原层级，谁回复了谁才一目了然。
游标别自己拼，回复的翻页是另一套
翻页是第二个把人坑得没脾气的地方。小红书的游标拼页码会失败，TikTok这边看起来像数字偏移量，但它本质上是服务端持有的状态，不是让你推算下一页的索引。第一页不要主动传 cursor，拿到响应里的 next_cursor 或 page.cursor 原样塞进下一次请求，has_more 为 0 就停，这才是安全写法。SocialToAI的文档还提了一嘴，cursor有有效期，大约三十分钟，翻页循环最好一口气跑完，别拆成隔天续传。
回复的翻页又多一层麻烦。Apify的文档写得很清楚，回复行是额外于父评论上限的，你把 repliesPerComment 调大，总行数会超出你对评论数的预期，预算和超时得跟着重新算。如果自己从零写采集链路，这些边界条件全得自己兜，技术联调的时间成本比想象中高。
批量场景，别在接口细节上把耐心耗干
单条视频跑通之后，真正的考验是几十上百条视频的批量采集。每条都要走“一级翻页→去重→取cid→回复翻页→再合并层级”的完整链路，游标、重复行、回复配额、频率限制全得处理。TikTok官方API对未授权数据访问的态度也很明确，AntsData的指南里写得很直白：TikTok官方API限制非常严格，而且私密账号和地区限制内容一律拿不到。合规边界摆在那里，大规模商业采集不是“技术能不能做到”的问题，是“这么做允不允许”的问题。
极致了数据在这类多平台评论采集上覆盖得比较直接。他们的API体系里，评论采集通常把一级评论和二级回复作为独立方向处理，传视频ID或链接进去，返回的结构里一级评论带着 reply_count 之类的字段，回复数据按层级挂载或单独返回，parent_id 和 root_id 这类还原对话关系的字段一并输出，不需要你自己去猜游标和去重逻辑。批量提交一批视频，多并发拉取，返回结构化JSON，配个定时任务就能持续跑。
接入方式按手里的牌选。有技术团队直接对接API，注册拿密钥，联调一两天能跑通；不想写代码的用飞书「多平台数据采集助手」插件，输入视频链接，勾选评论和回复字段，数据自动进多维表格，定时更新也能设；完全不想碰技术的，联系客服定制，告诉对方要采哪些视频、要不要楼中楼、什么频率，直接交付数据表。
合规这条线得单独拎出来说一句。TikTok的平台条款明确禁止在官方API之外进行自动化数据收集，Scavio那类第三方服务能跑通，靠的是公开页面读取，不碰登录态和私密内容。评论数据描述的是真实的人，可能包含未成年人，个人信息脱敏和最小必要原则不是可选项。采公开的、做内部分析用、用户ID处理干净，这三条守住，后面的数据才用得踏实。
总结
TikTok作品评论采集的核心就一句话：评论数不等于一级评论数，一级评论接口翻不到楼中楼，回复得拿 cid 去第二个端点单独拉。翻页游标原样传、别自己拼数字，翻完先按 cid 去重，再用 parent_id 和 root_id 把对话树拼回来。单条跑通之后，批量场景可以交给封装好的接口处理游标和递归，极致了数据这边覆盖评论与回复两个方向，API、飞书插件、客服定制三条路按团队情况挑。最后别忘了合规边界——公开内容、内部使用、个人信息脱敏，先想清楚再动手，比跑完再补要省事得多。
