DEV Community: wxfwxf911

爬虫被 React 反爬拦死？知乎 Draft.js 编辑器的完整破解过程（附代码）

wxfwxf911 — Sun, 16 Aug 2026 04:12:23 +0000

做自动化发布的时候，知乎是我卡得最久的一个平台——不是登录、不是风控，而是编辑器本身把我拦死了。

需求很简单：把 Markdown 文章自动发到知乎。结果内容怎么都进不去编辑器，提交一按，正文是空的。前前后后折腾了三个小时，最后发现根子在 React 上。整个过程记下来，给后来的人省点时间。

现象：内容塞进去了，一提交就丢

一开始我图省事，直接改 DOM：

const el = document.querySelector('.DraftEditor-root .public-DraftEditor-content');
el.innerHTML = contentHtml;

页面上看着明明显示出来了，一点「发布」，正文却是空的，或者只剩旧内容。你甚至能肉眼看到文字一闪，然后没了。

根因：Draft.js 是 React 受控组件，它不认你的 DOM

知乎的编辑器底层是 Draft.js，这是 React 官方出的富文本框架。它内部维护着一份自己的 state（编辑状态），页面上的文字是从这份 state 渲染出来的。

这意味着：你直接改 innerHTML，改的是浏览器里渲染出来的结果，但 React 那份 state 压根没变。等你触发提交，React 用自己 state 重新渲染，你塞进去的东西就全被「抹」回去了。

打个比方：你以为改了账本，其实你只是拿笔在账本的复印件上写了字，原件一个字没动。

破解关键：别走 DOM，走「事件」

React 不认直接赋值，但认合成事件。它监听的是浏览器的输入事件，而不是 DOM 的变化。所以正确的做法是：模拟一次真实的键盘输入，让 React 自己把这笔输入记进 state。

// 先让编辑器获得焦点（点击一下）
await page.click('.DraftEditor-root');

// 用 insertText 模拟键盘输入，触发 React 合成事件
await page.keyboard.insertText(content);

就这一句 insertText()，把 innerHTML 换成它，内容就进去了，提交也不丢了。

完整可跑通的代码

下面是发布知乎文章的完整片段（Playwright + Python）：

from playwright.sync_api import sync_playwright

def publish_zhihu(title: str, content: str):
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=False)  # 知乎反爬，建议 headful
        page = browser.new_page()
        page.goto("https://zhuanlan.zhihu.com/write")

        # 填标题
        page.fill('.WriteIndex-titleInput', title)

        # 填正文：先点编辑器获得焦点，再模拟键盘输入
        page.click('.DraftEditor-root')
        page.keyboard.insert_text(content)

        # 点发布
        page.click('button:has-text("发布")')
        browser.close()

几个关键点：

headless=False——知乎对无头浏览器检测很严，用有头模式成功率高得多。
insert_text() 是核心，fill() 对 React 受控组件经常失效。
别用固定 sleep，等「发布成功」的状态元素出现再结束，比瞎等可靠。

这套思路通用

凡是「你改了 DOM 但页面不认」的场景，基本都是 React / Vue 这类框架的受控组件在作怪。记住一条：框架维护状态的场景，一律走事件，不走赋值。 知乎是 Draft.js，其他平台也有各自的富文本框架，思路都一样。

做数据采集、自动化脚本、多平台发布的朋友，如果你也被某个平台的反爬卡住了，欢迎来找我聊聊。

接单范围：Python 脚本定制、数据采集（含反爬破解）、自动化代做、多平台自动发布。闲鱼直接搜「反爬数据采集」就能找到我，或者 CSDN 站内私信，说明你的需求，我看到了就回。

反爬不是玄学：我被 6 个平台毒打后，总结的一套破解方法论

wxfwxf911 — Fri, 14 Aug 2026 14:58:32 +0000

做自动化、爬数据的人，最常问的一句话是：「为什么同一个脚本，在别人那儿能跑，到我这就不行？」

其实反爬不是玄学。它本质是平台在判断「你到底是不是人」，而识别手段翻来覆去就那几类。我把踩过的坑归成四类，每一类给一套破解套路。摸清楚这四类，市面上大部分站你都能啃下来。

第一类：前端框架拦截（React 系）——你以为改好了，它根本不认

典型症状：你 innerHTML 塞进去的内容，一提交就丢了，或者点按钮没反应。

知乎的编辑器底层是 Draft.js（React 富文本框架）。它内部维护着自己的 state，你直接改 DOM，React 完全不知道，下次渲染又给你盖回去。

破解套路：别直接改 DOM，把输入「喂」给框架。React 认合成事件，不认原生赋值。比如：

await page.click('.DraftEditor-root');
await page.keyboard.insertText(content);

insertText() 会触发 React 的合成事件，Draft.js 这才认这笔输入。一句话：框架维护状态的场景，一律走事件，不走赋值。

第二类：DOM 隔离（Shadow DOM / 微前端）——querySelector 全是 null

典型症状：元素肉眼可见，但 document.querySelector() 一个都找不到。

微信视频号用了个叫 wujie 的微前端框架，页面全塞在 <wujie-app> 的 Shadow DOM 里。普通的 CSS 选择器全部失效，你会怀疑自己是不是打开了错误的页面。

