小红书 API 怎么选：官方平台、开源脚本、按次付费

搜「小红书 api」的人多半想拿别人的公开笔记和评论，但小红书官方开放平台在 2026 年 11 月 4 日能给开发者的，只有账号登录（授权范围 basic_info，4 个字段）和自家店铺的订单、商品接口，「读取笔记」那一项在官方文档里还写着「规划中」（授权范围）。GitHub 上 9 个热门的小红书开源仓库，近 90 天新开的 92 条 issue 里有 31 条是登录失效、风控拦截或页面变化导致取不到数，另有 3 个仓库已经 5 个月以上没有新提交。按次付费的第三方接口是第三条路：我们在同一天用 EveryInfra 真调了 9 次，每次 $0.005556，搜索一页 20 条折合每千条 $0.278，评论每千条 $0.370，单篇笔记详情每千条 $5.56，空结果和参数写错都不扣钱；但它比我们目录里 TikTok、YouTube 的单价高 10 倍，量大时要靠少调来控成本。

本文比较的「三条路」是指拿到小红书数据的三种方式：一是小红书自己的开放平台（官方 API），二是 GitHub 上的开源脚本（自己登录、自己跑），三是按调用次数收费的第三方数据接口。前两条路我们只用公开材料：开放平台的官方文档、GitHub 仓库的公开数据和 issue；第三条路我们用 EveryInfra 自己的接口真调，花多少钱以响应里的 charged_usd 为准，条数以响应里实际返回的行数为准。本文不点名其他第三方服务，它们的价格请读者用本文「第三方服务怎么比价」一节的公式自己换算。

先看结论：三条路的差别在哪里

三条路不是同一件事的三个价位，而是能拿到的数据范围根本不同。官方开放平台是给「自己的东西」用的：你的 App 想让用户用小红书账号登录，你的店铺想把订单同步到 ERP，你的广告账户想批量拉报表。它不提供搜索别人笔记、读别人评论的接口。开源脚本能拿到网页上看得到的大部分内容，因为它本质上是用你的登录态去模拟一个浏览器，所以能拿多少、能稳定多久，取决于你的账号和小红书当周的页面。按次付费接口把这件事做成一个普通的 HTTP 请求，每次请求付一次钱，能拿到哪些数据、每页几条，以服务商公开的目录为准。

这张表里最容易被忽略的是第一行。很多人以为「先去申请官方 API，申请不到再找别的」，但目前官方的授权范围里，和公开内容相关的 user_profile、read_notes、read_followers 三项都还没有开放，即使申请成功，拿到的也只是登录用户自己的昵称和头像。下面按三条路分别展开，每一节都给出能核对的原文或实测数据。

小红书有官方 API 吗：四个官方入口，各自给什么

有，而且不止一个，但它们各管一摊。我们在 2026 年 11 月 4 日逐个打开了小红书公开的开发者入口，按「面向谁、要什么资质、能拿到什么」整理成下表。

第一个入口是 2026 年新上的「开发者门户」。首页写的是「通过标准 OAuth 2.0 协议为你的应用提供小红书账号登录能力」（开发者门户），快速接入文档说创建应用后要「等待审核（约 1-3 个工作日）」，并且明确写着「当前仅开放『用户基本信息』授权范围（basic_info）」（快速接入）。授权范围页列出了 5 个 scope，只有 basic_info 的状态是「已开放」，其余 4 个都是「规划中」；其中 write_notes 还注明「需要人工审核，仅特定场景开放」（授权范围）。API 参考页的 11 个接口全部围绕授权和 token：查询授权状态、换取和刷新 token、获取用户基本信息、解除授权、车机和网页扫码，页面最后更新于 2026 年 8 月 19 日，refresh_token 有效期 180 天（API 参考）。

第二个入口是做电商的人最熟悉的电商开放平台。开发者角色只有两种：「软件服务商」为小红书商家提供商品管理、订单管理、ERP 等软件服务，应用要上架到服务市场；「商家自研」只给自己的店铺用。入驻门槛写得很具体：服务商的认证主体必须是在中国大陆注册、成立 1 年以上、经营范围包含技术开发或技术服务的企业；商家自研的店铺类型不能是个人或个体工商户（开发者角色说明，开放平台文档镜像）。授权流程文档写明「只允许店铺主账号才可以授权成功」，授权码 10 分钟有效，accessToken 7 天、refreshToken 14 天（授权流程（软件服务商））。所有业务接口都走同一个网关地址，用 appId、timestamp、version、method 加 appSecret 做 MD5 签名（签名算法）。这条路能把你店铺里的订单、售后、库存接进自己的系统，但它的数据边界就是「授权给你的那家店」。

