捕获阶段无法可靠识别机器人，因为多数机器人不触发真实DOM事件流，而是直接调用element.click()或通过WebDriver指令绕过事件机制；无头环境可禁用监听器或重写addEventListener，且仅捕获阶段缺乏鼠标轨迹、时间间隔等关键行为特征。
JavaScript 无法在捕获阶段“过滤机器人点击”——因为机器人（尤其是无头浏览器、爬虫或自动化脚本）通常不触发真实的 DOM 事件，或者根本绕过浏览器事件机制。所谓“捕获阶段过滤”，本质上是对 click 等用户交互事件的监听与拦截，但这对大多数真实机器人无效，且容易误伤正常用户。
为什么捕获阶段不能可靠识别机器人
浏览器事件（包括捕获阶段的 addEventListener('click', handler, true)）只在真实用户操作或受控脚本主动派发事件时触发。而：
- 多数恶意点击机器人直接调用
element.click()或通过 WebDriver 发送指令，不经过事件流（捕获→目标→冒泡）； - 无头环境（如 Puppeteer）可禁用事件监听器、重写
addEventListener，或直接修改 DOM 状态； - 人机验证（如鼠标移动轨迹、时间间隔、坐标变化）需在更上层建模，仅靠事件捕获阶段无法获取足够特征。
更实际的前端人机识别手段
若目标是减少自动化提交/误点，应组合使用轻量级行为信号，而非依赖事件阶段：
- 隐藏 honeypot 字段：表单中添加 display:none 的输入框，机器人常会填充它，提交时后端校验该字段为空；
- 交互延迟检测：记录页面加载到首次点击的时间，
-
鼠标移动熵分析：监听
mousemove，统计路径长度、加速度、停顿次数，静止/直线移动倾向高则风险高（注意隐私合规）； -
被动指纹辅助：检查
navigator.webdriver、plugins.length、screen.orientation.type等非标准属性（但易被绕过，仅作参考）。
不要做的“伪防护”
以下做法看似技术感强，实则无效甚至有害：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 只在捕获阶段阻止
click并认为能拦住机器人——事件可被重放、跳过或直接调用方法； - 用
event.preventDefault()+ 捕获阶段阻止所有点击——会彻底破坏正常交互； - 依赖
event.isTrusted === false判定机器人——现代自动化工具可伪造为true，且部分浏览器扩展也会触发false。
真正有效的策略是分层防御
前端做轻量信号采集（如时间戳、交互序列），后端结合业务逻辑做风控（频率限制、IP/User-Agent 聚类、行为图谱）。关键不是“在哪个阶段监听”，而是“采集哪些不可轻易伪造的上下文”。例如：
- 按钮点击前，是否发生过自然滚动或悬停？
- 点击坐标是否落在按钮视觉中心附近（排除脚本盲点点击）？
- 同一 session 中，表单填写耗时是否符合人类文本输入速度模型？
这些判断需要综合多个事件和状态，远超单一捕获阶段的能力范围。