破解套路：先穿透 shadowRoot，拿到真正的根节点，再往下找：

const shadowRoot = await page.evaluate(() =>
  document.querySelector('wujie-app').shadowRoot
);

记住：选择器失效时，先检查是不是被 Shadow DOM 隔开了，别急着怀疑反爬。

第三类：WAF / 网关拦截——请求直接给你打回来

典型症状：整个页面都进不去，统一返回个 4xx，或者一直转圈。

思否上了 Safeline WAF，自动化请求统一回 HTTP 468。我试过 headless、headful、换 UA、加 stealth，全被 JS Challenge 卡在门外。

破解套路：先分清是「JS Challenge」还是「IP 封禁」——这俩解法完全不同。

JS Challenge：只能真浏览器 + human-like 慢速操作 + stealth 插件，让它觉得你是人。
IP 封禁：换代理，本地直连基本无解。

这类最考验判断力。硬刚不动的时候，别死磕，绕过或者人工兜底，效率反而更高。

第四类：复杂异步流程——你以为传完了，其实没有

典型症状：文件「上传成功」了，结果发布是空的。

B站视频上传是分片的，你等 input 事件触发没用——文件传上去之后，它还要在后台转码。得等到「重新上传」按钮出现，才算真正传完：

await page.waitForSelector('.upload-reencode-btn', { timeout: 300000 });

破解套路：永远用状态信号，不用固定 sleep。 固定 sleep 要么浪费时间，要么还没好就继续跑。等「完成」标志出现，才是真的完成。

这四类对应了四种反爬思路：前端事件拦截、DOM 隔离、WAF 拦截、复杂异步。做自动化的，几乎都会撞上其中一两个。核心其实就一句：反爬打的是「识别你是脚本」，你打的牌是「装得像人」——走事件、穿 DOM、真浏览器、等状态，这套组合拳能破大半。

如果你也被某个平台的反爬卡住，或者想找人代做数据采集、自动化脚本、多平台内容分发，欢迎私聊交流。我平时也接这类私活，有需求可以直接私信，或者到我闲鱼上看看。

用 Playwright 做数据采集，真正难的从来不是点击

wxfwxf911 — Fri, 14 Aug 2026 03:21:49 +0000

很多人以为会 page.click() 和 page.fill() 就等于会做数据采集了。真上手一个项目才发现，点击、输入只占 20%，剩下 80% 全是下面这些「看不见的坑」。

一、登录态管理，才是第一道坎
目标网站要登录才能看数据，你总不能每次跑都手动扫码。核心是 Cookie 的生命周期管理：

首次手动登录，保存 cookie

context = browser.new_context()
page = context.new_page()

... 手动登录后

context.storage_state(path="cookies.json")

之后直接复用，跳过登录

context = browser.new_context(storage_state="cookies.json")
但保存一次就完事是错的。Cookie 会过期、会失效，脚本要能检测登录态是否还在，失效了及时提醒重新登录，而不是跑一半报一堆看不懂的错。

二、指纹一致性，比你想的阴险
很多网站不只看 UA，还查 navigator.webdriver、window.chrome、Canvas 指纹、甚至鼠标移动轨迹。你 headless 一开，指纹就露馅了。

关键不是「加 stealth 插件」这么简单，而是保持整套指纹的自洽——UA、屏幕分辨率、语言、时区要像一个真实用户，不能东拼西凑。

三、等待，是技术活不是 sleep
新手最爱 time.sleep(5)，结果要么等不够、要么浪费半天。真正该做的是等条件，不等时间：

差：固定睡 5 秒

time.sleep(5)

好：等某个元素真的出现

page.wait_for_selector('.data-table', state='visible', timeout=30000)
数据是异步加载的，等「数据渲染完成」这个信号，比等「几秒钟」可靠一百倍。

四、稳定性，决定你能不能接第二单
脚本跑一次成功没用，要能跑一百次都稳。三个关键：

重试机制：网络抖动、偶发超时，自动重试而不是直接崩
断点续跑：跑到一半断了，下次从断点接着跑，不从头再来
日志：每次跑留下记录，出问题了能查，而不是对着黑屏猜
这四点做扎实了，才是一个「能交付」的数据采集脚本，而不是「在我电脑上能跑」的 demo。

后续我会继续分享自动化实战里的这些细节。如果你也在做类似的项目，卡在某个环节上，欢迎一起交流。

标题：爬数据 / 做自动化最怕反爬？我在 6 个平台上踩过的坑，全给你

wxfwxf911 — Thu, 13 Aug 2026 14:58:22 +0000

做自动化的人都知道，写代码不难，难的是跟平台的反爬斗。最近我用 Playwright 做了一个多平台自动发布的工具，把国内主流的几个平台挨个打通了一遍。回头一看，这些坑一个比一个阴间，不踩一遍你根本想不到。挑四个最经典的说说。

一、知乎：富文本编辑器根本不认 innerHTML
知乎的文章编辑器底层是 Draft.js（React 的富文本框架）。一开始我图省事，直接 innerHTML = content，结果提交的时候内容直接丢了——Draft.js 内部维护着自己的 state，你改 DOM 它根本不认。

最后只能模拟键盘输入：

await page.click('.DraftEditor-root');
await page.keyboard.insertText(content);
insertText() 会触发 React 的合成事件，Draft.js 才认这笔输入。就这一下，卡了我大半天。

