自动化填不进去的编辑器：用剪贴板桥兜住最后一公里

写自动化脚本的人迟早会撞上一个尴尬时刻：选择器明明点中了输入框，fill 也返回了成功，但框里什么都没有。这时候最容易犯的错是继续换选择器——ref 不行换 CSS，CSS 不行换 XPath，半小时过去，页面还是空的。

前几天给一个 Issue 表单自动填内容时就栽在这上面。四个正文框，一个都填不进去。记录一下排查顺序和最后的兜底方案。

一、先确认它到底是不是"输入框"

无头浏览器报出来的可访问性角色很会骗人。四个正文框都被标成 textbox，看起来和普通输入框没区别。但把 HTML 拉出来一看：

<div contenteditable="true" class="cm-content cm-lineWrapping" role="textbox">

contenteditable，不是 input，也不是 textarea。这决定了后面所有方案的成败。

一个粗略但好用的判断：

- input / textarea → fill 基本都能成

- iframe 里的普通富文本 → fill 常常能成，失败会明确报错

- contenteditable + 框架接管（CodeMirror、ProseMirror、Slate、Quill）→ 大概率填不进去

第三类的问题不在选择器。这类编辑器自己维护一份内部状态，你直接把文字塞进 DOM，它下一次渲染就会把 DOM 重置回自己的状态——看起来像"填了又消失"，本质是你绕过了它的数据层。

二、报错信息要读懂

fill 的返回值得分开看：

- could not verify —— 文字其实已经进去了，只是框架刷新 DOM 太快，校验没读到。这种不用管

- target changed or lost focus —— 元素在填充过程中被重渲染，ref 失效

- 静默成功但内容为空 —— 最坑的一种，说明写进了一个被丢弃的节点

前两种可以重试一次；第三种重试多少次都一样，直接换手段。

三、兜底方案：走操作系统剪贴板

既然程序化写 DOM 不管用，就走真实用户的路径：把文本放进剪贴板，聚焦编辑区，发一次 Ctrl+V。真实按键事件会经过编辑器自己的事件处理，它认得。

三条命令，以 Windows PowerShell 为例：

Set-Clipboard -Value $text

# 聚焦编辑区

SendKeys "^v"

注意几点：

1. 文本要从文件读，不要从命令行参数传。几百字的中文塞进 shell 参数，引号、换行、$ 全是坑。

2. 剪贴板是全局资源。多个任务并发时会互相覆盖，必须串行，用完立刻清空。

3. 粘贴完要回读校验。字数统计、首尾关键字，挑一个能读到的东西确认，别假设成功。

4. 有的编辑器会拦截粘贴做格式清洗，纯文本模式反而更稳。

四、顺序比手段重要

这类问题的成本几乎全在"在一个不管用的方法上反复试"。比较省时间的做法是：

- 第一次失败：确认元素类型，看一眼 HTML

- 第二次失败：换一类手段（fill → 键盘输入 → 剪贴板）

- 第三次还不行：停下来，把现象记清楚，别继续

判断"元素是什么"这一步只要十秒，能省掉后面半小时。

五、小结

自动化不是"一种方法打天下"。fill 是快路径，不是唯一路径。真正稳定的脚本，是在快路径旁边备一条慢但可靠的兜底路径，并且知道什么时候该切过去。

编辑器越来越喜欢自己管 DOM，这个坑只会更多，不会更少。