social-auto-upload 小红书 Uploader 浅层对齐重构patchright 扫码登录、Cookie 校验与视频/图文双入口【免费下载链接】social-auto-upload自动化上传视频到社交媒体抖音、小红书、视频号、tiktok、youtube、bilibili项目地址: https://gitcode.com/GitHub_Trending/so/social-auto-upload本文基于仓库内的实施计划文档 2026-03-25-xiaohongshu-shallow-alignment.md完整还原 social-auto-upload 项目中「小红书浏览器端 Uploader 与抖音/快手风格对齐」这次浅层重构的目标、架构边界与四个落地任务。读完你可以掌握如何用 patchright 搭建可轮询的小红书创作者中心扫码登录流程、xiaohongshu_setup的return_detail结果载荷契约、Cookie 有效性校验原理以及XiaoHongShuVideo/XiaoHongShuNote两个正式发布入口的复用结构并能直接复现计划中的测试与验证步骤。1. 计划目标与范围边界这是一份面向 Agent 工作流的实施计划Plan其头部约定由superpowers:subagent-driven-development推荐或superpowers:executing-plans技能逐任务执行步骤用- [ ]复选框跟踪。计划定义了三个核心要素Goal目标让基于浏览器的小红书 Uploader 与当前抖音/快手风格对齐具体体现在三个方面——登录二维码QR流程、patchright 的使用方式、正式的视频/图文video/note入口点同时明确不扩展到 CLI 或文档工作。Architecture架构把改动收敛在 uploader/xiaohongshu_uploader/main.py 内部作为一次浅层重构shallow refactor。先引入一条薄的登录流程包含二维码提取、Cookie 校验与结果载荷result payload再新增一个共享的基类 Uploader以及各自复用公共初始化逻辑的视频和图文浏览器流程。Tech Stack技术栈Python、patchright、异步 Playwright 兼容的浏览器自动化async Playwright-compatible browser automation、unittest。浅层的含义可以从最终代码边界印证登录逻辑、校验逻辑、两个发布器类全部位于uploader/xiaohongshu_uploader/main.py单文件内跨文件依赖仅指向公共工具层utils/login_qrcode.py、uploader/base_video.py、utils/base_social_media.py的set_init_script与配置模块conf。CLI 层 sau_cli.py 只是消费该模块导出的公开名称本次计划本身不改 CLI 代码。2. Task 1先用测试锁定登录/校验的预期行为计划的第一步是测试先行涉及文件Create:tests/test_xiaohongshu_uploader.pyModify:uploader/xiaohongshu_uploader/main.py三个步骤为xiaohongshu_setup(..., return_detailTrue)的无效 Cookie 行为与 Uploader 的校验行为添加测试运行目标测试文件确认它因预期中的缺失行为而失败实现满足这些测试的最小生产代码改动。当前仓库的 tests/test_xiaohongshu_uploader.py 正是这一步的产物其中与登录/校验契约直接相关的用例有test_setup_returns_detail_when_cookie_invalid_without_handlemock 掉os.path.exists返回False后调用xiaohongshu_setup(missing.json, handleFalse, return_detailTrue)断言返回字典success为False、status为cookie_invalid。这锁定了无效 Cookie 时不弹浏览器、直接给出结构化结果的契约test_setup_uses_login_flow_when_handle_is_truemockxiaohongshu_cookie_gen为AsyncMock断言当handleTrue且 Cookie 缺失时xiaohongshu_setup恰好等待await一次登录流程并透传其结果test_video_validate_upload_args_normalizes_video_and_thumbnail与test_note_uploader_exists_and_validates_required_fields锁定XiaoHongShuVideo/XiaoHongShuNote的参数校验行为文件路径归一化、图文缺图片时抛ValueError。测试文件用FakeLocator/RecordingPage等轻量替身替代真实浏览器对象使登录页定位与fill_meta行为可以在无浏览器环境下做纯单元验证。3. Task 2核心重构——patchright、扫码登录流程与双入口这是计划中最重的一步包含三个子项逐项对应到源码。3.1 浏览器自动化层从playwright.async_api切换到patchright.async_apiuploader/xiaohongshu_uploader/main.py#L10-L12 中模块的所有浏览器类型与入口均来自 patchrightfrom patchright.async_api import Page from patchright.async_api import Playwright from patchright.async_api import async_playwright整个模块cookie_auth、xiaohongshu_cookie_gen、两个发布器的upload方法全部通过async with async_playwright() as playwright驱动与抖音/快手 Uploader 的写法保持同一风格发布器启动浏览器时统一使用playwright.chromium.launch(headlessself.headless, channelchromium)。headless默认值来自 conf.example.py 的LOCAL_CHROME_HEADLESS示例配置默认为True并支持本地 Chrome 路径LOCAL_CHROME_PATHcookie_auth中若配置了该路径则以executable_path启动。3.2 用二维码提取 终端打印 文件保存 轮询 Cookie 持久化替换page.pause()登录旧式登录依赖page.pause()人工在 Inspector 里等待扫码重构后的xiaohongongshu_cookie_gen正确拼写为xiaohongshu_cookie_gen见 main.py#L242-L306是一条完全可编程的流水线async def xiaohongshu_cookie_gen( account_file, qrcode_callbackNone, poll_interval: int 3, max_checks: int 100, headless: bool LOCAL_CHROME_HEADLESS, ):关键参数与行为参数默认值作用account_file必填Cookiestorage_state落盘路径通常为cookies/xiaohongshu_uploader/account.jsonqrcode_callbackNone可选回调二维码就绪时收到{image_path, image_data_url}载荷支持同步与异步awaitable回调见_emit_qrcode_callbackpoll_interval3秒每轮登录是否完成检查之间的间隔max_checks100次轮询上限即最长约 5 分钟的扫码等待窗口headlessLOCAL_CHROME_HEADLESS无头模式下会明确提示小人会输出终端二维码并保存本地二维码图片流程拆解对应计划中 QR extraction → terminal printing → QR file saving → polling → cookie persistence 五个环节打开登录页并提取二维码。page.goto(_build_xhs_creator_url(/login))之后_save_xhs_qrcodemain.py#L128-L160依次经过_open_xhs_qrcode_panel若登录框默认不是扫一扫面板则点击img.css-wemwzq切换与_find_xhs_qrcode_locator在.login-box-container内定位APP扫一扫登录文本的兄弟img找不到即抛RuntimeError。二维码文件保存。build_login_qrcode_path(account_file, suffixxhs_login_qrcode)utils/login_qrcode.py#L12-L15生成带时间戳的临时路径{stem}_xhs_login_qrcode_{时间戳}.png。若src是data:image/前缀则走save_data_url_image解码 base64 落盘否则直接对img元素截图。终端打印二维码。decode_qrcode_from_path用 OpenCVQRCodeDetector优先np.fromfile cv2.imdecode以兼容 Windows 中文路径解出二维码内容再由print_terminal_qrcode通过 segno 渲染到终端渲染失败时回退 ASCII 打印并提示打开图片文件扫码utils/login_qrcode.py#L38-L89。轮询登录完成。_is_xhs_login_completed的判定规则URL 仍停留在创作者中心/login前缀视为未完成否则看登录框div[class*login-box]是否还存在且可见不存在或已不可见即完成。完成后await asyncio.sleep(2)等待页面稳定context.storage_state(pathaccount_file)持久化 Cookie并再调用一次cookie_auth复核——复核失败会得到cookie_invalid状态而不是误报成功。收尾。无论成功、超时timeout还是异常failedfinally块都会清理临时二维码文件并关闭 context/browser。3.3 Cookie 校验与统一的结果载荷cookie_authmain.py#L177-L216是校验核心启动无头浏览器、以storage_stateaccount_file建 context、注入初始化脚本后访问发布页/publish/publish?fromhomepagetargetvideo等待 3 秒后判断——URL 被重定向到/login前缀或登录框仍可见均判为失效异常也按失效兜底返回False。对外入口xiaohongshu_setupmain.py#L219-L239定义了计划所说的 result payloads 契约async def xiaohongshu_setup( account_file, handleFalse, return_detailFalse, qrcode_callbackNone, headless: bool LOCAL_CHROME_HEADLESS, ):return_detailFalse时返回布尔值兼容旧的直接调用方式return_detailTrue时返回_build_login_result构造的字典{success, status, message, account_file, qrcode, current_url}其中status取值为cookie_valid/cookie_invalid/success/timeout/failedhandleTrue表示 Cookie 无效时自动接管登录转调xiaohongshu_cookie_genhandleFalse则只报告失效、不弹浏览器。这个二元开关的设计直接服务于上层 CLIsau_cli.py 中login_xiaohongshu_account使用handleTrue, return_detailTrue登录命令要拿到二维码与结果详情而upload_xiaohongshu_video/upload_xiaohongshu_note使用handleFalseCookie 失效时直接报错提示先运行sau xiaohongshu login --account name避免上传命令意外挂起等扫码。3.4 共享基类 视频/图文两个正式入口保留旧公开名可调用计划要求 Add a shared base uploader plus formal video and note entry points while keeping legacy public names callable。落地为三层结构XiaoHongShuBaseUploader(BaseVideoUploader)main.py#L309-L521持有publish_date、account_file、publish_strategy、debug、headlessvalidate_base_args统一完成 cookie 文件存在性检查、cookie_auth有效性校验、发布策略白名单immediate/scheduled对应模块级常量XIAOHONGSHU_PUBLISH_STRATEGY_IMMEDIATE/_SCHEDULED定时策略下还会调用validate_publish_date归一化发布时间。跨子类复用的页面操作也全部沉淀在这里fill_title/fill_desc/fill_tags标签上限 10 个、话题候选等不到时跳过而非中断发布、set_schedule_time_xiaohongshu、set_location、check_original_declaration来源转载声明、_js_click_by_text用原生el.click()冒泡绕过pointer-events: none的 Vue 事件拦截等。XiaoHongShuVideo视频发布入口必填title与file_path可选desc、tags、thumbnail_path。upload_video_content访问/publish/publish?fromhomepagetargetvideo经set_input_files上传后轮询预览区文本上传成功/分辨率/100%等关键字确认素材就绪再依次填元信息、设置封面失败仅告警、用视频首帧兜底、按策略点击发布或定时发布按钮并以 URL 通配XHS_PUBLISH_SUCCESS_URL_PATTERN **/publish/success?判定成功main.py#L26。XiaoHongShuNote图文笔记入口必填图片列表与标题未显式传title时取正文前 20 字兜底upload_note_content访问targetimage的发布页以填写标题输入框出现作为素材上传完成的信号。两个子类的upload()方法在发布结束或异常前统一执行context.storage_state(pathself.account_file)回写 Cookie使每次发布都顺带刷新登录态。keeping legacy public names callable 体现在xiaohongshu_setup、xiaohongshu_cookie_gen、cookie_auth以及XiaoHongShuVideo/XiaoHongShuNote等公开名称保持原签名可调用CLI 与示例脚本无需同步改名。文件与格式校验复用 uploader/base_video.py 的BaseVideoUploader视频支持.mp4/.mov/.avi/.mkv/.m4v/.webm/.flv/.wmv图片支持.jpg/.jpeg/.png/.webp/.bmpvalidate_publish_date要求publish_date为datetime或0立即发布且定时时间必须晚于当前时间并预留至少 2 小时MIN_SCHEDULE_LEAD_TIME。此外模块支持通过环境变量SAU_XHS_CREATOR_BASE_URL覆盖创作者中心域名默认https://creator.xiaohongshu.com_build_xhs_creator_url负责拼接登录页与发布页 URL——这一点对海外域名rednote场景下的调试是有用的旋钮测试中专门有test_creator_urls_use_configured_rednote_domain用例覆盖。4. Task 3刷新本地调试示例计划将两个示例文件更新为对齐后的入口且明确其定位是调试入口 / 历史直连路径主线走 CLIexamples/get_xiaohongshu_cookie.py 收敛为几行解析默认 Cookie 路径cookies/xiaohongshu_uploader/account.json然后asyncio.run(xiaohongshu_setup(str(account_file), handleTrue, return_detailTrue))——正好演示了 3.3 节结果载荷契约的完整调用方式。examples/upload_video_to_xiaohongshu.py 则暴露了四个直连调试函数对应计划中direct video/note debug functionsupload_video_to_xiaohongshu立即发布、upload_video_to_xiaohongshu_scheduleddatetime.now() 3h定时发布满足 2 小时提前量约束、upload_note_to_xiaohongshu与upload_note_to_xiaohongshu_scheduled图文立即/定时。文件头部 docstring 同时给出了等价的 CLI 主线命令sau xiaohongshu login --account account_name sau xiaohongshu upload-video --account account_name --file videos/demo.mp4 --title 示例标题 --desc 示例简介 sau xiaohongshu upload-note --account account_name --images videos/1.png videos/2.png --title 图文标题 --note 图文正文与 sau_cli.py 中xiaohongshu upload-video/upload-note子命令的参数定义一致--account必填账号名、--file/--images必填素材路径、--title必填、--desc/--note可选、--tags逗号分隔、--schedule定时时间、以及--thumbnail仅视频。5. Task 4验证计划把验证收敛为两条可执行动作运行目标 unittest 文件python -m unittest tests.test_xiaohongshu_uploader -v或等效方式执行 tests/test_xiaohongshu_uploader.py对改动的 Uploader 与示例做快速的 Python 语法/导入检查syntax/import check例如python -c import uploader.xiaohongshu_uploader.main与针对两个示例文件的编译检查。该测试文件除登录契约外还以纯桩对象验证了页面定位细节如test_find_xhs_qrcode_locator_prefers_scan_sibling_inside_login_box锁定APP扫一扫登录兄弟节点 img 的定位策略与fill_meta的输入序列标题fill→ 正文点击后键盘type→ 逐标签输入#话题并等待#creator-editor-topic-container候选项可作为后续维护小红书页面时回归行为的基准。6. 总结一次浅层但契约完整的对齐回看这份计划其价值在于用最小的改动面单文件重构 两个示例 一个测试文件把小红书 Uploader 拉齐到抖音/快手已经验证过的工程范式登录可编程化以二维码提取、终端/文件双通道展示、参数化轮询poll_interval/max_checks和存储态持久化替代page.pause()手工等待并为上层CLI、后端提供了return_detail结构化载荷状态判定显式化cookie_auth的重定向到/login或登录框可见即失效规则贯穿登录复核、上传前校验与失效提示入口正式化XiaoHongShUBaseUploader共享校验与页面操作XiaoHongShuVideo/XiaoHongShuNote视频与图文两条发布流构成清晰的继承结构同时保留旧公开名以维持 CLI 与示例的兼容验证可复现目标 unittest 文件 语法/导入检查保证重构行为被测试锁定而非仅靠人工确认。如果你在维护或扩展该模块建议从 uploader/xiaohongshu_uploader/main.py 的xiaohongshu_setup/xiaohongshu_cookie_gen入手理解登录契约用 tests/test_xiaohongshu_uploader.py 作为行为基线再参考 uploader/base_video.py 与 conf.example.py 理解参数默认值与运行环境前提需要 patchright、本地 chromium channel、以及SAU_XHS_CREATOR_BASE_URL等环境变量。【免费下载链接】social-auto-upload自动化上传视频到社交媒体抖音、小红书、视频号、tiktok、youtube、bilibili项目地址: https://gitcode.com/GitHub_Trending/so/social-auto-upload创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 social-auto-upload 小红书 Uploader 浅层对齐重构：patchright 扫码登录、Cookie 校验与视频/图文双入口
social-auto-upload 小红书 Uploader 浅层对齐重构patchright 扫码登录、Cookie 校验与视频/图文双入口【免费下载链接】social-auto-upload自动化上传视频到社交媒体抖音、小红书、视频号、tiktok、youtube、bilibili项目地址: https://gitcode.com/GitHub_Trending/so/social-auto-upload本文基于仓库内的实施计划文档 2026-03-25-xiaohongshu-shallow-alignment.md完整还原 social-auto-upload 项目中「小红书浏览器端 Uploader 与抖音/快手风格对齐」这次浅层重构的目标、架构边界与四个落地任务。读完你可以掌握如何用 patchright 搭建可轮询的小红书创作者中心扫码登录流程、xiaohongshu_setup的return_detail结果载荷契约、Cookie 有效性校验原理以及XiaoHongShuVideo/XiaoHongShuNote两个正式发布入口的复用结构并能直接复现计划中的测试与验证步骤。1. 计划目标与范围边界这是一份面向 Agent 工作流的实施计划Plan其头部约定由superpowers:subagent-driven-development推荐或superpowers:executing-plans技能逐任务执行步骤用- [ ]复选框跟踪。计划定义了三个核心要素Goal目标让基于浏览器的小红书 Uploader 与当前抖音/快手风格对齐具体体现在三个方面——登录二维码QR流程、patchright 的使用方式、正式的视频/图文video/note入口点同时明确不扩展到 CLI 或文档工作。Architecture架构把改动收敛在 uploader/xiaohongshu_uploader/main.py 内部作为一次浅层重构shallow refactor。先引入一条薄的登录流程包含二维码提取、Cookie 校验与结果载荷result payload再新增一个共享的基类 Uploader以及各自复用公共初始化逻辑的视频和图文浏览器流程。Tech Stack技术栈Python、patchright、异步 Playwright 兼容的浏览器自动化async Playwright-compatible browser automation、unittest。浅层的含义可以从最终代码边界印证登录逻辑、校验逻辑、两个发布器类全部位于uploader/xiaohongshu_uploader/main.py单文件内跨文件依赖仅指向公共工具层utils/login_qrcode.py、uploader/base_video.py、utils/base_social_media.py的set_init_script与配置模块conf。CLI 层 sau_cli.py 只是消费该模块导出的公开名称本次计划本身不改 CLI 代码。2. Task 1先用测试锁定登录/校验的预期行为计划的第一步是测试先行涉及文件Create:tests/test_xiaohongshu_uploader.pyModify:uploader/xiaohongshu_uploader/main.py三个步骤为xiaohongshu_setup(..., return_detailTrue)的无效 Cookie 行为与 Uploader 的校验行为添加测试运行目标测试文件确认它因预期中的缺失行为而失败实现满足这些测试的最小生产代码改动。当前仓库的 tests/test_xiaohongshu_uploader.py 正是这一步的产物其中与登录/校验契约直接相关的用例有test_setup_returns_detail_when_cookie_invalid_without_handlemock 掉os.path.exists返回False后调用xiaohongshu_setup(missing.json, handleFalse, return_detailTrue)断言返回字典success为False、status为cookie_invalid。这锁定了无效 Cookie 时不弹浏览器、直接给出结构化结果的契约test_setup_uses_login_flow_when_handle_is_truemockxiaohongshu_cookie_gen为AsyncMock断言当handleTrue且 Cookie 缺失时xiaohongshu_setup恰好等待await一次登录流程并透传其结果test_video_validate_upload_args_normalizes_video_and_thumbnail与test_note_uploader_exists_and_validates_required_fields锁定XiaoHongShuVideo/XiaoHongShuNote的参数校验行为文件路径归一化、图文缺图片时抛ValueError。测试文件用FakeLocator/RecordingPage等轻量替身替代真实浏览器对象使登录页定位与fill_meta行为可以在无浏览器环境下做纯单元验证。3. Task 2核心重构——patchright、扫码登录流程与双入口这是计划中最重的一步包含三个子项逐项对应到源码。3.1 浏览器自动化层从playwright.async_api切换到patchright.async_apiuploader/xiaohongshu_uploader/main.py#L10-L12 中模块的所有浏览器类型与入口均来自 patchrightfrom patchright.async_api import Page from patchright.async_api import Playwright from patchright.async_api import async_playwright整个模块cookie_auth、xiaohongshu_cookie_gen、两个发布器的upload方法全部通过async with async_playwright() as playwright驱动与抖音/快手 Uploader 的写法保持同一风格发布器启动浏览器时统一使用playwright.chromium.launch(headlessself.headless, channelchromium)。headless默认值来自 conf.example.py 的LOCAL_CHROME_HEADLESS示例配置默认为True并支持本地 Chrome 路径LOCAL_CHROME_PATHcookie_auth中若配置了该路径则以executable_path启动。3.2 用二维码提取 终端打印 文件保存 轮询 Cookie 持久化替换page.pause()登录旧式登录依赖page.pause()人工在 Inspector 里等待扫码重构后的xiaohongongshu_cookie_gen正确拼写为xiaohongshu_cookie_gen见 main.py#L242-L306是一条完全可编程的流水线async def xiaohongshu_cookie_gen( account_file, qrcode_callbackNone, poll_interval: int 3, max_checks: int 100, headless: bool LOCAL_CHROME_HEADLESS, ):关键参数与行为参数默认值作用account_file必填Cookiestorage_state落盘路径通常为cookies/xiaohongshu_uploader/account.jsonqrcode_callbackNone可选回调二维码就绪时收到{image_path, image_data_url}载荷支持同步与异步awaitable回调见_emit_qrcode_callbackpoll_interval3秒每轮登录是否完成检查之间的间隔max_checks100次轮询上限即最长约 5 分钟的扫码等待窗口headlessLOCAL_CHROME_HEADLESS无头模式下会明确提示小人会输出终端二维码并保存本地二维码图片流程拆解对应计划中 QR extraction → terminal printing → QR file saving → polling → cookie persistence 五个环节打开登录页并提取二维码。page.goto(_build_xhs_creator_url(/login))之后_save_xhs_qrcodemain.py#L128-L160依次经过_open_xhs_qrcode_panel若登录框默认不是扫一扫面板则点击img.css-wemwzq切换与_find_xhs_qrcode_locator在.login-box-container内定位APP扫一扫登录文本的兄弟img找不到即抛RuntimeError。二维码文件保存。build_login_qrcode_path(account_file, suffixxhs_login_qrcode)utils/login_qrcode.py#L12-L15生成带时间戳的临时路径{stem}_xhs_login_qrcode_{时间戳}.png。若src是data:image/前缀则走save_data_url_image解码 base64 落盘否则直接对img元素截图。终端打印二维码。decode_qrcode_from_path用 OpenCVQRCodeDetector优先np.fromfile cv2.imdecode以兼容 Windows 中文路径解出二维码内容再由print_terminal_qrcode通过 segno 渲染到终端渲染失败时回退 ASCII 打印并提示打开图片文件扫码utils/login_qrcode.py#L38-L89。轮询登录完成。_is_xhs_login_completed的判定规则URL 仍停留在创作者中心/login前缀视为未完成否则看登录框div[class*login-box]是否还存在且可见不存在或已不可见即完成。完成后await asyncio.sleep(2)等待页面稳定context.storage_state(pathaccount_file)持久化 Cookie并再调用一次cookie_auth复核——复核失败会得到cookie_invalid状态而不是误报成功。收尾。无论成功、超时timeout还是异常failedfinally块都会清理临时二维码文件并关闭 context/browser。3.3 Cookie 校验与统一的结果载荷cookie_authmain.py#L177-L216是校验核心启动无头浏览器、以storage_stateaccount_file建 context、注入初始化脚本后访问发布页/publish/publish?fromhomepagetargetvideo等待 3 秒后判断——URL 被重定向到/login前缀或登录框仍可见均判为失效异常也按失效兜底返回False。对外入口xiaohongshu_setupmain.py#L219-L239定义了计划所说的 result payloads 契约async def xiaohongshu_setup( account_file, handleFalse, return_detailFalse, qrcode_callbackNone, headless: bool LOCAL_CHROME_HEADLESS, ):return_detailFalse时返回布尔值兼容旧的直接调用方式return_detailTrue时返回_build_login_result构造的字典{success, status, message, account_file, qrcode, current_url}其中status取值为cookie_valid/cookie_invalid/success/timeout/failedhandleTrue表示 Cookie 无效时自动接管登录转调xiaohongshu_cookie_genhandleFalse则只报告失效、不弹浏览器。这个二元开关的设计直接服务于上层 CLIsau_cli.py 中login_xiaohongshu_account使用handleTrue, return_detailTrue登录命令要拿到二维码与结果详情而upload_xiaohongshu_video/upload_xiaohongshu_note使用handleFalseCookie 失效时直接报错提示先运行sau xiaohongshu login --account name避免上传命令意外挂起等扫码。3.4 共享基类 视频/图文两个正式入口保留旧公开名可调用计划要求 Add a shared base uploader plus formal video and note entry points while keeping legacy public names callable。落地为三层结构XiaoHongShuBaseUploader(BaseVideoUploader)main.py#L309-L521持有publish_date、account_file、publish_strategy、debug、headlessvalidate_base_args统一完成 cookie 文件存在性检查、cookie_auth有效性校验、发布策略白名单immediate/scheduled对应模块级常量XIAOHONGSHU_PUBLISH_STRATEGY_IMMEDIATE/_SCHEDULED定时策略下还会调用validate_publish_date归一化发布时间。跨子类复用的页面操作也全部沉淀在这里fill_title/fill_desc/fill_tags标签上限 10 个、话题候选等不到时跳过而非中断发布、set_schedule_time_xiaohongshu、set_location、check_original_declaration来源转载声明、_js_click_by_text用原生el.click()冒泡绕过pointer-events: none的 Vue 事件拦截等。XiaoHongShuVideo视频发布入口必填title与file_path可选desc、tags、thumbnail_path。upload_video_content访问/publish/publish?fromhomepagetargetvideo经set_input_files上传后轮询预览区文本上传成功/分辨率/100%等关键字确认素材就绪再依次填元信息、设置封面失败仅告警、用视频首帧兜底、按策略点击发布或定时发布按钮并以 URL 通配XHS_PUBLISH_SUCCESS_URL_PATTERN **/publish/success?判定成功main.py#L26。XiaoHongShuNote图文笔记入口必填图片列表与标题未显式传title时取正文前 20 字兜底upload_note_content访问targetimage的发布页以填写标题输入框出现作为素材上传完成的信号。两个子类的upload()方法在发布结束或异常前统一执行context.storage_state(pathself.account_file)回写 Cookie使每次发布都顺带刷新登录态。keeping legacy public names callable 体现在xiaohongshu_setup、xiaohongshu_cookie_gen、cookie_auth以及XiaoHongShuVideo/XiaoHongShuNote等公开名称保持原签名可调用CLI 与示例脚本无需同步改名。文件与格式校验复用 uploader/base_video.py 的BaseVideoUploader视频支持.mp4/.mov/.avi/.mkv/.m4v/.webm/.flv/.wmv图片支持.jpg/.jpeg/.png/.webp/.bmpvalidate_publish_date要求publish_date为datetime或0立即发布且定时时间必须晚于当前时间并预留至少 2 小时MIN_SCHEDULE_LEAD_TIME。此外模块支持通过环境变量SAU_XHS_CREATOR_BASE_URL覆盖创作者中心域名默认https://creator.xiaohongshu.com_build_xhs_creator_url负责拼接登录页与发布页 URL——这一点对海外域名rednote场景下的调试是有用的旋钮测试中专门有test_creator_urls_use_configured_rednote_domain用例覆盖。4. Task 3刷新本地调试示例计划将两个示例文件更新为对齐后的入口且明确其定位是调试入口 / 历史直连路径主线走 CLIexamples/get_xiaohongshu_cookie.py 收敛为几行解析默认 Cookie 路径cookies/xiaohongshu_uploader/account.json然后asyncio.run(xiaohongshu_setup(str(account_file), handleTrue, return_detailTrue))——正好演示了 3.3 节结果载荷契约的完整调用方式。examples/upload_video_to_xiaohongshu.py 则暴露了四个直连调试函数对应计划中direct video/note debug functionsupload_video_to_xiaohongshu立即发布、upload_video_to_xiaohongshu_scheduleddatetime.now() 3h定时发布满足 2 小时提前量约束、upload_note_to_xiaohongshu与upload_note_to_xiaohongshu_scheduled图文立即/定时。文件头部 docstring 同时给出了等价的 CLI 主线命令sau xiaohongshu login --account account_name sau xiaohongshu upload-video --account account_name --file videos/demo.mp4 --title 示例标题 --desc 示例简介 sau xiaohongshu upload-note --account account_name --images videos/1.png videos/2.png --title 图文标题 --note 图文正文与 sau_cli.py 中xiaohongshu upload-video/upload-note子命令的参数定义一致--account必填账号名、--file/--images必填素材路径、--title必填、--desc/--note可选、--tags逗号分隔、--schedule定时时间、以及--thumbnail仅视频。5. Task 4验证计划把验证收敛为两条可执行动作运行目标 unittest 文件python -m unittest tests.test_xiaohongshu_uploader -v或等效方式执行 tests/test_xiaohongshu_uploader.py对改动的 Uploader 与示例做快速的 Python 语法/导入检查syntax/import check例如python -c import uploader.xiaohongshu_uploader.main与针对两个示例文件的编译检查。该测试文件除登录契约外还以纯桩对象验证了页面定位细节如test_find_xhs_qrcode_locator_prefers_scan_sibling_inside_login_box锁定APP扫一扫登录兄弟节点 img 的定位策略与fill_meta的输入序列标题fill→ 正文点击后键盘type→ 逐标签输入#话题并等待#creator-editor-topic-container候选项可作为后续维护小红书页面时回归行为的基准。6. 总结一次浅层但契约完整的对齐回看这份计划其价值在于用最小的改动面单文件重构 两个示例 一个测试文件把小红书 Uploader 拉齐到抖音/快手已经验证过的工程范式登录可编程化以二维码提取、终端/文件双通道展示、参数化轮询poll_interval/max_checks和存储态持久化替代page.pause()手工等待并为上层CLI、后端提供了return_detail结构化载荷状态判定显式化cookie_auth的重定向到/login或登录框可见即失效规则贯穿登录复核、上传前校验与失效提示入口正式化XiaoHongShUBaseUploader共享校验与页面操作XiaoHongShuVideo/XiaoHongShuNote视频与图文两条发布流构成清晰的继承结构同时保留旧公开名以维持 CLI 与示例的兼容验证可复现目标 unittest 文件 语法/导入检查保证重构行为被测试锁定而非仅靠人工确认。如果你在维护或扩展该模块建议从 uploader/xiaohongshu_uploader/main.py 的xiaohongshu_setup/xiaohongshu_cookie_gen入手理解登录契约用 tests/test_xiaohongshu_uploader.py 作为行为基线再参考 uploader/base_video.py 与 conf.example.py 理解参数默认值与运行环境前提需要 patchright、本地 chromium channel、以及SAU_XHS_CREATOR_BASE_URL等环境变量。【免费下载链接】social-auto-upload自动化上传视频到社交媒体抖音、小红书、视频号、tiktok、youtube、bilibili项目地址: https://gitcode.com/GitHub_Trending/so/social-auto-upload创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考