二、微信视频号：DOM 藏在 Shadow DOM 里
视频号用了个叫 wujie 的微前端框架，页面结构全塞在的 Shadow DOM 里。普通的 document.querySelector() 全是 null，CSS 选择器全部失效。

得先穿透进去：

const shadowRoot = await page.evaluate(() =>
document.querySelector('wujie-app').shadowRoot
);
三、思否：WAF 直接把你整个自动化拦死
思否上了 Safeline WAF，自动化请求统一返回 HTTP 468。我试过 headless、headful、换 UA、加 stealth，全被 JS Challenge 卡在门外。这种不是技术能硬刚的，只能绕过或者人工介入。

四、B站：视频上传完 ≠ 传完了
B站的视频上传是分片的，你等 input 事件触发没用，文件传上去之后它还要在后台转码。得等到「重新上传」按钮出现，才算真正上传完毕：

await page.waitForSelector('.upload-reencode-btn', { timeout: 300000 });
这还不算完，之后还要等转码进度条走完。一个视频发布流程，光"等"就要好几分钟。

这四个坑，分别对应了四种不同的反爬思路：前端框架事件拦截（React）、DOM 隔离（Shadow DOM）、WAF 拦截、复杂异步流程。做自动化的，基本都会撞上其中一两个。

如果你也在做类似的事——数据采集、自动化脚本、RPA、多平台内容分发——卡在某个平台上搞不定，欢迎私聊交流。

另外我自己也接相关的私活：Python 脚本定制、数据采集、自动化代做、多平台自动发布，有需求可以直接私信。

开源项目从 0 到 1：我用 2 周业余时间搭建了多平台发布系统

wxfwxf911 — Wed, 12 Aug 2026 03:45:53 +0000

开源项目从 0 到 1：我是怎么用 2 周业余时间搭建多平台发布系统的

起因：一个周三晚上的崩溃

故事开始于一个普通的周三晚上。

22:00，写完了一篇 Python 教程。22:35，还在复制粘贴第 6 个平台。

当时心里想的是：「我写了 40 分钟文章，为什么还要花 30 分钟发布？」

作为一个程序员的本能反应——这个问题应该用代码解决。

Day 1-2：技术选型

动手之前花了两天调研。核心问题是：怎么跟 9 个平台对话？

经过调研发现，平台分三类：

类型	代表	方案
有公开 API	掘金、CSDN、Dev.to	HTTP 请求直接调
有半公开 API	知乎、博客园	需要逆向签名（x-zse-96、X-Ca）
没有 API	小红书、抖音	只能 Playwright 浏览器模拟

技术栈决策：

后端: Python + FastAPI
  - 选 Python 因为 Playwright 的 Python 绑定最成熟
  - 选 FastAPI 因为异步支持好，自带文档

前端: 原生 HTML/CSS/JS
  - 不需要 React/Vue。一个管理后台而已，原生 JS 完全够用
  - 零 npm 依赖，部署简单

数据库: SQLite
  - 单文件，不需要装 MySQL/PostgreSQL
  - 个人工具，并发不是问题

浏览器插件: Chrome Extension Manifest V3
  - 一键提取 Cookie，用户不用手动 F12

不做的事情：

❌ 不用 Docker（增加复杂度，个人部署不需要）
❌ 不用 Redis（SQLite 足够）
❌ 不用前端框架（过度设计）

Day 3-5：搭建骨架

先搭最小可用版本：一个 API + 一个页面 + 一个平台。

选掘金作为第一个平台——它有公开 API，最简单。

# 核心抽象：每个平台一个 Adapter
class BasePlatform:
    async def publish(self, title, content, tags, credentials) -> PublishResult:
        raise NotImplementedError

    async def fetch_stats(self, post_id, credentials) -> StatsResult:
        raise NotImplementedError

这个阶段的关键决策：

策略模式：每个平台是一个独立的 Adapter 类，新增平台不改核心逻辑
异步优先：所有网络请求用 async/await，发布 9 个平台可以并发
失败隔离：一个平台失败不影响其他平台

骨架搭完后，掘金能发了。但只有一个平台没意义——得把所有平台都接上。

Day 6-10：攻克硬骨头

知乎：逆向 x-zse-96 签名

知乎的 API 要求每个请求带一个 x-zse-96 签名头。签名的生成逻辑藏在知乎前端的混淆 JS 里。

花了两个晚上逆向：原来是 MD5(特定参数 + d_c0 Cookie) → AES-CBC 加密 → 拼接前缀。

def _make_x_zse_96(url: str, d_c0: str) -> str:
    source = f"101_3_3.0+/api/v4/{url}+{d_c0}"
    md5_hash = hashlib.md5(source.encode()).hexdigest()
    # ... AES-CBC 加密 ...
    return "2.0_" + encrypted.hex()

搞定的那一刻，知乎文章秒发——那种感觉比写完代码还爽。

CSDN：阿里云网关签名

CSDN 用的是阿里云 API 网关的 HMAC-SHA256 签名方案。文档是中文的，但签名串的格式写得很隐晦——分隔符必须是 \n，不能是空格。这个细节浪费了我两个小时。

博客园：2002 年的 XML-RPC

