发布成功之后Cherry 崩溃、导入 MD 与改一篇已上线的文章点下「发布」按钮页面跳出「发布成功」——如果你做的是自动化发文到这一步通常就鸣金收兵了。但真正耗时间的往往在后面回看线上文章发现代码块少了一半想改个错别字编辑器把正文吞了管理页的「编辑」按钮点完弹窗被浏览器拦了不报错也不弹窗。这篇文章记的是 2026-10-12 一个晚上我在腾讯云开发者社区的编辑器上连踩的三个坑以及最后的正解。全部有运行日志为证代码可以直接跑。一、坑一逐字打字正文被「崩溃」吃掉一半1.1 环境先认清腾讯云开发者社区的文章编辑器底层是 Cherry Markdown页面上能看到.cherry-editor容器正文区是 CodeMirror 5.cm-content另外还挂着一个隐藏的textarea#code。自动化脚本要往里面灌一篇几千字的文章第一反应是「模拟键盘」Runtime.evaluate拿不到编辑器实例Cherry 的实例存在闭包里外部不可达那就只能用Input.dispatchKeyEvent一个字符一个字符地打。1.2 诡异的现象输入过程一切正常光标跟着走高亮跟着变页脚字数一路上涨到 1547。点保存、点发布也都「成功」了。然后打开线上文章——正文只剩 720 字断点恰好落在第一个 shell 代码块中间就像文章被一把刀齐刷刷切掉一截。1.3 复盘不是网络问题是编辑器崩了把编辑器崩溃前后的状态拉出来对比结论很清楚崩因是 CodeMirror 5 在特定输入序列下 token 解析抛异常。最容易触发的是代码块内以#开头的行例如#!/usr/bin/env bash这种 shebang键盘事件是异步的脚本不等渲染完成就把下一行打了进去异常之后编辑器的状态机已经乱了后续输入全部打到一个「半死」的状态里Cherry 的自动保存管线很敬业——它忠实地把这个半截状态保存了上去。于是「输入时看到的 1547 字」和「保存后剩下的 720 字」之间隔着一次没人看见的崩溃。第一个「能过」的修法是跟崩溃共处代码块内逐字符keyDown(text)慢速打代码块外整行insertText快速灌。实测能过但每次发布都是赌——赌 CodeMirror 这次不崩。一篇五千字的稿子赌注是整篇文章。顺带还踩了一个直觉陷阱想走捷径直接给隐藏的textarea#code用setValue赋值再dispatchEvent(new Event(input))假装用户输入没用。Cherry 的内容在自己的状态里外部注入的值根本进不去它的管线赋值成功编辑器无动于衷。二、正解别再模拟键盘用编辑器自己的「导入 MD」2.1 思路转换编辑器工具栏本来就有一个「导入 MD」按钮。既然编辑器自己有 Markdown 导入管线为什么要让脚本在外面模拟一个人打字点「导入 MD」背后弹的是一个隐藏的文件选择框input[accept*.md]。让脚本走这条管子等于借编辑器自己的手灌稿。2.2 实现三步# 第一步点工具栏「导入 MD」按钮真实鼠标事件坐标取可见按钮的 rect 中点# 第二步用 CDP 找到隐藏的 file input 并直接塞文件DOM.getDocument# 拿到 input[accept*.md] 的 nodeIdDOM.setFileInputFiles# files: [/abs/path/article.md], nodeId: 上一步的 nodeId# 第三步等导入完成读页脚字数校验对应的页面内判断逻辑// 隐藏的 file input 就是导入 MD 的真正入口constfileInputdocument.querySelector(input[accept*.md]);// 校验信标页脚的 markdown 字符数不是 .cm-content 的 innerTextconstfooterdocument.querySelector(.cherry-editor-footer);constcharsfooter.innerText.match(/(\d)/);console.log(imported chars ,charschars[1]);2.3 为什么这是正解走原生管线Markdown 的解析、代码块语言标识、表格、列表全部由编辑器自己的导入逻辑处理格式保留完整不产生键盘事件CodeMirror 崩溃那条路径整个绕开不存在「赌这次不崩」的期望成本结果确定、可重复改稿等于用修好的文件重新导入一次同样的输入永远得到同样的结果这对自动化流水线比「手感」重要得多。还有一个实操细节校验要看页脚的 markdown 字符数不要看.cm-content的innerText。后者是渲染视图代码块折叠、虚拟滚动、语法高亮都会让它「看起来」缺字拿它当判据会被自己骗。三、坑二「存草稿」是个半个陷阱3.1 场景稿子写一半点「存草稿」心安理得地关掉页面。第二天打开草稿接着改——文章来源的单选按钮三个都没选中摘要空了标签空了。正文和标题都在但那三个发布必填项一个都没跟上。3.2 结论草稿快照里只有正文和标题文章来源、摘要、文章标签这三项发布必填不在草稿的保存范围里。重开草稿等于面对一张重新洗过的表单。这和上一篇《表单提交了但什么都没发生》是同一个教训的两面UI 上的「已保存」和「可发布」之间隔着一次完整的表单校验。草稿让你保存了正文但没有替你保存「发布的资格」。3.3 工程对策把发布三要素写进脚本的入参——标题、关键词、标签、摘要——每一轮发布全量重填填完再数一遍单选取值对不对、标签 chips 有几个、摘要长度够不够。不凭记忆不假设「上次填过」。// 发布前自检三要素一个都不能少constsourcedocument.querySelector(input[valueoriginal]);constsummarydocument.querySelector(textarea.summary, .summary-input);constchipsdocument.querySelectorAll(.cdc-tags-input__chip);if(!source.checked)returnFAIL: 文章来源未选;if(!summary.value.trim())returnFAIL: 摘要为空;if(chips.length0)returnFAIL: 标签为空;returnREADY;四、坑三改一篇已经发出去的文章4.1 常见的后续需求文章上线了发现代码块里有个笔误或者想补一段说明。去管理页找「编辑」——按钮的 onclick 是window.open(...)在自动化场景下合成调用被浏览器拦了既没弹窗也没报错。又是一次「静默丢弃」。4.2 正解URL 直导航根本不用管理页。腾讯云的编辑器 URL 形如https://cloud.tencent.com/developer/article/write-new/articleId直接导航过去加载出来的就是这篇文章的可编辑状态。URL 是唯一不会「静默失败」的入口——导航成功与否看location.href就知道。4.3 修复流水线两步第一步清空重导。把编辑器清空用修好的文件重新走一遍「导入 MD」。又是导入 MD——不用键盘就不会再崩。脚本里先全选删除再点「导入 MD」等页脚字数追上新文件的字符数。第二步补齐发布。重新填三必填点「更新发布」底层走editArticle接口而不是新建同时轮询网络面板确认这次发布请求真的发出了、回执是什么。发布后重新打开线上 URL 核对正文——只看编辑器里的状态不算数判据永远是线上页面。五、三条军规灌稿走文件导入不走键盘。凡是编辑器提供「导入文件 / 粘贴 Markdown」能力的优先用它。模拟键盘是最后手段且要接受「偶发截断」的期望成本——你看到的字数不等于保存上去的字数。校验信标选服务端视角的字段。页脚字符数、接口回执、线上页面正文都可信DOM 可见文本、UI 状态类名、按钮是否「看起来」点了都只能当参考。已发内容的编辑入口用 URL 直导航。window.open、管理页跳转、SPA 的 hash 路由能绕全绕。URL 是唯一不会「静默失败」的入口。六、后记发布成功不是终点。它是这篇文章开始被阅读的时刻也是自动化真正要跑的里程的开始修正、回看、再发布。一个晚上三个坑修完回头看每条军规背后都是一次「脚本成功了事情没发生」。而这类失败最狡猾的地方在于——它不报错。你只能靠判据活着字节数、回执、线上页面。把判据选对坑就踩不到第二次。