做了套小红书一键发布系统，运营小姐姐说她不想离开我了
洛卡卡了约 23 分钟运营小姐姐的烦恼
在我们公司有一个运营部门， 平常要负责把内容发布到抖音、快手、小红书等这些平台。账号类型也很多，有品牌号、合作号、还有专门用来做活动的测试号。 日常的工作量其实不小。尤其一到促销期或者活动期，一天要发好几条笔记，而且要同时覆盖不同的账号。
每次到了活动期，运营小姐姐的电脑上都是好几台手机和几十张图 + N 份文案堆在一起，一天下来要发好几条笔记，还得确保不同账号内容不重样、不出错。她经常一边切账号一边自言自语：“这张图是给哪个号的来着？我刚才发的是品牌号还是活动号？”
以前我们运营部门的流程是这样的：
❝策划把图文和文案打包发给运营，运营打开文件，一条条复制粘贴、上传图片、切换账号、点击发布……
❞
多账号的时候还得来回切换登录，有时候内容顺序搞错了，还得手动撤回重发，前功尽弃。
这种方式不仅「效率低下、容易出错」，而且「让人精神高度紧张」，运营小姐姐经常下班后还得回群里道歉：“刚才发错平台了，我重新发一遍……”
技术出手，只为运营小姐姐少加点班
我每天下班的时候都能看到运营小姐姐还坐在工位上加班，发内容、切账号、贴文案、盯发布进度，一天反反复复几十次。到了活动高峰期，还得深夜返工，改图换文案，一不小心还会贴错内容、发错账号，前功尽弃。
面对运营小姐姐每天这样重复性极高的内容工作流程，我还是看不下去了：
「我决定要用技术打破这一切机械操作。」
于是我打算做一套 「内容统一管理 + 多平台分享集成」 的系统。
所有图文内容、发布素材和话题信息，运营可以提前在后台配置好。确认无误后，只需点击 “一键生成分享链接”，把链接分享到对应设备上，打开就能自动跳转各个平台的发布界面，文案和图片都自动填充，彻底告别人工复制粘贴。
从 “人工发图” 变成“链接跳转”，
从 “复制粘贴” 变成“一键分发”，
用一行代码，换运营十分钟。
运营小姐姐只需要点一下，就能完成过去十几分钟的手工操作。把效率提上来，错误率降下去，让小姐姐能准点下班。
如何实现一键发布小红书笔记
那本篇文章我们就先单独讲一下如何实现用一条链接一键直接将图文和视频内容分享到小红书 App 笔记笔记里的功能。
我们先来看一下平常在小红书 App 手动发布笔记的流程 通常会先点击首页下方的加号按钮 选择要上传的图片或视频 然后输入标题和正文 再选择相关话题 确认无误后点击发布按钮完成发布 下面我放一张示意图方便大家直观理解整个流程
如果是多账号运营，这个过程就要重复好几次，效率非常低。等我们设计好架构接入技术之后，我们就能把整个流程程序化，把要发布的标题、内容、图片集中整理到一个统一的后台页面。运营先添加预发布的文案，在后台点击预览确认没有问题后，就可以生成一个分享链接，再把链接发给其他负责发布的同学。然后打开链接就能直接预览，并且一键快速发布，这就是我们希望实现的最终效果。
实现一键发布前的后台准备
由于项目真实后台涉及敏感配置和接口调用，这里我们用一个简单后台来说明功能设计流程。以下是一个我自己简单搭建的小红书文案管理后台，主要分为两个页面：文案列表页和发布页，分别用于管理文案和录入新文案。
我们先来看文案列表页，如下图展示：
它的主要功能是展示所有待发布或已发布的文案记录。每条文案包括封面图、标题、正文内容、图文数量，以及一组操作按钮，支持 “复制分享链接”、“预览”、“编辑” 和“删除”。通过这些操作，我们可以快速查阅、预览和维护已有文案。
右上角是搜索框和「新建文案」按钮，运营可以通过关键词快速查找历史文案，也可以点击新建按钮跳转到发布页。
下面是发布页的示意图，如图所示：
在这个页面中，我们可以填写文案的标题和正文内容，正文支持 Markdown 格式，方便排版。接着我们可以从素材库中选择需要发布的图片或视频内容。填写完成后，点击底部的「发布文案」按钮，即可提交到后台数据库中。
整个后台的核心流程是：运营先在发布页准备好图文内容并保存，之后可以回到列表页复制分享链接，将链接发送给需要发布的同学，对方点击链接即可跳转到预览页，一键发布到小红书 App 笔记。这种方式大大简化了手动发布流程，尤其适合多账号分工运营场景，能极大提升效率，减少重复劳动。
「后台文案管理功能设计」
为了更方便地管理和发布图文内容，我们设计了一个简单的小红书后台系统。后台主要由两个核心页面组成：「文案列表页」 和 「发布页」，分别用于查看、维护和录入要发布的图文素材。
后台的数据存储基于一张 x_post 表，结构设计如下：
CREATE TABLE `x_post` (`id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键',`type` varchar(20) NOT NULL COMMENT '笔记类型 normal | video',`title` varchar(255) DEFAULT NULL COMMENT '标题',`content` text COMMENT '正文内容',`cover_url` varchar(500) DEFAULT NULL COMMENT '封面图',`image_urls` text COMMENT '图片列表，JSON数组格式',`video_url` varchar(500) DEFAULT NULL COMMENT '视频地址',`is_deleted` tinyint(1) DEFAULT 0 COMMENT '是否删除 0=未删除 1=已删除',`deleted_at` datetime DEFAULT NULL COMMENT '删除时间',`created_at` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',`updated_at` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='发布笔记表';
这张表记录了每篇小红书笔记的关键信息，包括标题、内容、封面、图文或视频链接、删除时间和是否删除等字段。其中 image_urls 是一个 JSON 数组格式，便于存储多图信息，type 字段区分图文和视频类型。
内容创建完后，运营小姐姐就可以通过后台的发布页录入一篇新文案，然后在列表页点击「预览」按钮来查看内容展示效果。（其实我们还可以支持一键导入文案素材的功能）
例如下图就是我们第一篇文案的预览效果页面：
这个预览页面完全模拟小红书 App 内的发布效果，顶部是封面图和内容图集，下面是正文，包括 emoji、换行、图文排版、交通路线推荐等内容。
如果是「多账号运营」，传统做法需要登录多个账号重复上传素材和手动复制粘贴内容，非常低效。而接入我们这个系统后，运营只需提前在后台准备好文案并生成预览链接，分发给不同的发布同事即可。对方打开链接后可以直接查看效果，并一键完成发布操作。
这大大提升了运营效率，尤其是在有多个账号需要同步发布或定时推送内容的场景中，非常实用。
这就是我们后台的整体设计思路。接下来，我们将详细介绍如何与小红书 App 进行联动，实现「一键直达发布页」的功能。通过技术手段进一步简化发布流程，实现图文内容从准备到落地的一体化闭环。
接入小红书分享平台 API
为了实现我们前面提到的 “一键跳转到小红书发布页” 的能力，我们需要借助小红书官方提供的 分享开放平台[1]。它主要面向内容型或工具型的合作应用，提供了 SDK 和相关接口，支持 Android、iOS、HarmonyOS 和 JS 等多种平台。
从官方说明来看，当前支持的能力包括：
「一键分享」：通过开放的接口，第三方 App 或网页可以直接将图文、视频内容分享到小红书，免去了手动复制粘贴和跳转操作，极大提高了分享效率。 「快速发布」：在唤起小红书 App 后，系统会自动识别我们传入的内容类型，比如是图文还是视频。它还支持在发布页挂载话题标签，并根据内容自动推荐标题或话题。这项功能目前仅在 Android 和 iOS 平台支持，HarmonyOS 暂不支持。 「活动运营联动」：我们还可以联动小红书站内的活动，比如双十一、出游季等主题活动。在分享内容时，用户可以直接跳转到这些活动页面，提升曝光率和互动率。不过需要注意的是，这项能力目前同样只在 Android 和 iOS 平台可用。
这些功能意味着，我们不需要自行设计复杂的内容编辑器，也不需要从零搭建视频发布模块，只需准备好基础内容，通过官方提供的 SDK 唤起小红书 App，即可完成整个跳转发布流程。
接入流程
下面是我们使用小红书 JS SDK 整个接入流程的概览图：
从图中可以看出，整个分享流程包括如下关键步骤：
第三方开发者在开放平台官网申请注册应用，平台审核后分配 appKey 和 appSecret； 开发者服务端保管好这些凭证，并在需要调用时计算签名； 签名参数（nonce、sign、timestamp）将下发给前端页面； 页面通过 JS SDK 唤起小红书 App，完成内容分享跳转； 后台可通过 openAPI 配合 JS-SDK 进行鉴权校验。
鉴权签名流程
整个 JS SDK 鉴权流程主要包括以下三步：
「第一步：获取 access_token」
第一次签名操作，使用 appKey、appSecret 等生成加签参数，向 openAPI 请求access_token。「第二步：生成 JS 签名 signature」
获取到 access_token 后，使用appKey + nonce + timestamp + access_token进行再次签名，生成 JS SDK 所需的signature。「第三步：返回签名参数给前端」
服务端将appKey、nonce、timestamp和signature返回给第三方前端，前端可使用 JS SDK 调用分享方法，并唤起小红书 App。
发布分享
在完成了前面的接入流程和鉴权签名后，我们最终要调用的是小红书 JS SDK 提供的分享方法 xhs.share()，这个方法可以让我们唤起小红书 App，并快速填充好要发布的内容。
调用格式大致如下：
xhs.share({shareInfo: {type: 'normal', // 笔记类型，图文用 'normal'，视频用 'video'title: '...', // 笔记标题（可选）content: '...', // 笔记正文内容（可选）images: ['...'], // 图文笔记必填，必须是公网图片地址video: '...', // 视频笔记必填，必须是公网视频地址cover: '...', // 视频封面图，必须是公网地址},verifyConfig: {appKey: '...', // 平台分配的应用唯一标识nonce: '...', // 服务端生成的随机字符串timestamp: '...', // 服务端生成的时间戳signature: '...', // 服务端生成的签名},fail: (e) => {// 调用失败时的处理逻辑}})
这里的 shareInfo 是我们希望填入小红书发布页面的内容信息，主要包括笔记类型（图文 or 视频）、标题、正文、图片或视频地址等；而 verifyConfig 是服务端提前生成的签名鉴权参数，必须由服务器返回，不能由前端自己生成。
下面是每个字段的含义说明：
normal（图文）和 video（视频） | |||
需要注意的是，小红书的 xhs.share() 方法「内置了鉴权流程」，我们只需要提供服务端生成的 nonce、timestamp 和 signature，前端不需要自己参与签名过程。
上面我们已经介绍了接入小红书分享平台 JS SDK 的整个流程，包括平台能力、签名机制以及前后端的配合方式。
接下来我将通过一个简化版本的服务端接口与前端 HTML 页面，来实现一个最小闭环的一键发布功能 Demo，帮助大家快速理解整个流程的落地实现。
服务端接口设计：文案预览与一键发布签名生成
在服务端的逻辑里，我们通常只需要实现两个接口：一个是「文案预览接口」，另一个是一键发布时用到的「分享参数生成接口」。
文案预览接口的作用是：当我们从后台生成了一个分享链接发给同事后，对方打开这个链接时，前端需要能展示出这条小红书文案的内容，比如标题、正文、图片等信息。这时候页面会携带一个唯一的文案 ID（通常是链接里的参数），服务端需要根据这个 ID 去数据库查一下这条文案是否存在、有没有被下架等状态校验，然后把文案信息返回给前端做展示。
而一键发布接口的作用是：当用户点击 “立即发布” 按钮后，前端需要去服务端调用一个接口，这个接口的任务是再次校验文案是否有效，并根据我们接入小红书分享平台的要求，生成所需的签名参数（比如 appKey、nonce、timestamp、signature 等），这些参数会被前端 JS-SDK 拿去唤起小红书 App，实现真正的跳转和发布功能。
接口一：文案预览接口
在我们的后台中，每一条小红书文案都支持 “点击生成分享链接” 的功能。这个分享链接通常会附带一个唯一标识 ID，例如：
https://xxxx.com/share.html?_id=ABY1boZllzPlTiq2这个 _id 就是我们为每一条文案生成的唯一标识，目的是为了让运营或其他同事拿到链接后可以打开预览页面，并看到这条笔记的内容细节。
我们服务端的预览接口设计也非常简单，主要逻辑如下：
「控制器代码」
/*** 预览接口* 示例：GET /api/post/preview/1*/@GetMapping("/preview/{id}")public ResponseEntity<XPost> preview(@PathVariable Long id) {return ResponseEntity.ok(postService.previewPost(id));}
为了方便演示，这里我们使用的是通过 GET 请求访问接口，并直接返回数据库中的文案信息。实际项目中可以根据自己的需求使用更安全或更复杂的方式来处理「分享链接的鉴权与数据访问」。
「Service 层逻辑」
public XPost previewPost(Long id) {return postRepository.findById(id).orElseThrow(() -> new RuntimeException("内容不存在"));}
这个方法会根据文案 ID 去数据库中查询对应的数据。如果找不到，就直接抛出异常提示 “内容不存在”。
通过这个接口，我们就可以在分享链接打开时，自动去服务端拉取对应文案的数据，并渲染在页面中，方便运营预览确认。
「前端预览页面展示效果」
在前面我们已经通过服务端接口拿到了某条文案的详细内容（如图片列表、正文文案等）。这一步我们会基于这些数据，用一个简单的 HTML 页面来完成 “预览页面” 的渲染展示。
这个页面的作用是：当我们在后台生成分享链接并复制给运营后，运营或用户可以通过这个链接在浏览器中打开文案预览页面，确认发布内容是否正确。如果确认无误，还可以点击 “一键发布” 按钮，跳转至小红书 App 完成最终发布。
「示例展示效果」
如下图所示，这是我们通过「微信打开」渲染出来的预览页面效果：
我这个 demo 页面使用了原生 HTML + Tailwind CSS + Swiper 轮播图组件来实现这个页面。代码逻辑非常简单：
页面加载时调用服务端接口 /api/post/preview/{id}获取文案内容；根据接口返回的 imageUrls渲染轮播图；根据 content渲染正文文案；点击 “发布到小红书” 按钮，跳转到下一步一键分享页面。
下面是部分部分代码片段：
<!-- 图片轮播区域 --><divclass="swiper"><divclass="swiper-wrapper"id="preview-images"></div><divclass="swiper-pagination"></div></div><!-- 文案内容 --><divclass="xhs-text"id="preview-text">加载中...</div><!-- 一键发布按钮 --><buttonclass="btn-publish"onclick="publishPost()">发布到小红书</button>
我们通过简单的轮播图 + 段落渲染的方式，让用户在手机上也可以便捷查看预览效果。整个页面在移动端有良好的显示效果，支持微信、浏览器等环境打开。
接口二：一键发布接口：生成跳转小红书所需参数
在完成了预览页面后，接下来我们要实现的就是 「一键发布接口」。这个接口的核心目标是：
当用户在预览页面点击 “发布到小红书” 按钮后，后端生成一组必要的签名参数，并返回给前端，前端再用这组参数跳转到小红书 App 完成笔记发布。
「接口定义」
我们定义了如下接口来支持这个过程：
/*** 发布接口* 示例：GET /api/post/publish/1*/@GetMapping("/publish/{id}")public ResponseEntity<Map<String, Object>> publish(@PathVariable Long id) {Map<String, Object> result = postService.buildPublishResult(id);return ResponseEntity.ok(result);}
这个接口中，id 表示文案在数据库中的主键 ID。我们通过这个 ID 查询文案内容，并为其生成一组带签名的跳转参数。
「配置小红书开放平台的 AppKey 和 AppSecret」
在 Spring Boot 的 application.yml 配置文件中，我们提前配置好了小红书开放平台的 appKey 和 appSecret，用于生成签名参数：
# 小红书分享开放平台配置xhs:app-key: xxxxxxxapp-secret: xxxxxxx
「核心方法：构建发布参数」
接口底层调用的逻辑是：
public Map<String, Object> buildPublishResult(Long id) {XPost post = previewPost(id); // 获取笔记内容// 生成签名部分Map<String, Object> data = generateSignature(id);// 构建分享内容Map<String, Object> shareInfo = new HashMap<>();shareInfo.put("type", post.getType());shareInfo.put("title", post.getTitle());shareInfo.put("content", post.getContent());shareInfo.put("images", ImageUtils.parseImages(post.getImageUrls()));shareInfo.put("cover", Optional.ofNullable(post.getCoverUrl()).orElseGet(() -> ImageUtils.getFirstImage(post.getImageUrls())));shareInfo.put("time", System.currentTimeMillis());shareInfo.put("_id", "xhs_" + post.getId());Map<String, Object> result = new HashMap<>();result.put("data", data); // 签名字段result.put("shareInfo", shareInfo); // 文案内容return result;}/*** 生成小红书发布参数签名* @param postId 文案ID* @return appKey + nonce + timestamp + signature*/public Map<String, Object> generateSignature(Long postId) {// 查询是否存在XPost post = postRepository.findById(postId).orElseThrow(() -> new RuntimeException("内容不存在"));String appKey = xhsProperties.getAppKey();String appSecret = xhsProperties.getAppSecret();String nonce = UUID.randomUUID().toString().replace("-", "").substring(0, 12);String timestamp = String.valueOf(System.currentTimeMillis());try {String signature = SignatureUtil.buildSignature(appKey, nonce, timestamp, appSecret);Map<String, Object> result = new HashMap<>();result.put("appKey", appKey);result.put("nonce", nonce);result.put("timestamp", Long.parseLong(timestamp));result.put("signature", signature);return result;} catch (Exception e) {throw new RuntimeException("生成签名失败: " + e.getMessage(), e);}}
接口返回的结果分为两部分：
「 data部分」：用于跳转小红书所需的签名参数，包括appKey、nonce（随机字符串）、timestamp（时间戳）、signature（签名值），这些字段将作为xhs.share()方法中的verifyConfig参数传入；「 shareInfo部分」：是我们准备要发布的笔记内容，包括type（图文 or 视频）、title（标题）、content（正文）、images（图片地址列表）、cover（封面图）等信息，用于在前端渲染展示和传递给小红书 SDK。
我们测试时实际返回的结构如下所示：
{"shareInfo": {"cover": "http://110.42.233.124/images/dishini.jpg","images": ["http://110.42.233.124/images/dishini.jpg","http://110.42.233.124/images/dishini2.jpg","http://110.42.233.124/images/dishini3.jpg"],"time": 1758188642421,"_id": "xhs_1","type": "normal","title": "一张图讲清楚上次迪士尼交通攻略🚇","content": "一张图讲清楚上次迪士尼交通攻略🚇\n有多少宝子去迪士尼光是研究交通就费了好大劲。。。"},"data": {"signature": "2486268ecfa3886b7fc4cd1d1fcbda5381b3177f96daf5f1e4dd09b938f94d4f","appKey": "red.96juc55xxxx","nonce": "10e07cfc400c","timestamp": 1758188642420}}
前端拿到这组数据后，只需要将 shareInfo 和 data 传入小红书 SDK 的 xhs.share() 方法中，即可完成跳转与笔记预填。
「签名生成工具类：SignatureUtil.java」
小红书分享 SDK 的调用需要进行签名认证，为此我们封装了一个简单的工具类，用于生成 SHA256 签名，核心思路是：
将 appKey、nonce、timestamp等参数排序；拼接成 key=value&key2=value2...的格式后追加appSecret；使用 SHA-256 进行加密并返回十六进制字符串。
/*** 小红书签名生成工具类*/public class SignatureUtil {/*** 构建签名** @param appKey 应用唯一标识* @param nonce 随机字符串（建议12位）* @param timestamp 当前时间戳（毫秒）字符串格式* @param appSecret 应用密钥* @return 签名字符串（SHA-256 Hex）*/public static String buildSignature(String appKey, String nonce, String timestamp, String appSecret) throws Exception {Map<String, String> params = new HashMap<>();params.put("appKey", appKey);params.put("nonce", nonce);params.put("timestamp", timestamp);return generateSignature(appSecret, params);}/*** 签名生成逻辑* @param secretKey 秘钥* @param params 参数 map* @return 签名字符串*/public static String generateSignature(String secretKey, Map<String, String> params) {// Step 1: 排序参数Map<String, String> sortedParams = new TreeMap<>(params);// Step 2: 拼接参数字符串（key=value&...）+ secretKeyStringBuilder sb = new StringBuilder();for (Map.Entry<String, String> entry : sortedParams.entrySet()) {if (sb.length() > 0) sb.append("&");sb.append(entry.getKey()).append("=").append(entry.getValue());}sb.append(secretKey); // 拼接密钥// Step 3: 进行 SHA256 签名try {MessageDigest md = MessageDigest.getInstance("SHA-256");byte[] hashBytes = md.digest(sb.toString().getBytes(StandardCharsets.UTF_8));// 转十六进制StringBuilder hex = new StringBuilder();for (byte b : hashBytes) {hex.append(String.format("%02x", b));}return hex.toString();} catch (NoSuchAlgorithmException e) {throw new RuntimeException("SHA-256算法不可用", e);}}}
「图片处理工具类：ImageUtils.java」
因为我们数据库中 image_urls 字段是 JSON 数组格式（如 ["url1", "url2", "url3"]），前端展示和分享时需要将其解析成 List<String>，我们封装了如下工具类：
parseImages()：将数据库的 JSON 格式或逗号分隔的图片字符串，解析为图片地址列表。getFirstImage()：获取列表中的第一张图，作为默认封面图。
/*** 图片处理工具类*/public class ImageUtils {private static final ObjectMapper mapper = new ObjectMapper();/*** 将 imageUrls 字段解析为图片地址列表* @param imageUrls 数据库中的 imageUrls 字段* @return List<String> 图片地址列表*/public static List<String> parseImages(String imageUrls) {if (imageUrls == null || imageUrls.isBlank()) return Collections.emptyList();try {// 如果是 JSON 数组格式if (imageUrls.trim().startsWith("[")) {return mapper.readValue(imageUrls, new TypeReference<List<String>>() {});} else {// 普通逗号分隔格式return Arrays.stream(imageUrls.split(",")).map(String::trim).filter(s -> !s.isEmpty()).collect(Collectors.toList());}} catch (Exception e) {return Collections.emptyList(); // 解析失败返回空列表}}/*** 获取图片中的第一张图（封面用）* @param imageUrls 数据库中的 imageUrls 字段* @return 第一张图片地址或 null*/public static String getFirstImage(String imageUrls) {List<String> images = parseImages(imageUrls);return images.isEmpty() ? null : images.get(0);}}
「前端跳转页实现（跳转小红书 App 分享）」
在我们前面实现的文案预览页中，点击 “一键发布” 按钮后，会跳转到一个中间页，这个页面的作用是：
检查用户当前的浏览器环境（是否是微信、是否是 Android）； 请求服务端接口，获取真实的文案内容 + 签名参数； 自动调用小红书开放平台提供的 xhs.share()方法，引导用户跳转并打开小红书 App 进行发布。
「判断浏览器类型与环境」
前端页面在加载时，会首先通过以下代码判断当前浏览器环境：
const u = navigator.userAgent.toLowerCase();const isAndroid = u.includes('android') || u.includes('adr');const isWeixin = u.includes('micromessenger');const params = Object.fromEntries(new URLSearchParams(location.search).entries());const id = params.id;const appKey = params.appKey;const nonce = params.nonce;const timestamp = params.timestamp;const signature = params.signature;// 如果在微信中提示用户跳出if (isAndroid && isWeixin) {document.getElementById("tips").style.display = 'block';} else {goShare();}
这一段逻辑我们简单做了几件事：
从浏览器的 userAgent中判断用户是否使用的是 「安卓设备」，以及是否是在 「微信浏览器中打开」。如果是在微信中打开，则无法直接跳转小红书 App，因此我们会弹出提示，要求用户 “点击右上角 -> 浏览器打开”。 否则，说明环境已满足跳转条件，我们会直接调用 goShare()方法进入分享流程。
「请求服务端接口，校验并返回参数」
当满足环境条件后，页面会自动调用我们之前实现的第二个接口 /api/post/publish/{id}，用于服务端校验文案真实性，并返回跳转小红书所需的加密参数。代码如下：
const res = await fetch(`http://110.42.233.124:8888/api/post/publish/${id}`);const json = await res.json();const { data: verifyConfig, shareInfo } = json;
「调用小红书 SDK 的分享能力」
一旦我们拿到 verifyConfig（签名参数）和 shareInfo（图文内容），就可以正式调用小红书的 SDK 进行分享：
xhs.share({shareInfo: {type,title,content,images,...(type === 'video' ? { video, cover } : {})},verifyConfig: {appKey: verifyConfig.appKey,nonce: verifyConfig.nonce,timestamp: verifyConfig.timestamp,signature: verifyConfig.signature},fail: (e) => {console.error('小红书分享失败：', e);alert('小红书分享失败: ' + JSON.stringify(e));}});
这个方法会自动拉起小红书 App 并进入发布页，用户可以直接确认发布内容。
最终效果
以下是我们实际测试中跳转页的样式效果示意（「图片有点大，耐心等待一下.....」 ）包含提示引导和自动跳转逻辑：
从图中流程我们可以看到，我们打开了后台给到的分享链接后，我们就可以进入第一个文案预览页面。当我们点击预览页面中的「一键发布」按钮后，页面会自动跳转至我们前面实现的中间页（分享跳转页）。整个过程的用户体验如下：
「提示离开微信（或浏览器）」
如果用户是在微信中打开链接，系统会自动弹出提示，提示用户 “即将打开第三方 App”，引导用户点击右上角菜单，选择「在浏览器中打开」。「自动跳转小红书 App」
当用户点击继续，或在普通浏览器中打开时，页面会自动调用小红书开放平台的跳转能力（xhs.share），此时会拉起小红书 App。「自动进入发布页，内容已填充」
成功跳转后，用户会直接进入小红书的发布页面，不需要再手动粘贴内容：
文案标题和正文内容已自动填写； 所选图片已经预先加载为图文笔记的图组； 下方的「话题」也已经贴上； 如果是视频内容，则会自动带上封面图与视频资源。
也就是说，「用户只需要点几下，就能一键跳转到小红书 App 发布笔记，几乎不需要做任何额外操作」，整个过程简单快速，适合后台批量生成内容后，由运营一键分发。
这一套跳转流程适用于图文与视频类型的内容，不需要接入小红书 App SDK，只需要后台生成好内容和签名，前端发起跳转即可。
进阶设计：多设备自动发布与后台数据统计
到这里，我们已经完成了整套 “小红书文案一键发布” 的实现流程，用户只需点击跳转，就能将指定文案快速填充到小红书 App 的发布页面。
但如果放在实际业务中，这还只是第一步。
目前这种方式仍然依赖人工操作 —— 也就是说，我们还是需要每台手机手动打开链接、点击发布，才能完成整个笔记的投放过程。
而在真实的项目实践中，我们已经做到了 「“机器化发布”」：通过技术手段控制多台手机（甚至几十上百台设备）同时打开指定链接、自动触发跳转与发布动作，极大地提升了投放效率，节省了大量人力。
此外，「后台系统也支持发布数据的实时统计」，例如：
哪些账号已成功发布； 每条文案的发布状态； 相关数据是否回传成功（如小红书笔记的曝光量、点赞量等）； 发布失败的情况排查与补投管理。
当然，这部分内容就不展开讲了，有兴趣的同学可以进一步了解在分发调度、设备联控、账号管理等方面的实践方案。
用后台赋能一对多教学，打造自己的 “小红书孵化器”
这套系统除了用于团队运营，其实对「独立开发者、个人博主、内容培训者」也非常实用。
以我自己为例，比如我现在在做「教粉丝小红书起号」的副业。但如果每位粉丝都要我手动发图、写文案、传视频，再一个个教他们怎么发笔记，不仅效率低，还特别容易出错。
于是我直接用自己搭的 “小红书发布系统” 来做教学工具：
我在后台准备好文案、话题、图片 / 视频； 系统自动生成「发布跳转链接」； 然后我把这个链接生成「限时二维码」，发给粉丝； 粉丝扫码后，点击 “一键发布”； 自动跳转到小红书 App，文案和素材都粘贴好了，直接发布即可。
这样我就可以用「一套系统同时带多个账号起号」，效率极高，不用再反复教每个人怎么贴图、加话题、排版、复制文案。
甚至还可以统计哪篇文案被谁用了，效果怎么样，方便后续优化内容策略。
所以说这套系统已经不只是一个 “分享工具”，更是我做小红书教学、孵化账号的「内容分发中枢」了。
更多平台的扩展实践：从小红书到全平台统一管理
小红书虽然是目前最热门的图文笔记平台之一，但它的 JS SDK 和分享 API 对接起来其实非常简单。我们前端只要把参数拼好，直接调用 xhs.share()，就能一键跳转到 App 发布页面。
也正因为这种接入方式足够 “轻量、稳定”，我们很快发现：
❝「同样的模式，可以复制到更多平台。」
❞
除了小红书，我们还陆续接入了抖音（抖音开放平台[2]）、快手（快手开放平台[3]）、B 站（哔哩哔哩开放平台[4]）、微博（微博开放平台[5]）等多个平台，把 “一键发布” 做成了一个真正的统一系统。
最后我们搭建出了一个 「“内容发布中台”」 ：
后台统一配置文案、图片、视频等素材； 前端页面自动生成跳转链接； 多平台同时分发，减少人工操作； 实时回传发布状态，统一统计效果数据。
这样一来，无论是日常运营，还是品牌推广，都能用最少的人力，把内容快速推送到所有目标平台，实现最高效的触达。
技术也能让运营小姐姐更轻松
这一套 “小红书一键发布” 系统，其实技术上并不复杂，前端甚至就一行 xhs.share(...)。但当我们把流程统一、配置集中、权限收敛、参数自动化后，整个团队的节奏就变了。
以前运营小姐姐每天得在文案、图片、账号之间来回切换，错一个字就要撤回重发，现在她登录后台挑好文案，一键生成链接，分享到手机点一下，直接跳进 App 就能发笔记，图文话题全自动贴好。
从 “复制粘贴” 到“一键跳转”，从 “账号切来切去” 到“后台统一分发”，
连她自己都说：“以前像搬砖工人，现在像点菜经理。”
最重要的是：
她终于可以准时下班了。
我们现在还接入了设备控制、状态检测、效果回传，如果后面再接个大模型自动生成文案，她可能连选图都不用了，坐着喝奶茶就能把内容分发搞定。
这也让我明白一件事：
不是运营不努力，而是工具不给力。
技术如果能让人少加点班、多留点发际线，那就值得去做。
这其实就是一个非常典型的例子：技术可以改变运营效率，甚至直接降低人力成本。
未来当我们再结合 AI 大模型（比如自动生成文案、图片审核、内容风格推荐等），这个平台的自动化能力还可以再上一个台阶。
所以哪怕只是一次小小的集成，也值得认真打磨。它的价值，可能比我们想象中更大哦。