博客园的 API 是 MetaWeblog XML-RPC——一个 2002 年的协议。Python 标准库自带的 xmlrpc.client 直接用。但有个坑：分类里不加 [Markdown]，文章就会被当 HTML 解析。

小红书：Playwright 兜底

小红书没有公开 API，只能上 Playwright。但每次启动浏览器要 2-3 秒。优化手段：

Cookie 持久化，跳过登录
先通过 API 拿到图片上传地址，只让 Playwright 做最后的表单提交
在 Linux 服务器上用 Xvfb 虚拟显示

Day 11-14：打磨产品

核心功能跑通后，开始打磨：

数据看板：每个平台的阅读/点赞/评论自动汇总，不用挨个登录后台
浏览器插件：一键提取 Cookie，告别手动 F12
错误处理：发布失败自动重试，详细的错误日志
前端：深紫渐变配色，告别 Bootstrap 蓝

踩过的坑（诚实版）

思否的雷池 WAF（HTTP 468）——连 Playwright headful 模式都过不了，目前无解
CSDN 只能发草稿——API 发布只有 status=2（草稿），要手动去后台点「发布」还要微信扫码
知乎 content/daily API 需要「致知计划」权限——浪费半天调试，最后换了 creations/v2/all
Dev.to 反垃圾机制——标题 5 分钟内不能重复，包括不同文章

数据和反馈

两周开发，目前：

9 个平台接入
15 篇文章发布
累计 143 阅读（掘金 23、知乎 50、CSDN 70）

数字不大，但对于一个刚上线两天的开源项目来说，是个不错的开始。

下一步

Docker 一键部署
AI 内容改写（根据平台风格自动调整语气）
海外平台支持（Medium、Hashnode）
定时发布

最后

这个项目让我体会到一件事：程序员最好的副业，是解决自己的问题。

你自己就是用户，知道痛点在哪，不需要做用户调研。用着顺手了，开源出来——自然有人跟你一样需要它。

如果你也在维护多个平台，或者想看看 Python + Playwright 怎么搞定 9 个平台的自动化：

👉 GitHub: https://github.com/wxfwxf911/polypost

Star ⭐ 是我持续维护的动力。如果有什么平台想让我支持，提 Issue。

标签：开源, Python, Playwright, 自动化, 独立开发

Writing Takes 40 Minutes, Publishing Takes 30 — How I Automated Multi-Platform Content Distribution

wxfwxf911 — Wed, 12 Aug 2026 03:43:44 +0000

Writing Takes 40 Minutes, Publishing Takes 30 — How I Solved It

Last Wednesday, 22:00. I just finished writing a tutorial on Python async programming — 2200 words, clean Markdown, syntax-highlighted code blocks.

22:03, open Juejin. Paste title. Paste content. Code highlighting gone. Fix manually. Pick tags. Publish.

22:08, open Zhihu. Paste title. Paste content. The Draft.js editor merged async def into asyncdef. Fix line by line. Publish.

22:15, open CSDN. Paste title. Content looks fine. But the category dropdown has 50 options and "Python" is buried. Publish.

22:20, open Cnblogs. Must add [Markdown] tag to categories or the whole article renders as garbled HTML. Publish.

22:25, open SegmentFault. Search tags for "Python async" — zero results. Type manually. Publish.

22:30, open Dev.to. Translate title. Translate content. Publish.

Forty minutes to write. Thirty minutes to publish.

22:35, all done. But the next morning, I wanted to check stats — another round of logging into each platform's dashboard one by one.

I'm Not Alone

Searching forums and social platforms, I found many developers share this pain:

"Every time I publish an article, I open 7-8 tabs, copy-paste 7-8 times, fix formatting 7-8 times. The joy of writing gets killed by the drudgery of publishing."

"I usually only publish on one platform now. It's just too much work to do more. But then search engine exposure suffers."

Why "Just Copy-Paste" Doesn't Work

Each platform has a different editor:

Platform	Editor	Markdown Handling
Juejin	Custom Markdown	Good, but code highlighting sometimes breaks
Zhihu	Draft.js rich text	No Markdown support, eats line breaks
CSDN	Dual-mode	Mode switching corrupts formatting
Cnblogs	TinyMCE	Must add `[Markdown]` tag or disaster
SegmentFault	Markdown	Okay, but tag system is painful
Dev.to	Markdown	Best experience, but English-only audience

The same Markdown renders differently everywhere. Copy-paste doesn't solve it.

What I Built

I spent two weeks of evenings building PolyPost — an open-source tool that adapts your content for each platform and publishes everywhere with one click.

Write once (Markdown)
      |
      v
  PolyPost adaptation layer
  |- Juejin -> Markdown -> API
  |- Zhihu -> Plain text -> Draft.js API
  |- CSDN -> HTML -> API with X-Ca signing
  |- Cnblogs -> Markdown -> MetaWeblog XML-RPC
  |- SegmentFault -> Plain text -> API
      |
      v
  All published in ~30 seconds

Beyond Publishing

Stats dashboard: One page to see views/likes/comments across all platforms
Cookie manager: Chrome extension for one-click session extraction
Scheduled publishing: Queue posts for optimal timing
Publish history: Track what went where

Open Source

Built with Python + FastAPI + Playwright. MIT licensed.