第三个是聚光 Marketing API，面向广告主。入门指南写的接入门槛是「有聚光投放账号，在小红书聚光平台具有一定投放经验的行业重点客户」，并且「具备成熟的 API 对接经验」；注册流程「由小红书销售内部发起审批」（聚光开放平台 Marketing API 入门指南）。它能拉的是你自己广告账户的数据报表和投放管理，不是自然流量的笔记。第四个是分享开放平台，原本给第三方 App 提供「一键分享」「快速发布」能力（分享开放平台）；2025 年 11 月就有开发者发帖说打开页面「没有登陆注册按钮，直接是暂停接入状态」（V2EX 帖子），我们 11 月 4 日打开时页面仍然没有注册入口。另外还有一个小程序开放平台，用于在小红书里开发和上线小程序（小程序开放平台），同样不涉及读取社区内容。

官方开放平台拿不到的，正是大多数人要的那部分

把四个入口叠在一起看，结论很清楚：小红书的官方接口是「对内」的，围绕你自己的账号、店铺和广告；四个入口的文档里，都没有面向第三方的「搜索全站笔记」「读取任意笔记的评论」「查看任意账号的公开主页」这类读取接口；授权范围页上和公开内容有关的 read_notes、read_followers 也还标着「规划中」。另外要知道，注册在中国境外的用户是 rednote 用户，适用另一份 rednote 服务条款，所以海外团队查「rednote api」得到的答案也一样：目前没有读取公开内容的官方接口。两份协议对自动化读取和商业使用各有什么限制，放在下文「合规要点」一节里讲。

所以「小红书 api 接口」这个搜索词背后，其实是两种完全不同的需求。如果你要做的是自有 App 登录、自有店铺对接、自有广告报表，官方入口是唯一正确的路，不需要往下看；如果你要做竞品监测、舆情分析、选品研究、内容趋势，官方入口目前给不了，剩下的选择只有开源脚本和第三方接口，而这两条路都要先想清楚合规边界（见下文「合规要点」）。还有一个常被问到的说法是「蒲公英有接口」。蒲公英是小红书的品牌和博主合作平台，V2EX 上有人说可以传 Cookie 调它的页面接口拿笔记和评论，但同一帖里另一位开发者实测说只能拿到精选的前几条评论，翻页参数不生效（V2EX 帖子），而且这同样是用自己账号的登录态在调页面接口，属于下一节说的「脚本」路线。

小红书 api github：9 个热门开源仓库的维护状况

开源脚本是很多人的第一选择，因为它免费、代码看得见。为了不凭印象说「开源脚本不稳定」，我们在 2026 年 11 月 4 日 00:19:50（新加坡时间）用 GitHub API 做了一次取样。取样规则是：在 GitHub 上分别搜 xiaohongshu、xhs spider、小红书 三个词，各取按星标排序的前 30 个仓库去重，再挑出主要功能是「从小红书取数据」的仓库（爬虫、请求封装、MCP 服务、命令行、采集下载），排除只做发布、生成图文或通用视频下载的。符合条件的 9 个仓库如下表；「近 90 天 issue」指 2026 年 8 月 6 日到 11 月 4 日新开的 issue，不含合并请求（GitHub 仓库 issue 接口文档）。

「失效类」是我们逐条读 issue 标题后人工归的类，分三种：登录、Cookie、扫码或会话失效（10 条）；验证、搜索受限或触发防御机制（3 条）；读取、解析或自动化流程因为页面或接口变化而失败、超时（18 条）。其余 61 条是功能建议、安装环境问题、安全公告、推广帖或标题看不出内容的，归为「其他」。按标题归类会有误差，比如标题只写「[问题]」的 3 条我们都算进了「其他」，所以 31 条是下限。

这组数说明的不是某个项目写得不好，恰恰相反，issue 多的往往是用的人多、维护勤的项目。xiaohongshu-mcp 近 30 天有 35 次提交，它的 37 条 issue 里有「无法登录」（#880，10 月 23 日）、「搜索被限制（但是 app 里面正常使用）」（#877，10 月 21 日），也有用户直接问「小红书官方允许吗？使用后会不会遇到笔记推流减少等问题」（#878，10 月 22 日）。XHS-Downloader 的 #497（10 月 17 日）记录了一次典型的页面变化：小红书网页里的服务端数据新增了一种写法，导致解析直接报错；同一仓库的 #479 是用户请求加「调整抓取速度和间隔的功能，避免触发小红书防御机制」。Spider_XHS 的 #191（10 月 10 日）标题就是「Cookie is invalid or expired」。

