一条视频处理完，要打开抖音、B站、小红书、视频号挨个登录、填标题、选封面、点发布。四个平台跑完要花费一定的时间。

市面上不是没有解决方案，有收费的分发工具，月费从几十到几百不等。但这类工具有两个问题：一是没法集成进自己的工作流；二是出了问题你不知道哪里断了，只能等客服。

后来我找到了 social-auto-upload，GitHub 上 14.1K Star、2.3K Fork 的开源项目，作者本人的原话是：

“生命短暂，能用就用。”

它是怎么工作的

核心是 Playwright——一个可以控制真实浏览器的自动化框架。

用大白话说：它会帮你打开一个真实的 Chrome，然后模拟你的鼠标和键盘操作，自动登录、填写信息、上传视频、点击发布。

整个过程跟你手动操作一模一样，只是换成了代码在做。

目前支持：抖音、Bilibili、小红书、快手、视频号、百家号、TikTok 以及 YouTube 等，我自己用的是前四个，就是你们现在看到截图里的这个界面——四个平台登录状态全绿，一键全发。

我踩的最大的坑：绝对不能用无头模式

Playwright 有两种运行方式。一种是有头模式，会弹出一个真实的浏览器窗口，你能看见它在操作；另一种是无头模式（headless），后台静默跑，不弹窗口。

我第一次配的时候图省事，直接开了无头模式。作者也说了，小红书平台风控严格，尽可能采用有头模式。

结果不到几个小时，小红书给我发了账号异常警告。

这不是玄学，有技术原因的。

无头浏览器和真实浏览器在底层有很多细微的差别：window.__playwright__binding__ 这类全局变量会暴露自动化框架的存在；Canvas 指纹、WebGL 渲染结果不一样；字体列表、屏幕分辨率等环境参数也不一致。平台的风控系统会同时检测这些信号，命中几个就会触发异常判断。

有人专门做过测试，无头模式下这些特征几乎全都泄露。改成有头模式之后，这些信号基本消失，对平台来说就是”一个人在操作浏览器”。

代码层面就是一行的区别：

# 这样会被识别 browser = await playwright.chromium.launch(headless=True)  # 这样更安全 browser = await playwright.chromium.launch(headless=False) 

改完之后我没有再尝试了，毕竟我也怕我的小红书被影响。

实际用下来的感受

省时间是真的。 不用每个平台操作一遍，现在填完信息等它跑完，几分钟就发布了。

定时发布也能用。 可以设定发布时间，但是我只成功了视频号，也懒得调试了。

Cookie 持久化，不用每次扫码。 第一次扫码登录各平台之后，Cookie 会保存到本地，之后直接复用，但是视频号如果其它地方登录，好像就失效了。

出了问题自己能查。 因为是开源代码，哪个平台的上传逻辑出问题了，去 issues 里找，或者自己看代码改。这是收费工具给不了的，现在AI时代，也容易修改。

几个要注意的地方

账号安全。 自动化操作本质上是平台的灰色地带。不要上来就把主力账号挂上去，先用小号测试，稳了再切换。频率也不要搞太高，模拟正常人的节奏。

无头模式一定不要用。 这是最容易踩的坑，上面说了，用有头模式。

平台会更新页面结构。 有时候平台改了发布页面的元素，脚本会失效。这时候去 GitHub Issues 看看，通常有人已经提出来并给了修复方案。

Python 环境要装好。 用的是 Python + Playwright，环境配置有一定门槛，不熟悉命令行的人需要一点时间。

值得关注的是

14.1K Star 这个数字背后，意味着有相当多的内容创作者和运营团队在用这套方案。它的 Issues 里能看到各种真实场景的反馈，有踩坑的、有贡献代码的，整个社区还算活跃。

国内短视频代运营市场规模已经很大了，但绝大多数工具要么收费、要么闭源、要么没法集成进自己的系统。这个项目填的就是这个空白。

如果你在做多平台内容分发，这是目前我尝试过的最好的开源方案。

项目地址：https://github.com/dreammis/social-auto-upload

P.S. 用了无头浏览器被小红书警告这件事，我是吃过亏才知道的。技术细节不难，但踩坑的时间成本不低。希望这篇能帮你少走一点弯路。