GitHub: https://github.com/wxfwxf911/polypost

If you maintain accounts on 5+ platforms, this saves you 30 minutes per article. If you only use 1-2 platforms, you probably don't need it.

But if you're tired of the copy-paste-format-fix loop — give it a try.

Tags: #python #automation #productivity #opensource #writing

The Pain of Publishing to 9 Platforms — And How I Automated It Away

wxfwxf911 — Wed, 12 Aug 2026 03:35:31 +0000

写了 40 分钟文章，发了 30 分钟——程序员的发布困境终于有解了

一个周三晚上的真实记录

22:00，写完了一篇 Python 异步编程的教程，2200 字，Markdown 格式，代码块带语法高亮。

22:03，打开掘金。粘贴标题。粘贴正文。代码块的高亮没了。手动调整。选标签。发布。

22:08，打开知乎。粘贴标题。粘贴正文。Draft.js 编辑器把 async def 解析成了 asyncdef。一段一段地修。发布。

22:15，打开 CSDN。粘贴标题。正文正常了。但分类列表有 50 个选项，要找到"Python"得翻半天。发布。

22:20，打开博客园。分类里要加 [Markdown] 标签，不然文章会被当 HTML 解析。上次忘了加，整篇文章变成一团乱码。发布。

22:25，打开思否。标签搜索"Python 异步"，返回 0 结果。手动输入。发布。

22:30，打开 Dev.to。标题翻成英文。正文翻成英文。发布。

写完文章用了 40 分钟，发布用了 30 分钟。

22:35，终于全部发完。但第二天醒来，想看各平台数据——又得一个个登录后台。

我不是一个人

在 V2EX、掘金、知乎上搜了一圈，发现这不是我一个人的痛苦：

"每次发文章都要打开七八个页面，复制粘贴七八次，调格式七八次。写完文章的高兴劲都被磨没了。"
— V2EX 用户

"我一般只发掘金，因为多发几个平台太累了。但只发掘金的话，文章在搜索引擎上的曝光又不够。"
— 知乎回答

"之前手动管理 4 个平台，后来放弃了只剩掘金。不是不想维护其他平台，是时间和精力不允许。"
— 掘金沸点

程序员的发布困境：写文章很开心，发布很痛苦，看数据更痛苦。

为什么"复制粘贴"解决不了？

你可能想说：不就是 copy-paste 吗？能有多麻烦？

问题是每个平台的编辑器都不一样：

平台	编辑器	对 Markdown 的处理
掘金	自研 Markdown 编辑器	支持好，但代码块高亮有时丢失
知乎	Draft.js 富文本	不支持 Markdown，换行符被吃
CSDN	富文本 + Markdown 双模	切换模式容易乱
博客园	TinyMCE	不加 `[Markdown]` 分类就当场爆炸
思否	Markdown	还可以，但标签系统难用
Dev.to	Markdown	体验最好，英文平台

同一段 Markdown，在不同平台的表现完全不同。这不是复制粘贴能解决的。

自动化能做什么？

我花了两个星期的业余时间，写了一个开源工具——PolyPost。

核心逻辑很简单：你写一次 Markdown，它帮你适配到每个平台的格式要求，然后自动发布。

写文章（Markdown）
      │
      ▼
  PolyPost 适配层
  ├─ 掘金 → Markdown → API 发布
  ├─ 知乎 → 纯文本 → Draft.js API 发布
  ├─ CSDN → HTML → API + X-Ca 签名发布
  ├─ 博客园 → Markdown → MetaWeblog XML-RPC
  └─ 思否 → 纯文本 → API 发布
      │
      ▼
  全部发完，耗时 ≈ 30 秒

除了发布，还能做什么？

数据看板：一个页面看所有平台的阅读/点赞/评论，不用一个个登录后台
Cookie 管理：Chrome 浏览器插件一键提取登录态，不用手动 F12
定时发布：写好了预约时间发，配合平台流量高峰
发布记录：哪篇发了哪个平台，一目了然

开源 & 自部署

PolyPost 是开源的（MIT License），你可以部署在自己的服务器上：

👉 GitHub: https://github.com/wxfwxf911/polypost

目前支持 9 个平台：掘金、知乎、CSDN、博客园、思否、小红书、抖音、B站、微信视频号。

如果你只用 3-4 个平台，可能不需要这个工具。但如果你像我一样维护 5+ 个平台，这 30 秒 vs 30 分钟的差距，每发一篇文章都能体会一次。

最后

写代码是为了解决问题。自己的问题也是问题。

如果你也被多平台发布折磨过，欢迎 Star ⭐ + 试用。如果你想支持更多平台，提个 Issue，我来适配。

毕竟——写文章已经很累了，发布这件事，交给代码就好。

#Python #自动化 #效率工具 #开源 #技术写作

写了 40 分钟文章，发了 30 分钟——程序员的发布困境终于有解了

wxfwxf911 — Tue, 11 Aug 2026 17:18:05 +0000

写了 40 分钟文章，发了 30 分钟——程序员的发布困境终于有解了

一个周三晚上的真实记录

22:00，写完了一篇 Python 异步编程的教程，2200 字，Markdown 格式，代码块带语法高亮。

22:03，打开掘金。粘贴标题。粘贴正文。代码块的高亮没了。手动调整。选标签。发布。