另一头是没人维护的仓库。ReaJason/xhs 是「基于小红书 Web 端进行的请求封装」，最后一次提交在 2025 年 7 月 1 日，到今天 490 天；xiaohongshu-cli 停在 2026 年 3 月 21 日。没有新 issue 不等于能用，更可能是用的人已经走了。对要长期跑任务的团队来说，选开源脚本前至少要看三件事：最后一次提交是什么时候，近一个月的 issue 里有没有「登录」「失效」「解析失败」，维护者多久回一次。

开源脚本的四个代价：登录态、签名、页面变化和许可证

第一个代价是登录态。热门脚本几乎都要你先登录小红书，把 Cookie 存下来再用。xiaohongshu-mcp 的说明里用加粗写着：小红书的同一个账号不允许在多个网页端登录，登录了这个服务后再去别的网页端登录，就会把它「踢出登录」；作者还提醒没实名的新号会触发实名认证（xiaohongshu-mcp 说明）。xiaohongshu-cli 的用户在 #82 里抱怨每 7 天被迫重新登录。登录态一失效，定时任务就停，而且你通常要到第二天看报表才发现。更麻烦的是账号本身：协议第 2.3 条写明账号「仅限您本人使用」，授权第三方使用账号「行为无效」，小红书判断有风险时可以封禁（用户服务协议）。用来跑脚本的账号，最好当作随时可能失去的东西。

第二个代价是请求签名。小红书网页接口的请求头里要带 x-s、x-s-common 等签名字段，有的接口还要额外的风控头。社区里有专门的仓库做这件事，比如 xhshow 的说明写它生成 x-s、x-s-common、x-rap-param 等请求头，「feed、搜索、笔记发布等接口需要额外的 x-rap-param 风控头」（Cloxl/xhshow）。MediaCrawler 换了一种做法：用 Playwright 浏览器保存登录态，在浏览器里执行 JS 拿签名参数，说明里写默认连接用户已有的 Chrome，以「大幅降低平台风控检测风险」（MediaCrawler 说明）。两种做法的共同点是：签名算法一改，所有依赖它的脚本同时失效，这正是上一节 18 条「解析或自动化失败」的来源之一。

第三个代价是平台拆分带来的变化。xiaohongshu-mcp 的 #579 记录了一件海外用户很在意的事：用非 +86 手机号在 2025 年 12 月 8 日之后注册的用户被归为 rednote 用户，网页会跳到 rednote.com，Cookie 的域名也不同，原来只认 xiaohongshu.com 的脚本就一直显示未登录。这和用户协议里「小红书」与「rednote」分属两份条款的写法一致。对用海外手机号注册账号的团队来说，这意味着很多教程里的脚本在你的账号上直接跑不通。

第四个代价是许可证，很多人用之前不看。MediaCrawler 的许可证叫「NON-COMMERCIAL LEARNING LICENSE 1.1」，条款写明软件只限学习和研究，「不得用于大规模爬取或干扰平台运营的活动」，未经版权方书面同意不得用于任何商业目的（MediaCrawler 许可证）。Spider_XHS 和 xiaohongshu-cli 在 GitHub 上没有声明许可证，按 GitHub 的说明，没有许可证意味着作者保留全部权利，别人没有使用、修改和分发的授权（GitHub 文档：许可仓库）。公司把这类代码放进产品或对客户的交付里，法务那一关先过不去。

按次付费的第三方接口：我们实测了什么

第三条路是按次付费的数据接口：你发一个 HTTP 请求，服务商回一页结构化的数据，按请求次数收钱。我们用 EveryInfra 在 2026 年 11 月 4 日 00:14 到 00:20（新加坡时间）真调了小红书的 6 项能力，共 9 次付费调用；另外故意做错了 3 次请求，中途还有 4 次被限速退回、过一两分钟重发成功（见下文「失败、空结果和限速」）。先读免费的能力目录确认参数和单价（能力目录，00:13 读取）：小红书一共 17 项能力，其中 16 项是每次 $0.005556，「蒲公英内容广场榜」是每次 $0.016；搜索、账号笔记、商品搜索每页 20 条，评论每页 15 条，回复每页 10 条，翻页游标 24 小时内有效。

这 9 次合计实扣 $0.061115，共 11 个计费单位（批量评论 3 篇算 3 个）。每千条的算法是「实扣 ÷ 实际返回条数 × 1,000」，分母用实际返回的条数，不用目录里的每页上限，所以回 19 条的那三次单价略高。这张表里差距最大的是笔记详情：同样 $0.005556，搜索一次给 20 条，详情一次给 1 条，摊到每条上差 20 倍。所以做批量分析时，能用搜索结果里的字段（标题、正文摘要、点赞、收藏、评论数、发布时间、作者）解决的，就不要每篇再拉一次详情。

