企业官网建设流程全解析

链接失效这事儿，换谁遇到都想骂人。

前阵子我刚收藏的一篇民宿体验笔记，隔天再点开就变成了“该内容暂时无法查看”，作者删号了还是被平台下架了，反正是连个招呼都没打。没过几天，我自己发的一条装修避坑干货也被提示“涉及违规”直接锁了，后台申诉都没通过。更常见的是微信聊天里那个小红书的分享卡片，点击去要么打不开，要么提示“链接已暂停访问”。

我原本想着“反正收藏里存着呢”，结果收藏本身就是个链接，源头没了，收藏就给个404。

这个项目说白了就是在解决“链接失效”这件事：用两种思路把小红书笔记的内容本身——文案、图片、视频、结构化数据——完整保存到本地，让链接有没有都不影响后续阅读和复用。第一种方法零基础，适合单条、少量、重要的笔记；第二种方法涉及API调用技巧，适合批量归档，也是这篇文章想重点展开的部分。

如果你是经常用小红书收藏攻略的普通用户，或者你自己做内容、需要管理几十上百条笔记素材，这篇都值得花几分钟看完。

1. 链接失效的本质，与两种保存策略的取舍

1.1 链接失效的三个典型场景

先梳理一下“链接失效”到底是怎么发生的，这事不能只归咎于“作者删了”。

第一个场景是作者主动删除。博主把账号注销了、笔记设置了私密、编辑时把某些内容移除，分享链接自然就断。这个没法怪平台，是原始发布者的意愿。

第二个场景是平台被动下架。笔记因为涉嫌违规、诱发争议、被多次举报等原因被审核锁定。这个是最折磨人的，因为你可能什么都没做错，甚至只是文字里有一个敏感词被算法误伤，笔记就卒了。我自己的那条装修笔记就属于这一类。

第三个场景是分享渠道的临时限制。小红书链接分享到微信、QQ里，经常被内置浏览器拦截；在部分第三方App里直接打开也容易跳到一个“提示风险”的中间页。这种情况下链接其实没死，但用户体验上完全等于死。

不管是哪种，它们指向同一个真相：链接不是一个资产，它只是一个门牌号。门牌号被拆了，你记住门牌号也没用，真正要留下的是房子里的东西——文字、图片、视频、作者信息、发布时间。

1.2 理解“永久保存”的正确姿势

很多人一听“永久保存”，下意识以为存在自己手机相册里就算永久了。我见过有朋友把小红书笔记全部截图存在手机里，结果手机一换、微信一清，全部归零。

永久保存的含义包含两层：一是内容要完整，不能只截个开头、漏掉关键信息和配图；二是存储要可靠，不能在单一介质上只存一份。

所以我的项目思路是两条腿走路：

• 手动全量归档法：适合单条笔记，以截图、原图保存、正文复制、视频录屏为核心，配上规范的目录和多种备份介质。
• API自动抓取法：适合批量笔记，通过接口调取结构化数据，把笔记解析成Markdown、图片文件、视频文件，自动落盘。

两条腿不冲突。我现在自己的习惯是：朋友发来的重要链接、自己发的高价值笔记，当周手动归档；季度性的大批量素材，走API批量备份。下面两章分别把这两条路的细节讲透。

2. 方法一：手动全量归档，链接失效前把内容“搬回家”

先说这个零基础版本。听起来很土，但哪怕是我这种常年写脚本的人，遇到真正重要的笔记，也会第一时间先用这套方法做一次兜底——因为API可能会挂、签名会变、Cookie会过期，但你自己花五分钟把内容存下来，永远是最稳的。

2.1 图片、视频、正文的完整保存动作

打开一篇还没失效的笔记，按下面的顺序操作，基本不会漏：

图片素材的处理，很多人的误区是“截图”。截图会损失分辨率，小红书笔记里的原图清晰度远高于屏幕截图，所以正确的姿势是长按图片，选择“保存图片”。我自己做过对比，一张2000像素宽的原图和截屏在电脑上看缩放后差距非常明显。如果遇到某些笔记不支持长按保存，退而求其次再截图，尽量截单张而不是拼屏截图。

视频素材要区分情况。自己发布的笔记，在App内可以直接“保存视频到相册”，这是无损路径。别人发布的笔记大多数没有下载按钮，我一般用系统录屏功能把视频完整录下来，iOS和Android都自带录屏，分辨率选1080P以上即可。录的时候注意打开声音，小红书部分视频走的是无声BGM，这个还好，但如果你只看画面不看字幕，很容易漏掉信息。

