自动化里 JS click 点不动按钮？从一次 Issue 提交失败聊起

这两天在给一个 GitCode 仓库提交 Issue 时遇到一个很典型的自动化坑：表单三个必填段落都填好了，标题也填了，用 element.click() 点"提交 Issue"按钮，页面毫无反应，网络面板里只有埋点请求，没有任何创建 Issue 的 POST。

排查了一圈才定位到原因：这个页面用的是 Tiptap 富文本编辑器（ProseMirror 内核），表单校验依赖的是编辑器实例的内部状态。JS 直接调 click() 虽然会触发 click 事件监听器，但某些框架层的合成事件链、焦点转移和 input 事件序列与真实交互并不完全等价，导致编辑器没有把内容"认领"进自己的 state，校验判定为空，按钮点击被静默拦截。

换成 Playwright 的 locator.click()（内部会滚动到元素、计算真实坐标、派发完整的事件序列）之后，一次就成功了。

一、JS click 和真实点击差在哪

1. 事件可信度：element.click() 派发的 isTrusted 为 false，部分安全校验会忽略非可信事件。

2. 焦点链：真实点击会先经历 pointerdown → mousedown → focus → mouseup → click 的完整序列，某些组件（尤其 contenteditable、自定义下拉）依赖中间事件更新状态。

3. 滚动与遮挡：JS click 不关心元素是否在视口内、是否被弹窗遮挡，照样"点得到"；真实点击会被遮挡元素拦截——反过来这也是个调试利器，Playwright 的 click 超时日志里会明确写出"被哪个元素拦截了 pointer events"。

4. React/Vue 合成事件：框架在 root 上做事件委托时，通常 click() 也能触发；但依赖 pointer 系列事件或 focus 变化的逻辑就可能漏掉。

二、实用的排查顺序

1. 先看网络面板有没有目标请求。没有请求说明被前端校验拦了，有请求但报错说明是后端问题。

2. 检查必填字段是否真的"进了"组件的 state——用键盘逐字输入（keyboard.type 带 delay）比一次性 value 赋值更接近真实行为。

3. 把 JS click 换成 Playwright 的 locator.click()，让框架自己处理滚动、等待和事件序列。

4. 如果 Playwright 也点不动，看它的报错，"subtree intercepts pointer events" 这句话会直接告诉你是哪个弹窗/遮罩在挡。

三、一个反向利用

这个"会被遮挡拦截"的特性其实很有用：当页面有个弹窗怎么都关不掉时，让 Playwright 去点弹窗下面的按钮，报错信息里会打印出拦截元素的完整选择器，比肉眼在 DOM 里翻快得多。

总结：自动化里"点不动"不一定是选择器写错了，很多时候是事件序列和真实交互不等价。优先用框架提供的真实点击原语，把 JS click 留给那些明确不需要完整事件链的简单场景。