22:08，打开知乎。粘贴标题。粘贴正文。Draft.js 编辑器把 async def 解析成了 asyncdef。一段一段地修。发布。

22:15，打开 CSDN。粘贴标题。正文正常了。但分类列表有 50 个选项，要找到"Python"得翻半天。发布。

22:20，打开博客园。分类里要加 [Markdown] 标签，不然文章会被当 HTML 解析。上次忘了加，整篇文章变成一团乱码。发布。

22:25，打开思否。标签搜索"Python 异步"，返回 0 结果。手动输入。发布。

22:30，打开 Dev.to。标题翻成英文。正文翻成英文。发布。

写完文章用了 40 分钟，发布用了 30 分钟。

22:35，终于全部发完。但第二天醒来，想看各平台数据——又得一个个登录后台。

我不是一个人

在 V2EX、掘金、知乎上搜了一圈，发现这不是我一个人的痛苦：

"每次发文章都要打开七八个页面，复制粘贴七八次，调格式七八次。写完文章的高兴劲都被磨没了。"
— V2EX 用户

"我一般只发掘金，因为多发几个平台太累了。但只发掘金的话，文章在搜索引擎上的曝光又不够。"
— 知乎回答

"之前手动管理 4 个平台，后来放弃了只剩掘金。不是不想维护其他平台，是时间和精力不允许。"
— 掘金沸点

程序员的发布困境：写文章很开心，发布很痛苦，看数据更痛苦。

为什么"复制粘贴"解决不了？

你可能想说：不就是 copy-paste 吗？能有多麻烦？

问题是每个平台的编辑器都不一样：

平台	编辑器	对 Markdown 的处理
掘金	自研 Markdown 编辑器	支持好，但代码块高亮有时丢失
知乎	Draft.js 富文本	不支持 Markdown，换行符被吃
CSDN	富文本 + Markdown 双模	切换模式容易乱
博客园	TinyMCE	不加 `[Markdown]` 分类就当场爆炸
思否	Markdown	还可以，但标签系统难用
Dev.to	Markdown	体验最好，英文平台

同一段 Markdown，在不同平台的表现完全不同。这不是复制粘贴能解决的。

自动化能做什么？

我花了两个星期的业余时间，写了一个开源工具——PolyPost。

核心逻辑很简单：你写一次 Markdown，它帮你适配到每个平台的格式要求，然后自动发布。

写文章（Markdown）
      │
      ▼
  PolyPost 适配层
  ├─ 掘金 → Markdown → API 发布
  ├─ 知乎 → 纯文本 → Draft.js API 发布
  ├─ CSDN → HTML → API + X-Ca 签名发布
  ├─ 博客园 → Markdown → MetaWeblog XML-RPC
  └─ 思否 → 纯文本 → API 发布
      │
      ▼
  全部发完，耗时 ≈ 30 秒

除了发布，还能做什么？

数据看板：一个页面看所有平台的阅读/点赞/评论，不用一个个登录后台
Cookie 管理：Chrome 浏览器插件一键提取登录态，不用手动 F12
定时发布：写好了预约时间发，配合平台流量高峰
发布记录：哪篇发了哪个平台，一目了然

开源 & 自部署

PolyPost 是开源的（MIT License），你可以部署在自己的服务器上：

👉 GitHub: https://github.com/wxfwxf911/polypost

目前支持 9 个平台：掘金、知乎、CSDN、博客园、思否、小红书、抖音、B站、微信视频号。

如果你只用 3-4 个平台，可能不需要这个工具。但如果你像我一样维护 5+ 个平台，这 30 秒 vs 30 分钟的差距，每发一篇文章都能体会一次。

最后

写代码是为了解决问题。自己的问题也是问题。

如果你也被多平台发布折磨过，欢迎 Star ⭐ + 试用。如果你想支持更多平台，提个 Issue，我来适配。

毕竟——写文章已经很累了，发布这件事，交给代码就好。

#Python #自动化 #效率工具 #开源 #技术写作

I Built a Tool to Publish to 9 Platforms with One Click - Here is How

wxfwxf911 — Tue, 11 Aug 2026 17:15:43 +0000

I Automated Publishing to 9 Platforms with Python + Playwright

Writing the article takes 40 minutes. Publishing to 9 platforms takes another 30. So I built a tool to handle it automatically.

The Problem

Every tech blogger knows this pain:

Open Juejin → paste title → paste content → fix formatting → pick tags → publish
Open Zhihu → paste title → paste content → fight with Draft.js eating line breaks → publish
Open CSDN → paste title → paste content → set category → publish
Open Cnblogs → remember to add [Markdown] tag → paste everything → publish
Repeat for SegmentFault, Xiaohongshu, Douyin, Bilibili, WeChat Video...

Each platform has its own editor quirks. Markdown that looks perfect on one platform breaks on another. Code blocks lose syntax highlighting. Line breaks multiply or disappear.

So I built PolyPost — an open-source tool that publishes to all 9 platforms with a single click.

GitHub: https://github.com/wxfwxf911/polypost (⭐ star it if you find it useful!)

Architecture

User writes Markdown once
        |
        v
Content adaptation layer (Markdown → HTML / Rich Text / Plain Text)
        |
        v
