#WorkBuddy# 文章被驳回别慌：清洗正文后用 API 直提让 3 篇旧文重进审核

#WorkBuddy# 文章被驳回别慌：清洗正文后用 API 直提让 3 篇旧文重进审核

场景

批量发了十几篇技术文章，第二天一看：3 篇被驳回，理由就一句"部分内容格式有误"。点击"编辑"进去改完正文，点"提交审核"却毫无反应——按钮像坏了。这篇记录我定位根因、绕开编辑器死锁、最终让 3 篇全部重新进入审核的完整过程。

第一步：找根因，别急着改

把被驳回的文章和已过审的文章逐行对比，差异点浮出水面：被驳回的 3 篇正文里残留了"配图占位""（截图说明：…打码）"这类给排版流程看的元信息行。过审的文章里这些行全部被清洗掉了。

结论：发布管线里的正文清洗逻辑没对这 3 篇生效，元信息混进正文被判"格式有误"。

第二步：编辑页的死锁

用浏览器自动化打开编辑页改正文，遇到三个连环坑：

坑1: 正文容器在 markdown 模式下是 textarea，
     原生 setter + input 事件写进去是"假成功"，state 纹丝不动
坑2: 编辑器内部存在两个 React 实例，注入进了"假身"，
     保存按钮读了"真身"，拿到的是旧内容
坑3: 就算内容对了，点"提交审核"也静默无响应，
     深层的发布门禁 silently 跳过，界面不报任何错

试到第三层就明白了：这条路每一步都有暗坑，不如换路。

第三步：换路——API 直提

思路转变：与其跟界面搏斗，不如直接调它自己的接口。方法：

1. 新开一篇文章草稿，正常走一遍发布弹窗，
   用 performance 缓冲区抓下 CreateArticleDraft 的完整请求体
2. 把请求体里的 articleId 换成被驳回文章的 id，
   正文替换为清洗后的版本，action 改为 UpdateArticle
3. 在同一个已登录页面里用 fetch POST 回同一个 URL
4. 返回 code:0 → 重提成功，文章状态变为"审核中·修改于"

核心就一句：平台自己的接口，永远是比界面更稳定的通道。界面是给人用的，有层层校验和静默拦截；接口是给系统用的，成功失败都有明确回执。

结果与判定技巧

3 篇全部 code:0。重提后线上文章页仍显示旧版内容，这是正常的——新版本在审核队列里，通过后才会替换。判断"重提是否被接收"看文章管理列表的状态："审核中·修改于XX时间" = 平台已接收新版；只有"驳回"状态还在 = 没提上。

总结

1. 驳回先做版本对比找差异，别凭感觉改。
2. 自动化遇到连环暗坑，两次失败就该停手换路——界面死锁时，API 直提是最后的干净通道。
3. 重提成功的标志是状态进入"审核中"，而不是线上内容立刻变化。