前端页面「看起来能点」和「真的能点」之间，差了十万八千里

一个按钮为什么点了没反应

最近在写浏览器自动化，遇到一个反复出现的问题：明明页面上有个"提建议"按钮，元素存在、文字对得上、click() 也能调通，但点了就是没反应。

排查下来，这类问题至少有五种不同的成因，而且从代码上看几乎一模一样。

第一种：元素是隐藏的

页面上有两套提交按钮，一套在移动端容器里，一套在桌面端。用 querySelector 抓到的往往是第一个，而第一个是 display: none 的隐藏元素。

// 看起来没问题，其实是隐藏的那个
const btn = document.querySelector('.btn-submit');

// 应该先过滤可见性
const btn = [...document.querySelectorAll('.btn-submit')]
  .find(el => el.offsetParent !== null);

offsetParent === null 是判断元素是否可见的一个实用技巧：元素本身或祖先元素被 display:none 时它返回 null。注意 position: fixed 的元素 offsetParent 也是 null，这种情况要单独判断。

更隐蔽的一点：隐藏元素的 getBoundingClientRect() 返回全 0。如果你用坐标点击，就会点在屏幕左上角，什么都不会发生。

// 坐标点击前必须校验
const rect = el.getBoundingClientRect();
if (rect.width === 0 || rect.height === 0) {
  console.warn('元素不可见，坐标点击无意义');
}

第二种：React 等框架忽略了合成事件

很多前端框架的点击处理依赖事件的 isTrusted 属性。通过 element.click() 或 dispatchEvent(new MouseEvent(...)) 派发的事件 isTrusted 是 false，某些实现会直接忽略。

判断方法很简单：在控制台手动执行一次 .click()，如果没反应但鼠标真的点一下就有反应，那就是这个问题。

解决办法是走浏览器调试协议派发真实输入事件：

// Chrome DevTools Protocol
await send('Input.dispatchMouseEvent', {
  type: 'mousePressed', x, y, button: 'left', clickCount: 1, buttons: 1
});
await send('Input.dispatchMouseEvent', {
  type: 'mouseReleased', x, y, button: 'left', clickCount: 1
});

这样产生的事件 isTrusted 是 true，和真人操作没有区别。

第三种：点击被遮挡层拦截

元素可见、可点，但上面盖了一层透明遮罩。常见于下拉菜单、Tooltip、弹窗的蒙层。

// 这个 API 能直接告诉你顶部是谁
const top = document.elementFromPoint(x, y);
console.log(top);  // 如果不是目标元素，就是被挡了

我遇到过一个典型场景：自动填完表单后去勾选"同意协议"的复选框，点了十几次都没反应。查 elementFromPoint 才发现，标签输入框的下拉面板正好盖住了它。

处理方式不是硬点，而是先让遮罩消失：点击页面空白处触发 blur，或者按下 Escape。等遮挡层收起后再点。

第四种：富文本编辑器不是普通输入框

一整类编辑器（TinyMCE、CodeMirror、ProseMirror）不响应 input.value = ...，也不响应 insertText 到某个 div 上。

TinyMCE 的正规入口是它挂在全局的 API：

window.tinymce.get(0).setContent('<p>内容</p>');

CodeMirror 6 则是：

const view = document.querySelector('.cm-content').cmView.view;
view.dispatch({
  changes: { from: 0, to: view.state.doc.length, insert: '新内容' }
});

如果拿不到这些对象，退路是模拟真实键盘：先用真实鼠标点进编辑区获得焦点，再全选删除，最后用 Input.insertText 一次性灌入。这条路慢但通用，不依赖具体编辑器实现。

注意跨域 iframe 里的编辑器是另一个独立的调试目标，主文档的 querySelector 找不到它，必须单独连接。

第五种：参数校验静默失败

按钮点下去了，事件也触发了，但提交请求根本没发出——因为某个必填字段为空，而前端没有给出提示。

这类的排查方式是看网络面板。如果点击后没有任何请求，说明卡在本地校验。逐个检查必填项，尤其是那些不显眼的：隐藏的 checkbox、需要至少选一个的标签、有最小长度限制的文本域。

有个细节值得注意：字符计数器的显示值可能比你输入的少。我遇到过计数器显示 372 而实际内容 374 的情况，原因是编辑器把 HTML 实体算成了单个字符。如果校验依赖计数器，边界情况要留余量。

排查顺序建议

按成本从低到高排：

1. 看可见性 — offsetParent 和 getBoundingClientRect()
2. 看遮挡 — document.elementFromPoint(x, y) 返回的是谁
3. 看是否有请求 — 点了之后网络面板有没有新请求
4. 看事件类型 — 合成事件还是真实事件
5. 看组件实现 — 是不是富文本编辑器或自定义组件，有没有暴露 API

前四步基本能在控制台直接做完，不需要额外工具。第五步才需要去读页面代码或找组件文档。

小结

"点了没反应"这类问题，本质上是可点击性（clickability）和可触及性（reachability）的分离。DOM 里存在不等于用户能点到，用户能点到不等于事件处理器会响应。

写自动化脚本时，与其假设元素可用，不如每一步都先验证：元素可见吗？在视口内吗？顶部是这个元素吗？点完有反应吗？验证多花的时间，远比在"为什么没反应"上猜半天要少。

同样的问题在手工测试时也存在。判断一个界面是否真的可用，不能只看代码里有没有绑定事件，还得真的点一下试试。