Platform adapters (Juejin, Zhihu, CSDN, Cnblogs...)
        |
        v
Platform APIs / Playwright browser automation

The Interesting Parts

1. Zhihu's Anti-Crawler Signature (x-zse-96)

Zhihu requires a cryptographic signature on every API request. It's an AES-CBC encrypted MD5 hash with a fixed prefix and uses the d_c0 cookie value as part of the signed string. Had to reverse-engineer this from Zhihu's frontend JavaScript.

2. CSDN's X-Ca HMAC-SHA256

CSDN uses Alibaba Cloud's API Gateway signing mechanism — every request needs X-Ca-Signature, X-Ca-Nonce, and X-Ca-Timestamp headers. The signing string must use \n as the separator (not spaces!), which took me 2 hours to debug.

3. Cnblogs MetaWeblog XML-RPC

One of the few platforms with a standard API — though it's the ancient XML-RPC protocol from 2002. And yes, you must include [Markdown] in the categories or it parses your content as HTML. Not documented anywhere.

4. Playwright for Platforms Without APIs

Some platforms (Xiaohongshu, Douyin) don't have public APIs. For those, PolyPost falls back to Playwright browser automation — injecting pre-extracted cookies, filling forms, and clicking submit.

Tech Stack

Layer	Tech	Why
Backend	Python / FastAPI	Async, fast, great docs
Frontend	Vanilla HTML/CSS/JS	Zero npm dependencies
DB	SQLite	Single file, zero ops
Browser Extension	Chrome MV3	One-click cookie extraction
Fallback	Playwright	For platforms without APIs

Results

After two weeks of evening hacking, it works. I write an article, click publish, go make coffee, and when I come back it's on all 9 platforms.

The tool handles:

Automatic format adaptation per platform
Cookie management via browser extension
Stats aggregation (views, likes, comments)
Scheduled publishing (coming soon)

Try It

Open source, MIT licensed:

👉 https://github.com/wxfwxf911/polypost

If you publish to multiple Chinese platforms, give it a try. If you want support for another platform, open an issue.

Tags: #python #playwright #automation #opensource #productivity

I built a tool to publish to 9 platforms with one click — here is how

wxfwxf911 — Mon, 10 Aug 2026 17:28:58 +0000

I write technical articles for a few Chinese platforms (Juejin, CSDN, Zhihu, SegmentFault, Cnblogs). Every time I publish, I have to log into each one, paste the title, paste the content, fix the formatting, and hit publish. Five platforms, same content, one hour gone.

Last weekend I finally snapped. I built PolyPost.

What it does

Write in Markdown once. Check the platforms you want. Click publish. It handles the rest.

Under the hood it uses Playwright to control a real browser — opening each platform's publish page, filling in the title, body, and tags, then submitting. Each platform has its own adapter script to handle quirks like different editors, anti-bot detection, and cookie formats.

Tech stack

Backend: Python FastAPI + JWT auth
Automation: Playwright (Node.js child process)
Database: SQLite
Frontend: Vanilla HTML/CSS/JS, no framework
Deployment: Docker + Nginx

Core is under 2000 lines. Claude Code wrote most of the boilerplate — I focused on the platform-specific debugging.

Platforms supported

Articles: Juejin, CSDN, Zhihu, SegmentFault, Cnblogs, Dev.to
Video: Bilibili, Douyin (TikTok China), WeChat Video
Images/Text: Xiaohongshu (RED)

How to use

Online: http://42.193.173.160 (free registration)
Self-host: git clone, pip install, configure cookies, run
Docker: One command deploy

The real takeaway

This project took two days. Two years ago it would have taken me two weeks. AI-assisted development is a multiplier — not because the AI is smarter, but because it handles the 80% of work that is just wiring things together.

If you are not using AI in your dev workflow yet, start now. Not as a chatbot. As a coworker.

GitHub: https://github.com/wxfwxf911/polypost

Stars and PRs welcome.

让 9 个平台的内容发布从 30 分钟变成 30 秒

wxfwxf911 — Sat, 08 Aug 2026 16:38:16 +0000

痛点

每次写完技术文章，发布才是最痛苦的环节。我有 9 个平台的账号要维护：掘金、知乎、CSDN、博客园、思否、小红书、抖音、B站、微信视频号。

过去的标准操作：

打开掘金 → 粘贴标题 → 粘贴正文 → 选标签 → 发布
打开知乎 → 粘贴标题 → 粘贴正文 → 调格式（Draft.js 各种吞换行）→ 发布
打开 CSDN → 粘贴标题 → 粘贴正文 → 设分类 → 发布
...重复 ×6

写文章 40 分钟，发布 30 分钟。而且每次都要忍受不同平台编辑器的怪癖——有的不认 Markdown、有的吃空格、有的代码块语法高亮全丢。

于是我写了个工具：PolyPost。一次编辑，9 平台同步发布。开源。

GitHub: https://github.com/wxfwxf911/polypost

效果

在 PolyPost 的编辑器里写好文章（支持 Markdown + 富文本），勾选要发布的平台，点一下「发布」按钮。后端自动完成格式转换和推送。

对于不需要复杂交互的平台（掘金、CSDN、博客园、思否），直接调用 API 发布，秒级完成。对于需要浏览器操作的平台（知乎、小红书、抖音等），用 Playwright 模拟操作，但也比手动快得多——关键是你不用守着。

