将技术博客写好之后, 最让人打退堂鼓的, 向来都不是撰写的过程, 而是“发布”这一环节 —— 当一篇内容完成后, 需要登录七个后台, 调整格式, 上传封面, 点击发布。在这篇文章中, 会记载我是怎样借助一个项目, 把这一系列流程实现自动化的, 以及在每个平台实际遭遇过的难题。从无到有搭建起多平台博客自动发布系统, 提及架构设计以及 7 大平台踩坑的实际经历, 首先讲的是为何要去做这样一件事情。 句号。技术领域的人, 多数有着这般的经历, 一篇冗长的文章艰难写完后, 后续需要反复进行七次这样的操作, 即复制, 登录后台, 调整格式, 上传封面, 点击发布。平台数量越多, 发布过程中遭遇的阻碍就越大, 最终索性只在一两个平台发布, 文章所具有的长尾价值就此白白地丧失了。下面是我的目标, 有一份内容, 还有一条命令, 要把它们发送到七个平台上去, 这七个平台分别是掘金、CSDN、博客园、知乎、头条号、百家号以及微信公众号, 并且要最大程度地去复用本机已经登录好的账号, 不触碰任何账号密码。最终所落地的系统已然真实地跑通了, 同一篇文章在七个平台全部发布, 并且每个平台的格式、封面以及标签都依据各自的规则进行自适应, 下面来拆解架构, 再讲述其中的坑。二、整体架构核心思路仅一句话, 即借助 CDP 和已登录本机的连接, 运用代码去模拟人在后台实施操作。┌─────────────────────────────────────────────┐ │ FastAPI 控制台 ( :8000 ) │ │ 接收草稿路径 → 触发发布任务 → 轮询任务状态 │ └───────────────┬─────────────────────────────┘ │ ┌─────────────────────────────────────────────┐ │ 发布器基类 BasePublisher │ │ · connect(CDP) · 监听发布请求(page.on) │ │ · _click() 封装 · 封面上传 · 占位闸门 │ └───────────────┬─────────────────────────────┘ ┌───────┼───────────┬──────────┬────────┐ Juejin CSDN Cnblogs Zhihu Toutiao Baijiahao Weixin (子类各自实现 fill_form / confirm_publish) 本机独立 Chrome--remote-debugging-port9222 --user-data-dir项目隔离目录登录态与系统 Chrome 不互通几个关键设计决策三、两个看似微小、却致命的通用坑这两个坑, 并不归属于任何单独的一个平台, 然而, 一旦踩中其中任何一个, 就会致使你产生这样的认知, 觉得好像是发布成功了, 可实际上呢, 什么都没有发出去。3.1 请求监听必须立刻挂上发布动作的实质是捕捉平台后台的那个接口请求, 以此来判定“究竟有没有发出去”。常见的错误情形是: 先是在括号里填写相应内容, 而后再去括号处挂载监听。这样的一种情况是, 发布请求的时间比监听器挂上去的时间要早, 那么就会出现这样一种结果, 永远都捉捕不到, 进而错误地报告为“未捕获发布请求”。正确的先后次序是: () 随后最先要做的事情便是 page.on(,...) , 接着再进行 fill 操作、再。次序颠倒了, 后续所有的努力都白费。3.2 发布按钮必须 page.click()不是裸鼠标不少平台所具备的发布按钮, 是与React的(click)事件进行绑定设置的。要是你采用底层鼠标移动再加上点击这样的操作方式去点击它, 那么该事件根本就不会被触发, 页面看上去好像被点击了, 实际上却为零请求。在基类当中, 对一个带有检查功能的、括号内包含特定内容也就是 page.click()的操作进行封装, 使得框架能够自行在元素变得可以点击之后再去执行点击操作, 如此一来, 问题便得以消失。顺便提及, 在进行归档操作的时候, 使用的是 copy2 而非 move。不然的话, 源草稿会被从 01-draft/ 中移出, 但是同一篇文章若要发布到多个平台, 那就只能进行一次归档操作了。四、七大平台逐一踩坑头条号最阴险的AI 助手抽屉一当编辑器加以加载, 此刻右侧便会马上弹出一个关于 AI 助手的抽屉, 借 - 实施遮罩涵盖整个右侧区域——连带标题输入框也被遮盖住了。要是直接去点击标题框的话就会报超时出来。解决办法: 进入编辑器之后, 在填表之前, 要先将抽屉关闭点击关闭按钮, 按下相关操作, 再利用 JS 将相应设置为 none 作为兜底措施。此外, 头条号的“登录检测”存在虚假情况——创建页面的标题框只有点击“开始创作”才会出现, 而页脚却偏偏有“登录”字样, 依靠关键字进行判断会误报为未登录, 必须查看编辑器元素以及截图看到“在头条创作的第 N 天”才能算真正登录。将发布操作本身通过走接口重放, 其中 save 参数从 0 变为 1, 当返回 code 等于 0 时, 这才被认定为确确实实的真发布。百家号富文本粘贴被全面防御靠 docx 导入破局百家号的编辑器, 对自动化粘贴有着极度的防御, 我尝试了六种以上的粘贴方式, 结果竟全部失败合成注入仅有纯文本能够写进去, 然而换行却被吞没, 最终呈现出的是一坨没有段落的密文。真正的突破口在于其自身所具备的「插入 → 导入文档」功能, 此功能是走官方文件解析通道的, 它能够通过程序化的方式进行触发, 进而完美地绕过粘贴防御, 其流程如下, 先是 -docx 生成 .docx, 接着在 CDP 上点“插入”, 再点“导入文档”, 随后进行上传, 最后由百家号解析器将富文本写入其中, 经实测标题层级、代码块、列表、加粗、标签均可全部保留。注意了, 百家号最终的那个, 用于“发布”的按钮, 被百度的风控给拦截住了, 系统仅仅能够生成草稿, 而最后那一步, 必须得由人去点击。这跟微信是同一个模型, 也就是, AI负责写草稿, 然后由用户去点击发布。知乎弹窗确认按钮文案不固定点开该发布按钮, 它被称作“发布”, 并非“发布文章”, 旁边另有“发布设置”按钮, 极易误触, 弹窗中的确认按钮文案会发生变化。解法是用CSS的:not(:has-text(设置))来避开设置按钮, 弹窗确认的话要用JS进行模糊搜索多个候选文案, 把发布确认发布等传送进去进行匹配, 核验文章是否发出要去/p/或//posts列表查找, 不要使用已经404的旧后台URL。CSDN最终发布按钮藏在弹窗点击 CSDN 工具栏的“发布”, 仅会打开弹窗, 而真正用于发布的按钮, 是位于弹窗底部的那个.btn-b-red.ml16 , 在页面之中, 还存在一个.- , 属于隐藏状态的仿真元素, 点击它并无效果, 这属于典型的坑。除此以外, 先前需要进行sleep(1.5)操作以促使React与之同步, 不然的话就会偶尔发出400。掘金用 API 重放绕过确定并发布拦截在掘金 UI 那里, 存在着这样一种情况, 即所谓的「确定并发布」按钮具备反自动化拦截功能, 一旦点击这个按钮, 通常仅仅是保存为草稿状态。而解决的办法是, 不通过 UI 进行点击操作, 而是直接去重放该 UI 底层的接口, 依此来绕开按钮拦截。博客园幂等去重是正常行为返回 400「相同标题的博文已存在」的情况是因为相同标题会出现这种状况 , 这属于幂等保护并非是bug遇见这种情形就表明已经发布过了。博客园是七个平台之中最易于用来进行复核的 , 详情页能够直接抓取到正文。