几处细节值得单独说。第一，翻页是真的往下翻：第 2 页的 20 条和第 1 页没有一条重复，40 条里有 21 条是近 30 天发的，12 条是近 7 天，最老的一条是 231 天前，说明默认排序是「相关度」，不是时间；要看新内容就用 sort=newest 或 date_range。第二，详情比搜索多了 IP 属地、话题标签、图片列表这类字段，而且是现读的：那篇笔记在搜索结果里显示 231 条评论，两秒后读详情变成 232 条。第三，评论要注意回复：单篇评论第 1 页 15 条顶层评论声明了 53 条回复，返回里每条只带了 1 条，要完整的楼中楼得再调 xiaohongshu/sub_comments；3 篇的批量评论声明了 78 条回复，内嵌了 25 条。第四，comments_batch 是按笔记篇数计费的，3 篇收了 3 份 $0.005556，每条评论的单价和单篇调用一样；它省的是请求次数和限速名额，不省钱。

怎么接：curl、字段和 MCP 配置

最简单的接法是一个 POST 请求。下面就是上表第一次搜索的请求，把 Key 放在环境变量里，不要写进代码：

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform":"xiaohongshu","action":"search","params":{"keyword":"敏感肌防晒","sort":"newest","date_range":"last_7_days"}}'
# 翻页：把返回结果里的 next_page_token 原样放进 params.page_token；慢请求加 "mode":"async" 拿 job_id

返回字段和目录里的 response_fields 一一对应。下表列出本文用到的几组，最后一列是这次实测里看到的情况：

在 AI 客户端里用，EveryInfra 是一个远程 MCP 服务（MCP 是 Model Context Protocol，AI 客户端调用外部工具的开放协议，见规范），工具名都以 everyinfra_ 开头，在客户端里加一段配置就能用：

{
  "mcpServers": {
    "everyinfra": {
      "url": "https://api.everyinfra.com/mcp",
      "headers": { "Authorization": "Bearer ${env:EVERYINFRA_API_KEY}" }
    }
  }
}

配好之后可以直接说：「搜小红书上近 7 天『敏感肌防晒』的笔记，挑评论数超过 20 的，各拉一页评论，按提到的品牌汇总。」小红书各项能力的说明和试用见 小红书数据接口 和 小红书 MCP，接入验收步骤见 远程 MCP 接入。

失败、空结果和限速：哪些不扣钱

按次付费最怕的是「没拿到数据也扣钱」。我们故意做了 3 次失败请求（空结果、错参、无 Key）；另外 4 次被限速（429），都不扣费。7 次的结果如下：

空结果那一次等了 29 秒才返回，响应里 count 为 0、reason 为 empty_result_refunded，这次没有扣钱。参数写错返回 422 并给出可用的值，这对让 AI 自己调接口很有用，模型读到 did_you_mean 就能自己改。

4 次 429 都不是故意的。本文用的测试 Key 设了每分钟 10 次的单 Key 上限，而 00:14:59 到 00:15:48 这一分钟里我们自己只发了 4 次，说明同一时段还有别的测试在用这把 Key，名额先被占满了。每次 429 的响应都写明「Nothing was charged」，并给出 retry_after（5 到 17 秒）；我们过了 77 到 147 秒重发，4 次都成功，各扣一次正常的 $0.005556。正式账户的限速按账户计，名下所有 Key 合计，多开 Key 不会叠加，上限按累计充值分档（见价格页）。写定时任务时，按 retry_after 等待后重试，再给每轮任务留出排队时间，就不会因为限速丢数据。完整的扣费和退款对账方法见 失败退款对账。

xiaohongshu api pricing：小红书比别的平台贵 10 倍，预算要分开算

这是要照实写的一点：在我们自己的目录里，小红书是社交平台里最贵的。按各平台全部可用能力的中位数算，小红书每次 $0.005556，TikTok、YouTube、Instagram、B站、Reddit 都是 $0.000556，正好是十分之一；抖音、快手、微博、知乎、X 是 $0.000806，小红书是它们的 6.9 倍；淘宝、京东是 $0.001389，小红书是 4 倍。只有亚马逊比它贵一点（中位数 $0.006875）。

小红书的目录价是其他平台的 4 到 10 倍，以价格页为准。换成预算看更直观：每月 $10，按小红书每次 $0.005556 算能调约 1,800 次，按 TikTok 的中位数 $0.000556 算能调约 18,000 次。对读者的意义是：同样的预算，在小红书上能拉的请求数大约是 TikTok 的十分之一，所以下一节的「少调」比在别的平台上更重要。和 TikTok 数据接口 放在同一个项目里算预算时，不要按同一个单价估。

