#WorkBuddy# 前端一改版，自动化全线失效：我是怎么重新摸出一条上传链路的

#WorkBuddy# 前端一改版，自动化全线失效：我是怎么重新摸出一条上传链路的

场景

我有一套跑了几个月的全自动发文管线：AI 写好文章，脚本打开浏览器、填标题、注入正文、传配图、点发布，一气呵成。某天中午它突然集体趴窝——正文里传图的操作全部失败，重试五次五次都是同一个报错。查看页面才发现：平台夜间把编辑器整个换掉了。原来依赖的代码编辑器组件彻底消失，换成了一套全新的富文本实现。所有自动化里凡是碰过编辑器的部分，全线阵亡。

过程

慌是没有用的，改版不会通知你。我给自己定了一套探路流程，这次全用上了。

第一步：清点现场，别急着改代码。 打开新编辑器，把可能的选择器挨个 query 一遍数数量。旧组件的挂载点数量是 0——确认不是"加载慢"而是"真没了"。这一步的价值是防止在错误的前提上继续盖楼。

第二步：找新锚点，优先用行为而非结构。 新编辑器传图的入口不再是隐藏的文件输入框，而是工具栏上一个带样式标记的按钮。我把锚点从"结构定位"改成了"行为定位"：点击按钮、用 file chooser 事件接住弹出的文件选择，配图逐张传入。每张图 20 秒左右，上传完 DOM 里图片的地址会从本地预览换成云端签名地址——这个变化本身就是"传完了"的信号。

第三步：抓请求验真伪。 新编辑器保存草稿时发的请求体是一层编码过的富文本结构。我在保存动作上挂了请求监听，把请求体抓下来、逐层解码，然后做两项硬校验：图床域名的出现次数等于传图张数、代码块标记存在。校验不过就不允许提交——这次五连败里，脚本其实每次都把校验做对了，拒绝提交保护了我没有发出一篇空图文章。

第四步：走直提接口收尾。 校验通过后，用同一个请求体调更新接口直提，返回 code:0，六张图全部落进正文。从发现改版到重新打通，一个多小时。

坑：最贵的学费是"想当然"

复盘时最扎心的是第一版修复：我以为只是选择器变了，改完就跑，结果失败在完全不同的地方——图传上去了，但按老路径从正文里抠图片地址，抠出来是 0 张。新编辑器的数据结构里，图片地址藏在编码层下面。失败日志就是路标：每一行"图 0/6"都在告诉我"不是入口错了，是出口也变了"。后来我养成了习惯：改版修复必须先把失败日志读穿，找到第一个与预期不符的字节，再动手。

总结

这次改版应急沉淀成四条探路军规：

1. 先清点再动手：所有旧锚点 query 计数，确认死透，避免在错误前提上盖楼；
2. 锚点用行为定位：按钮点击+文件选择事件这类"行为锚点"比 DOM 结构锚点抗改版得多；
3. 提交前必须硬校验：解码请求体，数图、验代码块，不过就拦——校验是自动化最后的保险丝；
4. 失败日志读穿再修：第一处不符预期的字节，就是新链路的入口。

附上探路时最常用的几段检查命令，可直接复制：

:: 1. 清点旧锚点(数量为0=真没了, 不是没加载)
document.querySelectorAll('.旧组件类名').length

:: 2. 挂请求监听, 抓保存动作的请求体
page.on("request", lambda r: "CreateDraft" in r.url and log(r.post_data))

:: 3. 硬校验: 图床域名计数 + 代码块标记
解码后.count("图床域名") == 预期张数 and "code-block" in 解码后.lower()

前端一定会再改版，管线也一定会再挂一次。但只要探路流程在，每次都是一小时的事故，而不是一天的灾难。