正文部分的采集，我强烈建议不要只用截图。截图没法检索、没法二次编辑，复制文字才是正道。在笔记页长按正文，Android上可以直接全选复制，iOS如果遇到复制受限，就把字体调最大再滚动截图，然后用“文本识别”功能（iOS实况文本、小米传送门都行）转成可复制的文字。我现在会直接把正文粘贴进一个Markdown文件里，标题、标签、发布时间、作者名一起记下来。

2.2 长截图的正确打开方式

说一个关于滚动截图的细节。

手机自带的滚动截屏看起来简单，实际用起来有坑：小红书页面底部会加载“相关推荐”，滚动截图时非常容易把推荐内容也截进去，导致你截了一大张图，但中间笔记正文只有一小段，后面全是推荐流。

我的做法是，进入笔记后先点击正文区域，把底部推荐流划走或者等页面加载完，然后快速滚动截图；更稳的方式是分段截图。比如一篇2000字的笔记，我截三段拼一下，每段之间的重叠部分留10%左右，后面用系统相册的编辑功能或第三方拼接工具接起来。避免用那些有广告的全屏拼图App，我踩过坑，导出的图片底部自带水印，特别烦。

2.3 归档目录结构的规范化设计

手动归档最怕的就是“随手存”，存完了自己都找不到。我踩过几次找资料的坑之后，把归档目录固定成下面这套结构：

小红书笔记归档/ 2025-03-15_装修避坑指南/ 封面.jpg 图片_01.jpg 图片_02.jpg 视频.mp4 正文.md 来源信息.txt

• 文件夹名 = 日期_主题，不用笔记原标题，因为小红书标题经常很长还带emoji，做文件名会有各种兼容问题。
• 正文.md 里存的是文本化后的笔记正文，以及补充的标签和发布时间。
• 来源信息.txt 记录笔记ID、作者昵称、原始链接、抓取时间。别小看这个文件，等以后链接真的失效了，它是唯一能证明“这个东西确实存在过”的凭证。

主题的命名建议用“领域_关键词”，比如“装修_瓷砖美缝”“旅行_大理环海”，以后要按类目找会很方便。

2.4 3-2-1备份原则的日常落地

“永久保存”不能只放在一个地方。我做内容这行，硬盘坏过两次，教训非常深刻。

现在我的备份方案是三层：

• 主工作区：电脑本地硬盘一份，日常编辑和管理用。
• 备用介质：移动机械硬盘一份，每月初同步一次。
• 异地副本：网盘一份，选一个不常打开但别总弹广告的（我用的是阿里云盘，上传不限速，存图片视频比较舒服）。

这就是业内常说的3-2-1原则：3份副本，2种不同介质，1份存放于异地。

不用觉得麻烦，现在网盘同步都很智能，你只要建好文件夹、把归档文件夹拖进去，剩下交给同步程序。真正要防的是“只有一个手机、一张SD卡”这种单点，手机掉了就啥都没了。

3. 方法二：API自动抓取，批量归档的正确姿势

手动归档一次处理一两条还行，要是手里积压了80条笔记素材，一条条截图复制能把人整疯。这时候就得上一套自动化的方案：通过API调用把笔记的结构化数据拿下来，落盘成文件。

这段是整个项目里技术含量最高的部分，也是大家最关心的“API调用技巧”，我尽量用容易懂的方式讲。

3.1 从链接链路看懂数据从哪来

先说个基础认知：你在小红书网页版打开一篇笔记时，浏览器并不是直接把文字画在页面上的，它是通过一个后台接口请求，拿到一份包含标题、正文、图片地址、视频地址等信息的JSON数据，然后在前端渲染成页面。

也就是说，只要我们找到这个接口，模拟浏览器发一次请求，就能“绕过”页面渲染，直接拿到最干净的源数据。

这个思路在所有内容平台几乎通用，小红书也只是其中一例。顺着这个思路走，第一步就是从链接里提取笔记ID。

像这条链接：

https://www.xiaohongshu.com/explore/6425e4d0000000001201a1c5

中间的6425e4d0000000001201a1c5就是笔记的唯一ID。它像身份证号一样，一条笔记对应一个ID，通过这个ID就能定位到平台数据里的那条记录。