怎么少调：五个控量办法和一笔月账

第一，能用列表就不用详情。搜索、账号笔记每页 20 条，已经带了标题、正文摘要、点赞、收藏、评论数、发布时间和链接，绝大多数排序和筛选用这些字段就够了；只有要 IP 属地、话题标签或完整正文时才调 xiaohongshu/note，因为详情每条的成本是列表的 20 倍。第二，先看评论数再拉评论。我们这 40 条搜索结果里，评论数中位数是 14，只有 18 篇在 20 条以上；评论数为 0 的笔记拉评论只会拿到空结果（空结果不扣钱，但白占一次限速名额）。第三，用时间筛选代替全量重拉：每天的任务用 sort=newest 加 date_range=last_24_hours 或 last_7_days，只处理新笔记。第四，楼中楼按需展开：sub_comment_count 已经告诉你每条评论下面有多少回复，只展开回复多的那几条。第五，把频率降到业务真正需要的程度，很多竞品周报每周跑一次就够。

这张表的单价取目录的 $0.005556，「评论数 ≥20」的比例取本文样本的 18/40，这是推算，不是账单；你的关键词不同，比例会不同。它要说明的是：同一套监控，从每月 $70.01 降到 $4.44，差 15.8 倍，靠的全是少调，而不是换一个更便宜的单价。这也是按次计费的好处：每一次调用都看得见，砍掉哪一类调用省多少钱，事先就能算出来。

把第二个办法算细一点，用的还是本文那 40 篇「敏感肌防晒」搜索结果。这 40 篇的评论数加起来是 1,177 条，其中 11 篇评论数为 0、18 篇在 20 条以上，评论最多的一篇 231 条。下面四种拉评论的做法，单价都按目录的每页 $0.005556、每页 15 条算：

最后一行摊到 1,177 条评论上是每千条 $0.444，比第 1 页的 $0.370 高，因为每篇最后一页往往不满 15 条，同样的钱拿到的条数少。所以要全量评论时，先想清楚是不是真的要翻到底：做口碑归类，第 1 页的 15 条热评通常已经够用；只有要做「全部评论里提到某品牌的比例」这类统计时才值得翻完。单篇也可以这样估：那篇详情里显示 232 条评论的笔记，全部翻完是 16 页、$0.0889。

楼中楼同理。单篇评论第 1 页的 15 条顶层评论声明了 53 条回复，返回里已经每条内嵌 1 条；要把其余回复全部展开，按 xiaohongshu/sub_comments 每页 10 条，要 14 次、$0.0778；只展开回复数 ≥5 的 4 条评论，是 4 次、$0.0222，花费少了七成多，留下的正是讨论最热的几串。

最后算一下时间。本文的测试 Key 每分钟上限 10 次，按这个速度，上面「每天搜 1 页再给每篇拉评论」的方案每天 420 次，要排 42 分钟；「每周 1 次、只拉评论数 ≥20」的方案每轮 200 次，20 分钟跑完。正式账户的限速按累计充值分档，以价格页为准；无论哪一档，调用次数少，排队时间和被限速的次数也跟着少。

第三方服务怎么比价：同一个公式，六个要问的问题

市面上按请求计价的第三方服务很多，单价写法也五花八门：有的按次，有的按返回条数，有的按「点数」，还有的另收月费或起步费。比较时只用一个公式：每千条结果的价格 = 每次请求的价格 ÷ 每次实际返回的条数 × 1,000。举一个纯假设的例子：某服务每次 $0.01、每页 10 条，折合每千条 $1.00；同样每次 $0.01、每页 20 条，就是 $0.50。所以只比「每次多少钱」没有意义，一定要问清每页给几条，最好自己调一次数一数。按这个公式，我们实测的小红书搜索是每千条 $0.278，评论 $0.370。

表里第二、三、四行最容易被忽略。冷门词多、或者让 AI 客户端自己调接口难免写错参数时，「没拿到数据扣不扣钱」会直接改变月账；本文 7 次没拿到数据的请求（3 次故意做错、4 次被限速）都是 $0。比价时把这三行问清，再自己真调一次、数一数每页条数，比看宣传页可靠。价格和规则以价格页为准。

合规要点：相关法规、平台协议和使用者自己要守的做法

