拓冰网站定制 
简介这是一份面向Python爬虫与JavaScript逆向学习者的开源项目资源主要聚焦小红书平台数据采集的算法还原与接口封装方案。项目核心针对小红书x-s、x-common等加密参数用Python还原其生成逻辑并将GET、POST等请求类型及常用接口封装为预制模块使使用者无需深入逆向细节即可调用实现毫秒级数据抓取开箱即用。资源包共29个文件以py源码为主辅以yml工作流配置、txt依赖清单、md/rst说明文档以及makefile、ini、cfg等工程辅助文件整体压缩包仅28KB短小精炼。目前已有4435人学习浏览。通过学习可掌握接口参数还原、JavaScript逆向思路、爬虫请求构造与工程化组织方式同时项目内所含测试用例和文档便于二次开发或快速接入自己的分析流程适合希望深入小红书协议或开展社交媒体数据挖掘的开发者参考。1. 项目背景与我为什么要碰这个方向小红书这个平台现在早就不只是美妆穿搭的种草社区了。美食探店、旅行攻略、数码评测、职场经验甚至行业趋势分析信息密度相当高。所以不管是做内容运营、竞品分析、用户调研还是单纯的行业研究都会遇到同一个问题需要大量真实数据来支撑判断。但官方没有提供公开的开放接口手动一篇篇复制又太原始这时候xhs-小红书数据采集python算法还原这类项目就成了绕不开的话题。我最早接触这个方向纯粹是被数据逼的。当时要给一个消费品牌做投放效果复盘需要分析某品类下几十个头部博主的笔记数据、互动趋势、评论情绪人工翻页截图整理了两天效率低还容易出错。后来开始尝试用Python写脚本从最简单的页面请求到逐步理解数据是怎么加载出来的再到面对各种加密参数时不得不去还原算法走了不少弯路也踩了不少坑。这篇文章我会把整个过程里最核心的东西梳理出来前期怎么选技术路线、中间怎么处理请求和解析、所谓的算法还原到底在还原什么、以及实操中必然遇到的坑和对应的解法。内容偏向实战适合对Python有一定基础、想做合规数据采集的运营、开发或研究型读者。需要先说明的是整个项目必须以合法合规为前提只采集公开可访问的数据尊重平台规则和用户隐私千万别越界。先说我的结论市面上把算法还原讲得很玄乎但本质上它就是搞清楚客户端在发请求时除了你肉眼看到的参数之外服务端还要校验哪些隐藏参数以及这些参数是怎么根据请求信息算出来的这一件事。理解了这句话后面所有技术点都有了解题方向。2. 整体思路拆解从数据流角度看采集链路2.1 一条笔记数据从服务器到我的Excel到底经过了什么如果你在浏览器里打开小红书网页版随意点开一篇笔记你会发现内容完整地渲染在页面上了。如果这时候按下F12打开开发者工具切到Network面板刷新页面就能看到几十个网络请求。真正装着笔记正文内容、点赞数这些核心数据的往往不是最开始的HTML文档而是后面某个JSON接口的响应。这个现象解释了一个关键问题数据是动态加载的。也就是说服务器返回给浏览器的第一份HTML只是一个空壳子JavaScript在浏览器里继续跑再向后端接口发起二次请求拿到的JSON数据才被填充到页面上。既然数据来自接口那用Python模拟这个接口调用就能跳过浏览器直接拿到结构化数据省去解析HTML的麻烦。整条链路我画在一张草图上大概是这样构造参数并签名然后带着关键Header发送HTTP请求服务端校验通过后返回JSON本地解析存入数据表。听上去很简单但每一步都藏着坑。比如签名参数怎么生成、Header里哪些字段是强校验、请求频率多高会被限制这些就是整个项目真正的技术含量。2.2 为什么网上方案五花八门我却推荐“先理解再编程”我之前见过不少人一上来就找现成的轮子——GitHub上搜小红书爬虫确实能搜出一堆仓库有些还标着Star很高。但直接clone下来跑大概率跑不通。原因有二一是平台的风控参数更新之间非常快旧仓库的加密逻辑很可能已经失效二是不理解内置逻辑出了问题根本不知道从哪里排查。所以我强烈建议第一遍不要急着写任何代码先花半天时间把请求流程手动过一遍。用浏览器开发者工具观察每个请求的URL、Method、Headers、Payload、响应结构记录下来。第二遍才开一个空的Python文件从最简单的requests.get开始请求一个公开笔记详情页的接口观察返回结果和浏览器里的差异逐渐补齐缺失的参数和Header。这种先理解再编程的方式比拿别人的代码来改要扎实得多后面调试时你才知道错在哪里。3. 工具选型与环境准备搭建一个顺手的基础设施3.1 Python环境与依赖库的取舍做这类项目Python 3.9以上版本就够了我用的是3.10。依赖库方面核心就三个requests负责发送HTTP请求json是标准库直接用来解析数据pandas用来做数据清洗和导出Excel。如果日后需要更复杂的并发请求可以把requests升级成httpx或者用异步的aiohttp但对于第一版脚本requests完全够用没必要过度设计。安装依赖时有个小建议在项目根目录创建一个虚拟环境不要直接往全局环境里装。我吃过这个亏曾经把某个第三方库装到全局导致好几个旧项目无法运行。创建一个干净的虚拟环境是好习惯具体命令如下python -m venv venv source venv/bin/activate # Windows下执行 venv\Scripts\activate pip install requests pandas3.2 抓包工具与调试辅助Requests库只是用来发请求但真正去观察接口结构、翻看参数格式我需要一个顺手的抓包工具。浏览器自带的开发者工具完全够用我大部分时间都直接用Chrome的DevTools。F12打开后切到Network面板勾选Preserve log日志保留这样页面跳转时历史请求不会丢失。对于需要批量观察、过滤URL关键词的场景我会配合Charles或者mitmproxy这类独立代理工具。它们在移动端调试时尤其有用——有时候Web端的加密方式和App端不完全一样想研究App端的请求结构就需要在手机上配置代理证书把HTTPS流量解包出来看。不过说实话Web端能搞定的需求我是不会去碰App端的工作量完全是两回事。4. 核心细节解析所谓“算法还原”到底在还原什么4.1 平台常用的风控手段一览把小红书Web端的接口校验方式拆开来大致可以分成四层第一层是基础Header校验。简单如User-Agent、Referer、Origin这些字段服务端会检查你是不是从正规入口进来的。如果这些信息缺失或者互相矛盾直接拒绝响应。第二层是Cookie鉴权。登录后服务端会下发一组Cookie其中一部分包含你的身份凭证。很多接口要求必须在请求头里带上这些Cookie才肯返回数据否则返回401或登录跳转。这里需要注意Cookie不是静态的过一段时间会失效需要处理好登录态的管理。第三层是签名参数。这是算法还原的重头戏。部分接口的请求URL上会带着一个类似X-S、X-T之类的参数它不是固定值而是根据每次请求的时间戳、请求路径、请求体内容等动态计算出来的。服务端拿到请求后会按照同一套逻辑重新算一遍如果值对不上就判定为非法请求。第四层是行为风控。就算前三层都突破了频繁请求一样会触发验证码或者IP限制。有些验证码是滑块形式的这就涉及更复杂的行为模拟问题。把这四层放进一个表格里理解会更清楚风控层级校验内容常见的绕过方式实际难度基础HeaderUA、Referer、Origin设定合理的请求头低Cookie鉴权登录态凭证维护Cookie会话低签名参数动态加密参数研究加密逻辑、还原算法高行为风控频率、行为轨迹限速、代理池、随机等待中4.2 还原签名算法的正确姿势不是硬啃JS很多人一提到算法还原第一反应是我要去读JavaScript源码把它翻译成Python。这个思路没有错但不是最高效的。我的习惯是先判断这个参数是不是真的强校验。怎么判断把请求URL里的某个动态参数删掉用Python直接请求一次看服务端是正常返回还是报错。如果报错说明它确实是必填项如果不报错说明它只是个障眼法直接忽略就行。强校验的参数往往出现在带有搜索、翻页、详情获取这类核心功能的接口上。要还原它推荐用抠代码配合补环境的方式在Chrome的Sources面板里搜索参数名定位到生成它的JavaScript函数把其中相关的代码片段拿出来用Node.js在本地执行最后通过子进程方式由Python调用Node生成签名。这种方式避免了自己翻译算法的繁琐过程也不容易出错。我之前写过这么一段Python侧调Node签名的代码结构大概是这样的import subprocess import json def get_signature(params: dict) - str: # params 是需要参与签名的原始参数 result subprocess.run( [node, sign.js, json.dumps(params)], capture_outputTrue, textTrue, encodingutf-8 ) return result.stdout.strip()对应的sign.js文件里就是抠出来的那一段生成签名的JS逻辑。不过这里有个重要提醒别抱着永远破解的念头。平台改版很快今天写好的签名逻辑明天可能就变了。更务实的做法是把签名函数设计成独立的模块平台一改你只需要更新这一小段而不是把整个采集脚本推倒重来。4.3 “算法还原”技术的合规边界这一点我必须单独拿出来说。理解签名算法、做技术研究本身是中性的。但如果你用还原出来的算法去做高频率的数据抓取、绕过平台风控、获取非公开数据那就越界了。我在整个项目里始终坚持三条纪律第一只采集公开页面能直接看到的数据第二控制请求频率不大规模并发第三不采集个人敏感信息。这既是法律要求也是技术人基本的职业操守。5. 实操过程实现一个最小可用的笔记详情采集脚本5.1 从浏览器复制一个请求开始为了避免空谈我以采集某篇公开笔记的基础数据标题、作者、点赞、收藏、评论数为目标带大家走一遍完整流程。第一步在浏览器打开一篇小红书笔记F12打开DevTools进入Network面板刷新页面。在请求列表里找到名为notes/xxx/details不同版本可能不一样特征是返回JSON且包含标题字段的请求右键Copy as cURL。第二步把复制的cURL命令粘贴到终端随便用一个在线cURL转Python的工具转成requests结构。这不是让你直接用而是让你看清这个请求里所有Header和参数的样子。第三步最关键的一步逐个字段确认哪些可以删掉。我会先把cURL转出来的代码放进脚本里跑一遍能正常拿数据然后开始删Header删一个跑一次直到删出问题那删掉的最后一个就是必要条件。通过这种方式把请求精简到最小可用状态后面维护起来也容易。我最终精简出来的请求核心大概是下面这个模样import requests import time import json headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Referer: https://www.xiaohongshu.com/, Origin: https://www.xiaohongshu.com, } def fetch_note_detail(note_id: str, cookies: str) - dict: url fhttps://www.xiaohongshu.com/explore/{note_id} params { source_note_id: note_id, source: explore_feed, } # 这里省略了签名参数的生成步骤 # params[x-s] get_signature(params) resp requests.get(url, headersheaders, cookiescookies, paramsparams, timeout10) resp.raise_for_status() data resp.json() note_detail data.get(data, {}).get(items, [])[0] return note_detail这段代码返回的note_detail是一个嵌套字典里面就有标题、正文、作者信息、互动数据等。听到省略了签名参数生成步骤可能有人会焦虑。但说到底签名生成这个动作是动态变化的一篇罗列具体代码的教程很容易在两周后失效反而是把结构和方法教给你你能自己应对变化。5.2 数据清洗与导出让数据“可用”拿到原始JSON只是第一步。嵌套结构里的字段名往往是英文下划线或驼峰命名比如likedCount、collectedCount直接看会有点懵但对应关系整理清楚后用pandas转成表格就行了。我习惯把关键字段抽出来放在一个字典里再统一转DataFrame。下面这段代码把嵌套的互动数据拍平到一行import pandas as pd def flat_note(raw: dict) - dict: return { note_id: raw.get(id), title: raw.get(title), desc: raw.get(desc), author: raw.get(user, {}).get(nickname), likes: raw.get(interactInfo, {}).get(likedCount), favorites: raw.get(interactInfo, {}).get(collectedCount), comments: raw.get(interactInfo, {}).get(commentCount), shares: raw.get(interactInfo, {}).get(shareCount), create_time: raw.get(time), } rows [flat_note(item) for item in raw_list] df pd.DataFrame(rows) df.to_excel(note_data.xlsx, indexFalse)这样导出的数据表用来做透视、排序、环比都非常方便。比如我想看最近一个月哪个博主的平均点赞最高只要加一列博客名再pivot一下就能出结果。5.3 大批量采集时的频率控制策略少量数据靠请求硬顶是完全没问题的但真正要跑上万个笔记ID必须考虑频率控制。我自己的经验是每次请求之后最少停1到2秒每100次请求停更久一点比如10秒。这一方面是防止给平台服务器造成压力另一方面也是把触发验证码的概率降到最低。还可以引入一种简单的指数退避策略第一次失败等2秒重试第二次失败等4秒超过5次就放弃这条数据标记下来手动补。这种策略不会让你的采集速度突飞猛进但会让整个采集过程稳定很多。稳定是长周期采集最重要的指标。6. 常见问题与排查技巧实录6.1 返回空白或提示“操作频繁”怎么办这是最常遇到的问题遇到它先别慌按顺序排查第一步看请求状态码如果是200但内容是空的检查是不是页面结构换了字段名JSON解析层取错了路径如果是302跳转基本是Cookie失效了重新登录更新Cookie如果直接弹验证码那就是频率太高或者IP被盯上了建议停下来等半小时再用代理换一个出口IP。6.2 签名参数生成了但还是被拒绝这个情况我踩过最深的坑是时间戳不同步。签名算法里往往包含请求发起的时间服务端会校验这个时间戳是否在合理范围内。如果你本机的时间跟服务器时间偏差超过一两分钟签名就会失效。排查方法很简单在签名生成的代码里把时间戳打出来跟浏览器里实际请求的时间戳对比差太多就同步一下系统时间。另一个容易忽略的点是请求体的参与签名问题。有的接口不仅GET参数参与签名POST的请求体也参与。很多人在自测时只改了URL参数忘了在签名函数里把请求体数据也传进去导致签名的值始终对不上。遇到这种情况把签名函数的入参打印出来仔细比对参与计算的字段和实际发送的字段是否完全一致。6.3 7个避免踩坑的细节一是User-Agent里的系统版本、浏览器版本要跟实际环境匹配太离谱的组合容易被识别。二是请求里的顺序其实不重要Header不区分顺序但大小写规范和常见顺序还是别太随意。三是Cookie的持久化建议用requests.Session来管理重定向和Cookie维持都更自然。四是脚本跑了一段时间数据开始变少先检查IP是不是被限制而不是急着改代码。五是所有正则解析都改用JSON路径提取页面的HTML模板一变正则就废但接口的JSON结构相对来说稳定得多。六是日志非常关键每一条请求的URL、状态码、耗时都打出来出问题的时候能快速定位。七是给自己设置一个最大重试次数不做无休止的循环。7. 项目能做什么以及还能往哪个方向延伸脚本写到这里其实已经具备了一个通用框架。你可以把fetch_note_detail改装成搜索接口的请求函数用同一个签名逻辑去跑搜索词就能批量拿到某个关键词下的笔记列表。把笔记ID抽出来去请求详情就得到更完整的数据集。这一套组合拳覆盖了从按关键词发现笔记到按笔记ID获取详情的完整链路。我后来基于这套逻辑做过几个实际应用给一家MCN机构跑过某个细分品类近半年的内容趋势分析笔记标题里的高频词和互动量的关系给自己运营的账号做过一个小的选题辅助工具输入一个关键词返回近期热度最高的笔记和它们的评论区高频情绪词帮我在起标题时避开自嗨型表达。这套框架最大的价值不是写出了多少行代码而是让我掌握了一套观察接口-精简请求-处理异常-结构化数据的方法论。换一个平台换个数据源这套思路依然能打。只是每一次换目标平台都要重新走一遍理解流程的路没有一劳永逸的方案。最后再分享一个我个人的习惯脚本跑完我一定会在本地保留一份当时抓下来的原始JSON备份哪怕已经转成了Excel。因为需求方经常会在你看完数据之后追加一句这个字段的数据还能不能拿到如果原始JSON还在重新解析一下就行如果没了你就得重新去请求又是一轮风控博弈。备份原始数据是这个项目里成本最低、收益最明显的一个好习惯。本文还有配套的精品资源点击获取 小红书数据采集实战：Python算法还原与风控应对
简介这是一份面向Python爬虫与JavaScript逆向学习者的开源项目资源主要聚焦小红书平台数据采集的算法还原与接口封装方案。项目核心针对小红书x-s、x-common等加密参数用Python还原其生成逻辑并将GET、POST等请求类型及常用接口封装为预制模块使使用者无需深入逆向细节即可调用实现毫秒级数据抓取开箱即用。资源包共29个文件以py源码为主辅以yml工作流配置、txt依赖清单、md/rst说明文档以及makefile、ini、cfg等工程辅助文件整体压缩包仅28KB短小精炼。目前已有4435人学习浏览。通过学习可掌握接口参数还原、JavaScript逆向思路、爬虫请求构造与工程化组织方式同时项目内所含测试用例和文档便于二次开发或快速接入自己的分析流程适合希望深入小红书协议或开展社交媒体数据挖掘的开发者参考。1. 项目背景与我为什么要碰这个方向小红书这个平台现在早就不只是美妆穿搭的种草社区了。美食探店、旅行攻略、数码评测、职场经验甚至行业趋势分析信息密度相当高。所以不管是做内容运营、竞品分析、用户调研还是单纯的行业研究都会遇到同一个问题需要大量真实数据来支撑判断。但官方没有提供公开的开放接口手动一篇篇复制又太原始这时候xhs-小红书数据采集python算法还原这类项目就成了绕不开的话题。我最早接触这个方向纯粹是被数据逼的。当时要给一个消费品牌做投放效果复盘需要分析某品类下几十个头部博主的笔记数据、互动趋势、评论情绪人工翻页截图整理了两天效率低还容易出错。后来开始尝试用Python写脚本从最简单的页面请求到逐步理解数据是怎么加载出来的再到面对各种加密参数时不得不去还原算法走了不少弯路也踩了不少坑。这篇文章我会把整个过程里最核心的东西梳理出来前期怎么选技术路线、中间怎么处理请求和解析、所谓的算法还原到底在还原什么、以及实操中必然遇到的坑和对应的解法。内容偏向实战适合对Python有一定基础、想做合规数据采集的运营、开发或研究型读者。需要先说明的是整个项目必须以合法合规为前提只采集公开可访问的数据尊重平台规则和用户隐私千万别越界。先说我的结论市面上把算法还原讲得很玄乎但本质上它就是搞清楚客户端在发请求时除了你肉眼看到的参数之外服务端还要校验哪些隐藏参数以及这些参数是怎么根据请求信息算出来的这一件事。理解了这句话后面所有技术点都有了解题方向。2. 整体思路拆解从数据流角度看采集链路2.1 一条笔记数据从服务器到我的Excel到底经过了什么如果你在浏览器里打开小红书网页版随意点开一篇笔记你会发现内容完整地渲染在页面上了。如果这时候按下F12打开开发者工具切到Network面板刷新页面就能看到几十个网络请求。真正装着笔记正文内容、点赞数这些核心数据的往往不是最开始的HTML文档而是后面某个JSON接口的响应。这个现象解释了一个关键问题数据是动态加载的。也就是说服务器返回给浏览器的第一份HTML只是一个空壳子JavaScript在浏览器里继续跑再向后端接口发起二次请求拿到的JSON数据才被填充到页面上。既然数据来自接口那用Python模拟这个接口调用就能跳过浏览器直接拿到结构化数据省去解析HTML的麻烦。整条链路我画在一张草图上大概是这样构造参数并签名然后带着关键Header发送HTTP请求服务端校验通过后返回JSON本地解析存入数据表。听上去很简单但每一步都藏着坑。比如签名参数怎么生成、Header里哪些字段是强校验、请求频率多高会被限制这些就是整个项目真正的技术含量。2.2 为什么网上方案五花八门我却推荐“先理解再编程”我之前见过不少人一上来就找现成的轮子——GitHub上搜小红书爬虫确实能搜出一堆仓库有些还标着Star很高。但直接clone下来跑大概率跑不通。原因有二一是平台的风控参数更新之间非常快旧仓库的加密逻辑很可能已经失效二是不理解内置逻辑出了问题根本不知道从哪里排查。所以我强烈建议第一遍不要急着写任何代码先花半天时间把请求流程手动过一遍。用浏览器开发者工具观察每个请求的URL、Method、Headers、Payload、响应结构记录下来。第二遍才开一个空的Python文件从最简单的requests.get开始请求一个公开笔记详情页的接口观察返回结果和浏览器里的差异逐渐补齐缺失的参数和Header。这种先理解再编程的方式比拿别人的代码来改要扎实得多后面调试时你才知道错在哪里。3. 工具选型与环境准备搭建一个顺手的基础设施3.1 Python环境与依赖库的取舍做这类项目Python 3.9以上版本就够了我用的是3.10。依赖库方面核心就三个requests负责发送HTTP请求json是标准库直接用来解析数据pandas用来做数据清洗和导出Excel。如果日后需要更复杂的并发请求可以把requests升级成httpx或者用异步的aiohttp但对于第一版脚本requests完全够用没必要过度设计。安装依赖时有个小建议在项目根目录创建一个虚拟环境不要直接往全局环境里装。我吃过这个亏曾经把某个第三方库装到全局导致好几个旧项目无法运行。创建一个干净的虚拟环境是好习惯具体命令如下python -m venv venv source venv/bin/activate # Windows下执行 venv\Scripts\activate pip install requests pandas3.2 抓包工具与调试辅助Requests库只是用来发请求但真正去观察接口结构、翻看参数格式我需要一个顺手的抓包工具。浏览器自带的开发者工具完全够用我大部分时间都直接用Chrome的DevTools。F12打开后切到Network面板勾选Preserve log日志保留这样页面跳转时历史请求不会丢失。对于需要批量观察、过滤URL关键词的场景我会配合Charles或者mitmproxy这类独立代理工具。它们在移动端调试时尤其有用——有时候Web端的加密方式和App端不完全一样想研究App端的请求结构就需要在手机上配置代理证书把HTTPS流量解包出来看。不过说实话Web端能搞定的需求我是不会去碰App端的工作量完全是两回事。4. 核心细节解析所谓“算法还原”到底在还原什么4.1 平台常用的风控手段一览把小红书Web端的接口校验方式拆开来大致可以分成四层第一层是基础Header校验。简单如User-Agent、Referer、Origin这些字段服务端会检查你是不是从正规入口进来的。如果这些信息缺失或者互相矛盾直接拒绝响应。第二层是Cookie鉴权。登录后服务端会下发一组Cookie其中一部分包含你的身份凭证。很多接口要求必须在请求头里带上这些Cookie才肯返回数据否则返回401或登录跳转。这里需要注意Cookie不是静态的过一段时间会失效需要处理好登录态的管理。第三层是签名参数。这是算法还原的重头戏。部分接口的请求URL上会带着一个类似X-S、X-T之类的参数它不是固定值而是根据每次请求的时间戳、请求路径、请求体内容等动态计算出来的。服务端拿到请求后会按照同一套逻辑重新算一遍如果值对不上就判定为非法请求。第四层是行为风控。就算前三层都突破了频繁请求一样会触发验证码或者IP限制。有些验证码是滑块形式的这就涉及更复杂的行为模拟问题。把这四层放进一个表格里理解会更清楚风控层级校验内容常见的绕过方式实际难度基础HeaderUA、Referer、Origin设定合理的请求头低Cookie鉴权登录态凭证维护Cookie会话低签名参数动态加密参数研究加密逻辑、还原算法高行为风控频率、行为轨迹限速、代理池、随机等待中4.2 还原签名算法的正确姿势不是硬啃JS很多人一提到算法还原第一反应是我要去读JavaScript源码把它翻译成Python。这个思路没有错但不是最高效的。我的习惯是先判断这个参数是不是真的强校验。怎么判断把请求URL里的某个动态参数删掉用Python直接请求一次看服务端是正常返回还是报错。如果报错说明它确实是必填项如果不报错说明它只是个障眼法直接忽略就行。强校验的参数往往出现在带有搜索、翻页、详情获取这类核心功能的接口上。要还原它推荐用抠代码配合补环境的方式在Chrome的Sources面板里搜索参数名定位到生成它的JavaScript函数把其中相关的代码片段拿出来用Node.js在本地执行最后通过子进程方式由Python调用Node生成签名。这种方式避免了自己翻译算法的繁琐过程也不容易出错。我之前写过这么一段Python侧调Node签名的代码结构大概是这样的import subprocess import json def get_signature(params: dict) - str: # params 是需要参与签名的原始参数 result subprocess.run( [node, sign.js, json.dumps(params)], capture_outputTrue, textTrue, encodingutf-8 ) return result.stdout.strip()对应的sign.js文件里就是抠出来的那一段生成签名的JS逻辑。不过这里有个重要提醒别抱着永远破解的念头。平台改版很快今天写好的签名逻辑明天可能就变了。更务实的做法是把签名函数设计成独立的模块平台一改你只需要更新这一小段而不是把整个采集脚本推倒重来。4.3 “算法还原”技术的合规边界这一点我必须单独拿出来说。理解签名算法、做技术研究本身是中性的。但如果你用还原出来的算法去做高频率的数据抓取、绕过平台风控、获取非公开数据那就越界了。我在整个项目里始终坚持三条纪律第一只采集公开页面能直接看到的数据第二控制请求频率不大规模并发第三不采集个人敏感信息。这既是法律要求也是技术人基本的职业操守。5. 实操过程实现一个最小可用的笔记详情采集脚本5.1 从浏览器复制一个请求开始为了避免空谈我以采集某篇公开笔记的基础数据标题、作者、点赞、收藏、评论数为目标带大家走一遍完整流程。第一步在浏览器打开一篇小红书笔记F12打开DevTools进入Network面板刷新页面。在请求列表里找到名为notes/xxx/details不同版本可能不一样特征是返回JSON且包含标题字段的请求右键Copy as cURL。第二步把复制的cURL命令粘贴到终端随便用一个在线cURL转Python的工具转成requests结构。这不是让你直接用而是让你看清这个请求里所有Header和参数的样子。第三步最关键的一步逐个字段确认哪些可以删掉。我会先把cURL转出来的代码放进脚本里跑一遍能正常拿数据然后开始删Header删一个跑一次直到删出问题那删掉的最后一个就是必要条件。通过这种方式把请求精简到最小可用状态后面维护起来也容易。我最终精简出来的请求核心大概是下面这个模样import requests import time import json headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Referer: https://www.xiaohongshu.com/, Origin: https://www.xiaohongshu.com, } def fetch_note_detail(note_id: str, cookies: str) - dict: url fhttps://www.xiaohongshu.com/explore/{note_id} params { source_note_id: note_id, source: explore_feed, } # 这里省略了签名参数的生成步骤 # params[x-s] get_signature(params) resp requests.get(url, headersheaders, cookiescookies, paramsparams, timeout10) resp.raise_for_status() data resp.json() note_detail data.get(data, {}).get(items, [])[0] return note_detail这段代码返回的note_detail是一个嵌套字典里面就有标题、正文、作者信息、互动数据等。听到省略了签名参数生成步骤可能有人会焦虑。但说到底签名生成这个动作是动态变化的一篇罗列具体代码的教程很容易在两周后失效反而是把结构和方法教给你你能自己应对变化。5.2 数据清洗与导出让数据“可用”拿到原始JSON只是第一步。嵌套结构里的字段名往往是英文下划线或驼峰命名比如likedCount、collectedCount直接看会有点懵但对应关系整理清楚后用pandas转成表格就行了。我习惯把关键字段抽出来放在一个字典里再统一转DataFrame。下面这段代码把嵌套的互动数据拍平到一行import pandas as pd def flat_note(raw: dict) - dict: return { note_id: raw.get(id), title: raw.get(title), desc: raw.get(desc), author: raw.get(user, {}).get(nickname), likes: raw.get(interactInfo, {}).get(likedCount), favorites: raw.get(interactInfo, {}).get(collectedCount), comments: raw.get(interactInfo, {}).get(commentCount), shares: raw.get(interactInfo, {}).get(shareCount), create_time: raw.get(time), } rows [flat_note(item) for item in raw_list] df pd.DataFrame(rows) df.to_excel(note_data.xlsx, indexFalse)这样导出的数据表用来做透视、排序、环比都非常方便。比如我想看最近一个月哪个博主的平均点赞最高只要加一列博客名再pivot一下就能出结果。5.3 大批量采集时的频率控制策略少量数据靠请求硬顶是完全没问题的但真正要跑上万个笔记ID必须考虑频率控制。我自己的经验是每次请求之后最少停1到2秒每100次请求停更久一点比如10秒。这一方面是防止给平台服务器造成压力另一方面也是把触发验证码的概率降到最低。还可以引入一种简单的指数退避策略第一次失败等2秒重试第二次失败等4秒超过5次就放弃这条数据标记下来手动补。这种策略不会让你的采集速度突飞猛进但会让整个采集过程稳定很多。稳定是长周期采集最重要的指标。6. 常见问题与排查技巧实录6.1 返回空白或提示“操作频繁”怎么办这是最常遇到的问题遇到它先别慌按顺序排查第一步看请求状态码如果是200但内容是空的检查是不是页面结构换了字段名JSON解析层取错了路径如果是302跳转基本是Cookie失效了重新登录更新Cookie如果直接弹验证码那就是频率太高或者IP被盯上了建议停下来等半小时再用代理换一个出口IP。6.2 签名参数生成了但还是被拒绝这个情况我踩过最深的坑是时间戳不同步。签名算法里往往包含请求发起的时间服务端会校验这个时间戳是否在合理范围内。如果你本机的时间跟服务器时间偏差超过一两分钟签名就会失效。排查方法很简单在签名生成的代码里把时间戳打出来跟浏览器里实际请求的时间戳对比差太多就同步一下系统时间。另一个容易忽略的点是请求体的参与签名问题。有的接口不仅GET参数参与签名POST的请求体也参与。很多人在自测时只改了URL参数忘了在签名函数里把请求体数据也传进去导致签名的值始终对不上。遇到这种情况把签名函数的入参打印出来仔细比对参与计算的字段和实际发送的字段是否完全一致。6.3 7个避免踩坑的细节一是User-Agent里的系统版本、浏览器版本要跟实际环境匹配太离谱的组合容易被识别。二是请求里的顺序其实不重要Header不区分顺序但大小写规范和常见顺序还是别太随意。三是Cookie的持久化建议用requests.Session来管理重定向和Cookie维持都更自然。四是脚本跑了一段时间数据开始变少先检查IP是不是被限制而不是急着改代码。五是所有正则解析都改用JSON路径提取页面的HTML模板一变正则就废但接口的JSON结构相对来说稳定得多。六是日志非常关键每一条请求的URL、状态码、耗时都打出来出问题的时候能快速定位。七是给自己设置一个最大重试次数不做无休止的循环。7. 项目能做什么以及还能往哪个方向延伸脚本写到这里其实已经具备了一个通用框架。你可以把fetch_note_detail改装成搜索接口的请求函数用同一个签名逻辑去跑搜索词就能批量拿到某个关键词下的笔记列表。把笔记ID抽出来去请求详情就得到更完整的数据集。这一套组合拳覆盖了从按关键词发现笔记到按笔记ID获取详情的完整链路。我后来基于这套逻辑做过几个实际应用给一家MCN机构跑过某个细分品类近半年的内容趋势分析笔记标题里的高频词和互动量的关系给自己运营的账号做过一个小的选题辅助工具输入一个关键词返回近期热度最高的笔记和它们的评论区高频情绪词帮我在起标题时避开自嗨型表达。这套框架最大的价值不是写出了多少行代码而是让我掌握了一套观察接口-精简请求-处理异常-结构化数据的方法论。换一个平台换个数据源这套思路依然能打。只是每一次换目标平台都要重新走一遍理解流程的路没有一劳永逸的方案。最后再分享一个我个人的习惯脚本跑完我一定会在本地保留一份当时抓下来的原始JSON备份哪怕已经转成了Excel。因为需求方经常会在你看完数据之后追加一句这个字段的数据还能不能拿到如果原始JSON还在重新解析一下就行如果没了你就得重新去请求又是一轮风控博弈。备份原始数据是这个项目里成本最低、收益最明显的一个好习惯。本文还有配套的精品资源点击获取