小红书评论采集这件事，我最早的想法特别天真：把笔记链接丢给脚本，把评论一页页翻下来存进表格，不就完事了。跑完第一轮数据我还挺得意，直到朋友看了一眼表格问我，那篇笔记下面“共47条回复”的楼中楼呢？我打开数据一查，一条都没有。一级评论抓了一堆，真正在对话的二级回复全漏了，这不是我一个人的问题，是大多数人第一次碰评论接口都会踩的坑。
一级评论和二级回复，压根不是一回事
小红书评论区看着是一层，实际上是两层。你打开笔记看到的默认列表，是按热度排序的一级评论，每条评论下面如果还有讨论，会折叠成一个“展开更多回复”的入口，点进去才是二级评论，也就是楼中楼。
对应到接口侧，情况完全一样。大多数评论列表接口默认只返回最外层的评论，返回的数组里每条一级评论字段看起来挺齐全——评论ID、用户信息、点赞数、内容文本都有，很容易让人误以为“全部评论已经到手了”。但一级评论对象里通常带着一个 sub_comment_count 字段，它告诉你这条评论底下还挂了多少条回复。如果你拿到这个字段却不管它，数据里就永久缺了一块。实操里有个快速判断的方法：拿到一批数据后先算一下二级回复占一级评论的总比例，互动好的笔记这个占比通常在30%到60%之间，如果算出来是0，几乎可以断定调用方式漏掉了楼中楼层。
这里有一个地方需要说明一下。一级评论和二级回复的信息价值不一样。一级评论往往是情绪表态——“好看”“种草了”“踩雷了”，信息密度不高。真正的购买追问、产品细节、竞品对比，大多藏在二级回复里。用户在一条评论下问“敏感肌能用吗”，回复区才有人接“我用了没事，但我朋友泛红了”。只抓一级，你拿到的是散落的观点；把二级也拉回来，才拼得出完整的讨论树。
调用逻辑：先拿 comment_id，再往下钻
接口的设计逻辑很直白。一级评论和二级回复是两个独立的接口，不能指望一个接口全包。第一步传入笔记ID，调一级评论接口，返回评论内容、评论者昵称、头像、点赞数、时间戳，以及最关键的 comment_id。第二步把这个 comment_id 传给二级评论接口，才能拉出这条评论下的回复列表。maxhub 的接口文档也是这个结构，get_note_comments 负责一级评论，get_note_sub_comments 用 comment_id 取二级回复，两个端点各管一层。
小红书评论区最多开放两层，二级评论下面不会再挂更深的嵌套，所以不存在“三级评论”，遍历逻辑并不复杂：把每条一级评论当父节点，拉它的子节点挂上去就行。但真正花时间的地方不在逻辑，在翻页。
翻页和字段，两个最容易翻车的地方
游标不是页码。 我一开始习惯性写 cursor=2、cursor=3 去翻页，结果返回的数据永远停在第一页。小红书的接口用的是字符串游标，每次翻页必须拿上一次响应里返回的新游标接着传，不能自己拼数字。二级评论还多一层：一级评论对象里有 sub_comment_cursor 和 sub_comment_has_more，这两个字段专门控制楼中楼的翻页，和一级评论的游标是两套东西，不能混用。
另一个坑是 ID 的用途。一级评论和二级评论都有自己的 id，但请求二级回复列表时，传的参数是 top_comment_id，也就是一级评论的ID，拿二级评论自己的ID去调是拉不出东西的。字段层面，二级回复比一级多一个“被回复者”信息，能还原出“A回复了B”的对话关系，没有这个字段，一堆回复文本摆在一起你分不清谁在跟谁说话。
批量采集，别在接口细节上耗干耐心
单篇笔记的评论采集跑通之后，真正考验人的是批量。几十上百篇笔记，每篇都要走“一级翻页→取comment_id→二级翻页”的链路，游标、频率、报错处理全得自己兜。更麻烦的是，小红书并没有像淘宝京东那样完全向个人开发者开放评论接口，合规路径通常是企业级合作、白名单接入或者第三方封装服务。自己从零搭一套稳定的采集链路，技术联调的时间成本比想象中高。
极致了数据在小红书这块覆盖了21个接口方向，评论是其中一块独立能力。它的设计思路和上面说的一致：一级评论和二级回复各有独立接口，但调用上做了简化——传入笔记ID，系统自动采集一级评论并递归抓取每条评论下的二级回复，返回的JSON天然带层级关系，每条一级评论下面挂着它对应的回复列表，不用你再做二次关联匹配。一级评论返回 comment_id 和 sub_comment_count，二级回复返回回复内容、回复者与被回复者信息、点赞数、时间戳，讨论树的父子关系在数据里直接成立。分页逻辑接口自己处理，热门笔记几百上千条评论不需要手动拼接。
接入方式按手里的牌选就行。有技术团队直接对接API，注册拿密钥，传笔记ID和 comment_id，返回结构化JSON，联调一两天能跑通，之后配个定时任务每天拉增量。不想写代码的用飞书「多平台数据采集助手」插件，选小红书平台，输入笔记链接，勾选评论字段，数据自动写进多维表格，定时更新也能设。完全不想碰技术的，联系客服定制数据服务，告诉对方监控哪些笔记、什么频率、什么格式，直接交付数据表。具体字段和调用细节可以到 https://www.jzl.com 看，或者找他们客服问。
合规这条线，别等出事再补
评论数据涉及用户生成的UGC内容，合规边界得提前想清楚。第三方采集接口不是小红书官方开放API，平台用户协议明确禁止未经授权批量爬取用户评论，商业场景大规模采集存在账号限流封禁的风险。比较稳妥的做法是划三条线：公开可见的评论内容可以采，登录态下与本账号经营直接相关的数据要授权留痕，涉及个人信息的部分做脱敏处理，用户ID不能原样往外抛。数据拉回来是给自己做分析用的，别转手公开或写入未授权的数据库，这是底线。
总结
小红书评论采集的核心就一句话：一级和二级是两套接口、两套游标，二级回复必须拿一级评论的 comment_id 单独往下钻。先拉一级评论，检查 sub_comment_count 判断有没有漏，再用 comment_id 调二级接口，游标老老实实跟着响应走，别自己拼页码。单篇跑通之后，批量场景可以考虑用封装好的接口省掉翻页和递归的重复劳动，极致了数据这边21个接口方向覆盖评论采集，API、飞书插件、客服定制三条路按团队情况挑。最后别忘了合规边界，公开信息、授权留痕、个人信息脱敏，这三件事做在前面，后面的数据才用得踏实。