先说清楚：本文不构成法律意见，下面只列法条和平台协议的原文要点，你的具体用途请问律师。和「拿小红书数据」直接相关的有三处规定。《个人信息保护法》第二十七条允许「在合理的范围内处理个人自行公开或者其他已经合法公开的个人信息」，但个人明确拒绝的除外，对个人权益有重大影响的要取得同意（个人信息保护法）。《网络数据安全管理条例》第十八条要求「使用自动化工具访问、收集网络数据，应当评估对网络服务带来的影响，不得非法侵入他人网络，不得干扰网络服务正常运行」（条例全文，2025 年 1 月 1 日起施行，司法部发布消息）。2025 年修订的《反不正当竞争法》第十三条第三款新增：经营者「不得以欺诈、胁迫、避开或者破坏技术管理措施等不正当方式，获取、使用其他经营者合法持有的数据」，该法自 2025 年 10 月 15 日起施行（反不正当竞争法（2025 年修订））。

平台协议方面有两份文件。《小红书用户服务协议》（2026 年 3 月 23 日更新）对未经书面许可读取、统计、商业使用平台信息内容，以及抓取、模拟下载等方式有限制（第 3.4、4.1 条），对账号转借也有限制（第 2.3 条）（用户服务协议）；注册在中国境外的用户适用 rednote 服务条款，2026 年 6 月 9 日生效，同样限制用自动化方式提取数据（rednote Terms of Service）。你的用途是否落在这些限制里，请咨询律师。

司法实践里，有对未经许可批量抓取并转售平台数据判赔的案例。法院通常会看几件事：是否避开或破坏了技术措施，取的是零散信息还是形成了大规模数据集合并转售，是否涉及个人信息和非公开功能，对平台正常运行有没有实质影响。

不论你走哪条路，用到小红书数据时，使用者自己至少要守下面这些做法：

• 只用于合法、明确的用途，比如自家品牌的口碑分析、选品研究，用途写进内部记录，换用途前重新评估。
• 遵守平台协议和你所在地区的法律；协议限制的用途（比如商业转售、批量下载内容）先问律师。
• 个人信息最小化：评论里的昵称、头像、IP 属地按个人信息处理，分析用不到的字段不存，能汇总就不留逐条明细，存储期限和用途写清楚。
• 不转售原始数据：对外交付分析结论和汇总表，不把逐条原始数据打包卖给别人或公开发布。
• 按分析需要少量取，不囤全量；过期的原始数据按期删除。
• 不碰私信、私密账号这类非公开内容，也不用取到的数据去批量私信或骚扰用户。

这几条和上文「怎么少调」的办法方向一致：只取分析真正用到的那部分，既省钱，也让要保存和保护的数据更少。

三条路怎么选：按你要做的事

如果你在做自己的 App，想加「用小红书登录」，走开放平台账号能力，申请 basic_info，按快速接入文档创建应用、配回调地址、等 1–3 个工作日审核。如果你是小红书商家，要把订单、售后同步到 ERP，走电商开放平台，自己有技术团队就选「商家自研」，没有就在服务市场找服务商。如果你在小红书投广告，要批量拉报表，找你的销售开通聚光 Marketing API。这三种需求都不需要第三方，也不应该用第三方。

如果你要做的是看别人：竞品的笔记数和互动、某个话题下用户在吐槽什么、哪些商品在被种草、某个品牌在小红书上的口碑走势，官方入口目前给不了，只剩脚本和第三方接口。小量、偶尔、为了学习，开源脚本够用，用一个不怕丢的账号，读清楚许可证。要每天稳定跑、要交给客户、要让 AI 客户端自己调，按次付费接口更省心，按「怎么少调」一节的办法把调用量控住，按「合规要点」一节的做法守住边界。站内另有两篇可以接着读：小红书数据导出与快照分析讲怎么把搜索和评论存成可复查的快照，Claude Code 动态工作流拉小红书评论讲怎么让 AI 自己决定拉哪些评论；批量评论的完整步骤见 小红书评论批量采集。

行业动向（2026 年 10–11 月）

• 2026-11-03：取样前一天，MediaCrawler、xiaohongshu-mcp、XiaohongshuSkills 都有新提交，近 30 天提交分别是 11、35、32 次；ReaJason/xhs 仍停在 2025 年 7 月 1 日（GitHub API，2026-11-04 00:19:50 新加坡时间取数）。对读者意味着：还活着的开源工具都在高频跟改，用它就要跟着升级，停更的那几个不适合放进定时任务。
• 2026-10-23 前后：xiaohongshu-mcp 连续出现「无法登录」「搜索被限制」两类 issue，维护者 11 月 1 日合并了修复「搜索结果等待」和「发布时回点标题框」的提交，11 月 3 日又修了登录取码失败后的浏览器清理（xiaohongshu-mcp 提交记录）。对读者意味着：靠登录态的工具每隔几周就要跟着平台改一次，定时任务要有失败告警。
• 2026-10-17：小红书网页里的服务端数据换了一种写法，13,199 星的 XHS-Downloader 解析直接报错（#497）。对读者意味着：一次普通工作日的页面变化，就能让所有读这类页面的脚本同时停摆，排期时要留出修复时间。
• 2026-08-19：小红书开放平台账号能力的 API 参考更新，仍只开放 basic_info（API 参考）。对读者意味着：官方读取笔记的接口短期内还指望不上。