同时附带一个 Chrome 浏览器插件，一键提取各平台 Cookie，告别手工配置的麻烦。

技术实现

后端：Python FastAPI + SQLite。前端：原生 HTML/CSS/JS（无框架依赖，体积极小）。

支持平台及实现方式：

平台	类型	实现方式
掘金	文章	HTTP API（Markdown 原生支持）
CSDN	文章	HTTP API
思否	文章	HTTP API
博客园	文章	MetaWeblog API
知乎	文章	Playwright 浏览器自动化
小红书	图文	Playwright 浏览器自动化
抖音	视频	Playwright 浏览器自动化
B站	视频	Playwright 浏览器自动化
微信视频号	视频	Playwright + 微前端集成

一些有意思的技术细节

知乎使用 Draft.js 富文本编辑器，不能直接设 innerHTML，必须用 keyboard.insertText() 触发 React 合成事件
小红书 是 Vue SPA，编辑器路由切换要走 Vue Router 内部导航
视频号 用 wujie 微前端框架，DOM 藏在 <wujie-app> 的 Shadow DOM 里，普通的 CSS 选择器全部失效
抖音登录页直接内嵌在发布页 URL 里，需要靠 body text 实时检测扫码状态
B站视频上传有独立的分片上传组件，要等「重新上传」按钮出现才算上传完毕，期间还需要等待转码

每个平台都是独立的小工程，做完之后再回头看，这些"脏活累活"才是自动化最能发挥价值的地方。

其他功能

除了核心的一键多发，还陆续加了：

⏰ 定时发布 — 可以预约发布时间，全自动
📊 数据看板 — 实时统计发布成功率、各平台阅读量/点赞数
👥 多账号管理 — 支持多个同平台账号切换
🔍 文章管理 — 已发布文章列表、重发、删除

为什么开源

这个工具一开始只是为了解决自己的痛点。但后来发现很多做自媒体的朋友都有类似的困扰——内容分发是所有创作者绕不开的时间黑洞，但又不是每个人的核心业务，不值得花精力去优化。

开源出来，希望更多的人能用上。也欢迎提 Issue 和 PR。

GitHub 地址：https://github.com/wxfwxf911/polypost

觉得有用的话，给个 Star ⭐️ 就是最大的鼓励

后续计划

海外平台接入（Medium / Dev.to / Hashnode / Reddit）
文章翻译（中英互译，方便发海外平台）
AI 辅助优化标题和摘要

我做了一个多平台自动分发工具，7个平台一键发布，数据实时追踪，分享开发心得

wxfwxf911 — Wed, 05 Aug 2026 12:51:02 +0000

我是一个独立开发者，平时写博客需要在七八个平台之间来回粘贴排版，每次发布加修改格式至少要40分钟。久而久之就觉得很烦——能不能一次写好，一键发到所有平台？

于是动手做了 PolyPost，一个多平台内容分发工具。

能做什么

目前在7个平台跑通了发布和统计数据抓取：CSDN、掘金、知乎、Dev.to、SegmentFault、博客园、小红书。Medium 和 Hashnode 也在接入中。

核心流程很简单：

在编辑器写一篇 Markdown
一键推送到所有平台（自动适配各平台的格式差异）
每小时自动拉取各平台的阅读/点赞/评论数据
仪表盘统一查看所有平台的实时数据

技术栈

后端用的 FastAPI + SQLite，前端是原生 JS SPA。多平台发布的难点不在"发"，而在"适配"——每个平台都有自己的一套玩法：

知乎：Cookie 认证 + x-zse-96 签名算法（魔改 AES-CBC），文章发布要用 Playwright 浏览器自动化
掘金：API 层面已经比较规范，但 detail API 返回 err_no=2，最后用 query_list 遍历才拿到统计数据
CSDN：bizapi 只支持写入不支持读取，统计需要用 Phoenix 控制台 API
Dev.to：官方 API 设计不错，但文章详情端点不返回 page_views_count，要切到 /articles/me 端点
小红书：纯 Playwright 驱动，填表→一键排版→下一步→发布，每一步都像在拆盲盒

折腾下来最大的感悟是：做多平台工具的护城河不在功能本身，而在于踩完了所有平台的坑。知乎那个 x-zse-96 的逆向、CSDN 的 Phoenix API 发现、小红书的五重发布按钮定位策略——这些东西不是看文档能搞定的，只能一个一个趟。

实际使用效果

我自己用来发了 2 篇技术文章到 7 个平台，目前掘金显示 7 次阅读（其他平台因为文章较新或渠道差异数据还没起来）。但和之前手动分发相比，省下的时间才是真正的收益——差不多每次省 30-40 分钟。

下一步计划

这周刚把 PolyPost 从单用户改造成了多用户 SaaS，加了注册登录、免费/Pro 分层，准备对外运营。路线很清晰：

免费版开放 3 个平台、每天 2 篇，让用户先体验到省时间的爽感
Pro 版按月收费，全平台不限量
用 PolyPost 自己发「自动化搞副业」系列文章来引流——产品自己就是最好的案例

如果你也是多平台写作者，欢迎体验。我们一起把手动分发的苦差事交给脚本。