3.2 环境准备：Python、requests、Cookie

API调用需要一点编程基础，但不需要很高级。我用的是Python，装了requests库就够。

pip install requests

然后是Cookie。小红书网页端的接口要求带登录态，也就是Cookie字符串。获取方法很简单：

• 浏览器登录小红书，按F12打开开发者工具
• 切到Network（网络）面板，刷新页面
• 随便点开一个请求，在Request Headers（请求头）里找到Cookie:开头的那一大段字符串，复制下来
• 这段字符串会不定期失效，建议当天使用

Cookie的作用相当于你的登录凭证。没有它，很多接口会直接返回未登录或风控错误。它也不需要搞什么高深技术，就是复制粘贴。

3.3 核心调用脚本实战

写一个最精简的脚本，目标是：输入链接，提取ID，请求详情接口，打印结果。

import requests import re import json BASE_URL = "https://www.xiaohongshu.com" HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Cookie": "你的Cookie字符串放这里", "Accept": "application/json, text/plain, */*", "Referer": "https://www.xiaohongshu.com/", } def extract_note_id(url: str) -> str | None: match = re.search(r"/explore/([a-f0-9]+)", url) return match.group(1) if match else None def fetch_note(note_id: str): url = f"{BASE_URL}/api/sns/web/v1/feed" payload = {"id": note_id} resp = requests.post(url, json=payload, headers=HEADERS, timeout=10) return resp.json() if __name__ == "__main__": link = input("请输入小红书笔记链接: ") note_id = extract_note_id(link) if not note_id: print("链接格式不对，没法提取ID") exit() print(f"笔记ID: {note_id}") data = fetch_note(note_id) print(json.dumps(data, ensure_ascii=False, indent=2)[:1000])

这个脚本跑通之后，你会看到控制台输出一大段JSON。里面就是这篇笔记的完整结构化数据。

3.4 返回数据的解析与本地化

接口返回的JSON结构大体是下面这样（字段名会随平台版本更新，但大方向稳定）：

{ "code": 0, "data": { "title": "装修避坑指南", "desc": "瓷砖美缝这样做才不出错……", "imageList": [ { "urlDefault": "https://sns-img-hw.xhscdn.com/xxxxx", "width": 1080, "height": 1440 } ], "video": { "url": "https://xxx.xhscdn.com/xxx.mp4" }, "user": { "nickname": "某博主", "avatar": "https://xxx" } } }

拿到这份JSON，接下来就是“转储”——把数据变成我们能长期保存的文件。我的完整脚本会做四件事：

1. 创建以笔记ID为名的目录
2. 把desc写入正文.md
3. 遍历imageList下载所有图片到images/目录
4. 保存来源信息.txt

图片下载时最容易踩的一个坑是防盗链。如果不带Referer头，很多图片会返回403。所以下载图片时要额外加一个请求头：

IMG_HEADERS = { "User-Agent": "Mozilla/5.0", "Referer": BASE_URL + "/explore/" + note_id, } def save_image(img_url: str, filepath: str): r = requests.get(img_url, headers=IMG_HEADERS, timeout=15) with open(filepath, "wb") as f: f.write(r.content)

视频同理，下载时也要带上TopCookie和Referer，否则大概率拿到一个空文件或者错误页。

3.5 API调用技巧与注意事项

这一节我单拎出来讲，因为实际跑通接口和“在文档里看着能用”完全是两码事。

第一个技巧是频率控制。个人归档场景，请求频率不要超过每分钟10次，抓一条sleep个3到8秒，基本不会被风控盯上。我之前测试时因为跑循环没加sleep，连续请求了二三十次，直接触发了滑块验证，还要自己手动过验证，得不偿失。

第二个技巧是Cookie定期更新。Cookie不是永久有效的，我一两周就得重新登录一次。为了省事，我把Cookie放在一个单独的环境变量或者config文件里，过期时只改一处，不用去翻脚本代码。

第三个技巧是容错设计。接口返回的字段经常变化，imageList可能某天变成image_list，video可能变成videoList。写解析逻辑时，全部用字典的get方法层层取，不要直接data["data"]["imageList"]，否则字段一改就崩。

第四个技巧是日志记录。我每次跑批量任务，会把处理过的笔记ID追加到一个done.txt里，下次跑之前先读取这个集合，跳过已经处理过的。这样哪怕中途脚本崩了，重跑也不会产生重复文件。

最后必须强调一句合规边界：这套方法适合处理你自己发布的笔记、你明确有权限备份的内容，不适合大规模抓取别人的隐私数据。如果你拿去做商业化采集，账号风险和法律责任你得自己掂量。

4. 高频问题排查实录与避坑总结

4.1 常见问题速查表

我把自己踩过的、以及朋友问过的问题整理成一张表，基本覆盖了90%的坑：

其中-100这个错误码是很多人的噩梦，这里单独展开聊一下。

4.2 签名校验与Cookie的应对思路

小红书网页端接口目前对请求签名有一定的要求，签名参数通常长这样：x-s、x-t这类字段。它们是在前端JS中动态生成的，用来证明“你不是一个自动脚本”。如果只带Cookie不带签名，接口就会返回-100。

很多入门教程会让你去找前端的JS文件、断点调试、抠加密函数，这条路能走通，但维护成本极高——平台改一次前端签名逻辑，你的代码就废一次。

我个人的应对思路比较务实，分享两种“不跟签名硬刚”的办法：

第一种是浏览器半自动抓包。在开发者工具里手动操作页面，触发笔记详情接口，然后把响应体的JSON复制出来，用脚本离线解析、落盘。这样签名验证由浏览器帮你完成了，你要做的只是解析数据。缺点是每次只能手动复制，适合几十条以内的场景。

第二种是直接调用官方开放平台。如果本来就是做品牌的，可以申请小红书的专业版/企业号开放接口，平台会发完整的API文档，不涉及任何逆向。缺点是申请门槛高、个人用户很难拿到权限，而且接口配额也有限。

对大多数人来说，第一种办法就已经够用。别被那些“全自动采集”的演示视频带偏了，真正用得长久的方式，往往是看起来慢但稳的。

4.3 手动归档里的隐藏坑

API有API的坑，手动归档也有几个容易被忽视的细节，值得一并提醒：

一个是别漏标签和话题。小红书笔记正文里带的#小红书露营季这种话题标签，是内容信息的重要一部分，复制正文时很容易漏掉。我习惯把标签放在正文末尾，用单独一行记录，方便以后做分类。

另一个是图片要保留原始分辨率。通过长按保存的图片，如果原图本身分辨率不高，也不要强行放大去存，存原尺寸即可。放大不仅不会清晰，还会让文件变很大，浪费存储空间。

还有一个是**“相关推荐”污染**。如果你在页面停留过久，底部会出现大量推荐笔记。手动截图时一定要把页面顶到正文区域再截，否则很容易把推荐内容当正文截进去。我也犯过这种低级错误，归档了一条旅行攻略，结果翻图片时发现三张截图里有两张是推荐流里的民宿广告。

5. 归档工作流的个人实践体会

5.1 我的“一周一归档”节奏

做了这个项目之后，我给自己定的节奏是：每周日晚上拿出15分钟，把本周发布的、收藏的、朋友分享的重要笔记做一次手动归档。数量控制在5条以内，走方法一，非常轻松。

遇到季度性的整理需求，比如要整理一篇长文的素材，再上API批量备份。我自己目前维护着两个目录：一个是日常速存，随手丢东西用的；一个是正式归档，按日期和主题整理过、有完整来源信息的。定期把日常速存里的东西清理到正式归档里，顺手删掉明显不要的内容，这个动作比任何自动化都有效。

5.2 从单条备份延伸到内容资产管理

这个方法跑通之后，我慢慢地不只想保存小红书笔记了，开始把公众号文章、知乎回答、B站视频简介也用类似思路做归档，甚至把每条原始链接的标题、作者、抓取时间都记在一个Excel表里，相当于给自己建了一个小型的内容资产库。

后续我还打算把这个流程接到NAS上，用定时任务每周自动跑一次增量备份，把归档目录同步到另一块硬盘。整个过程并不复杂，核心就是要形成“链接会失效，内容才值钱”的意识，然后让保存动作变成肌肉记忆。

我在实际操作中最深的一个体会是：比起临时抱佛脚地等链接失效后再后悔，更重要的还是把“归档”这件事排进日常的例行清单里。宁可多花五分钟保存，不要等到链接真没了才抓狂。这大概也是这个项目带给我最大的价值。