上手：从一次试用到每周自动跑

第一步，注册 EveryInfra 拿 API Key，没有月费，充进钱包的余额长期有效、不清零，步骤见快速上手。第二步，在能力页上先免费读目录、再试一次：试小红书搜索、试笔记详情、试评论、试批量评论、试账号笔记、试商品搜索、试评论回复。第三步，看响应里的 charged_usd 和返回条数，按「实扣 ÷ 条数 × 1,000」算出你自己场景的每千条价，再按「怎么少调」一节的表估一个月的量。第四步，把 MCP 配置加进你的 AI 客户端，让它按你的关键词每周跑一次。其他平台和能力在数据市场里按平台找，服务状态见状态页。

常见问题

小红书有官方 API 吗？

问题来自 Google 联想词「小红书api接口」「xiaohongshu developer api」。有，但只对「自己的东西」开放：账号登录只开放 basic_info（昵称、头像、性别、地区），电商开放平台只给企业店铺和软件服务商读授权店铺的订单和商品，聚光接口只给广告主拉自己的报表（授权范围、电商授权流程）。读取别人公开笔记和评论的官方接口目前没有，read_notes 在官方文档里是「规划中」。

小红书 api key 怎么申请？

问题来自联想词「小红书api key」「xiaohongshu api key」。官方没有一个通用的「API Key」：账号能力是创建应用后拿 app_id 和 app_secret，审核约 1–3 个工作日（快速接入）；电商开放平台是企业认证后拿 appId 和 appSecret，再由店铺主账号授权；聚光要由销售发起注册审批。如果你要的是读公开笔记的 Key，那是第三方服务的 Key，比如 EveryInfra 注册后在控制台生成。

小红书 api github 上的开源项目能商用吗？

问题来自联想词「小红书api github」「xiaohongshu api github」。看许可证。本文取样的 9 个仓库里，MediaCrawler 的许可证明确只许非商业学习，不得大规模爬取（许可证）；Spider_XHS 和 xiaohongshu-cli 没有声明许可证，默认作者保留全部权利；xiaohongshu-mcp 是 Apache-2.0，XHS-Downloader 是 GPL-3.0。许可证只管代码，不管你用代码去取的数据，数据怎么用仍然受小红书用户协议和法律约束。

小红书 api 能发帖吗？

问题来自联想词「小红书 api 发帖」。官方的 write_notes 授权范围还在「规划中」，并注明需要人工审核、仅特定场景开放（授权范围）；分享开放平台目前显示暂停接入。开源工具里有自动发布功能，靠的是模拟网页操作，xiaohongshu-mcp 10 月 18 日就有一条「图文发布持续超时，读操作正常」的 issue（#875）。EveryInfra 目录里的 17 项小红书能力都是读取类，没有发帖。

小红书数据采集合法吗？

问题来自联想词「小红书数据采集」「小红书采集工具」。本文不构成法律意见。小红书用户协议对未经许可的自动化读取和商业使用有限制，2025 年修订的《反不正当竞争法》也明确禁止避开或破坏技术管理措施获取他人数据（反不正当竞争法）；法条、协议要点和使用者要守的做法见上文「合规要点」一节，你的具体用途请咨询律师。

参考资料

1. 开发者门户首页，小红书开放平台，2026-11-04 读取。https://openaccount.xiaohongshu.com/
2. 授权范围（Scope），小红书开放平台，最后更新 2026-03-29，2026-11-04 截图。https://openaccount.xiaohongshu.com/docs/scope
3. API 参考，小红书开放平台，最后更新 2026-08-19。https://openaccount.xiaohongshu.com/docs/api-reference
4. 快速接入，小红书开放平台，最后更新 2026-03-29。https://openaccount.xiaohongshu.com/docs/quick-start
5. 授权流程（软件服务商），小红书电商开放平台开发者文档。https://open.xiaohongshu.com/document/developer/file/38
6. 签名算法，小红书电商开放平台开发者文档。https://open.xiaohongshu.com/document/developer/file/39
7. 开发者文档目录（电子面单、服务市场规则），小红书电商开放平台。https://open.xiaohongshu.com/document/developer/file/4
8. 开发者角色说明（开放平台文档镜像，第三方托管）。https://xiaohongshu.apifox.cn/doc-2811119
9. 聚光开放平台 Marketing API 入门指南，小红书聚光，更新于 2024-01-03。https://ad.xiaohongshu.com/openApiDoc?categoryId=761&articleId=3047
10. 小红书分享开放平台首页。https://agora.xiaohongshu.com/index
11. 小红书分享开放平台暂停接入，V2EX，2025-11-06。https://global.v2ex.co/t/1170874
12. 小红书小程序开放平台。https://miniapp.xiaohongshu.com/
13. 小红书用户服务协议，更新日期 2026-03-23。https://agree.xiaohongshu.com/h5/terms/ZXXY20220331001/-1
14. rednote Terms of Service，生效日期 2026-06-09。https://agree.xiaohongshu.com/h5/terms/ZXXY20251205003/-1
15. NanmiCoder/MediaCrawler，GitHub，2026-11-04 读取。https://github.com/NanmiCoder/MediaCrawler
16. MediaCrawler 许可证 NON-COMMERCIAL LEARNING LICENSE 1.1，GitHub。https://github.com/NanmiCoder/MediaCrawler/blob/main/LICENSE
17. xpzouying/xiaohongshu-mcp，GitHub。https://github.com/xpzouying/xiaohongshu-mcp
18. xiaohongshu-mcp 提交记录，GitHub，2026-11-04 读取。https://github.com/xpzouying/xiaohongshu-mcp/commits/main
19. xiaohongshu-mcp #880「无法登录」，2026-10-23。https://github.com/xpzouying/xiaohongshu-mcp/issues/880
20. xiaohongshu-mcp #877「搜索被限制」，2026-10-21。https://github.com/xpzouying/xiaohongshu-mcp/issues/877
21. xiaohongshu-mcp #878「小红书官方允许吗」，2026-10-22。https://github.com/xpzouying/xiaohongshu-mcp/issues/878
22. xiaohongshu-mcp #579「支持 rednote.com（海外用户）」，2026-03-13。https://github.com/xpzouying/xiaohongshu-mcp/issues/579
23. JoeanAmier/XHS-Downloader，GitHub。https://github.com/JoeanAmier/XHS-Downloader
24. XHS-Downloader #497 SSR 数据解析失败，2026-10-17。https://github.com/JoeanAmier/XHS-Downloader/issues/497
25. XHS-Downloader #479 调整抓取速度，2026-09-15。https://github.com/JoeanAmier/XHS-Downloader/issues/479
26. cv-cat/Spider_XHS，GitHub。https://github.com/cv-cat/Spider_XHS
27. Spider_XHS #191 Cookie 失效，2026-10-10。https://github.com/cv-cat/Spider_XHS/issues/191
28. jackwener/xiaohongshu-cli，GitHub。https://github.com/jackwener/xiaohongshu-cli
29. xiaohongshu-cli #82 每 7 天重新登录，2026-08-17。https://github.com/jackwener/xiaohongshu-cli/issues/82
30. ReaJason/xhs，GitHub。https://github.com/ReaJason/xhs
31. white0dew/XiaohongshuSkills，GitHub。https://github.com/white0dew/XiaohongshuSkills
32. autoclaw-cc/xiaohongshu-skills，GitHub。https://github.com/autoclaw-cc/xiaohongshu-skills
33. Jamailar/Beav，GitHub。https://github.com/Jamailar/Beav
34. Cloxl/xhshow 小红书请求签名库，GitHub。https://github.com/Cloxl/xhshow
35. List repository issues，GitHub REST API 文档。https://docs.github.com/en/rest/issues/issues#list-repository-issues
36. Licensing a repository，GitHub 文档。https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository
37. 中华人民共和国个人信息保护法，国家互联网信息办公室。https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm
38. 网络数据安全管理条例（国务院令第 790 号），生态环境部转载。https://www.mee.gov.cn/zcwj/gwywj/202410/t20241003_1087417.shtml
39. 李强签署国务院令公布《网络数据安全管理条例》，司法部，2024-09-30。https://www.moj.gov.cn/pub/sfbgw/gwxw/xwyw/202409/t20240930_507076.html
40. 中华人民共和国反不正当竞争法（2025 年修订），国家知识产权局。https://www.cnipa.gov.cn/art/2026/5/20/art_104_206437.html
41. V2EX 讨论帖（蒲公英页面接口的回复），V2EX。https://www.v2ex.com/t/1170609
42. EveryInfra 社交数据能力目录（免费读取），2026-11-04 00:13 新加坡时间读取。https://api.everyinfra.com/api/v1/social/catalog
43. Model Context Protocol 规范 2025-06-18。https://modelcontextprotocol.io/specification/2025-06-18
44. xiaohongshu-mcp #875「图文发布持续超时，读操作正常」，2026-10-18。https://github.com/xpzouying/xiaohongshu-mcp/issues/875