滑块验证码拖拽完成事件需通过sdk回调监听而非原生dom事件；极验用onsuccess、腾讯云用onverify、阿里云用success回调；“完成”不等于“通过”，须以sdk验证成功回调为准，服务端必须二次校验token。
滑块验证码的拖拽完成事件通常不是浏览器原生提供的，而是由第三方验证码服务（如极验 Geetest、腾讯云验证码、阿里云人机验证等）封装的自定义事件。你需要通过其 SDK 提供的 API 来监听，而不是直接用 oninput 或 onchange 监听原生 <input type="range">。
确认你用的是哪个验证码 SDK
不同服务商暴露的完成事件名和监听方式不同，常见情况如下：
-
极验（Geetest v4）：调用
onSuccess回调，或监听实例的success事件 -
腾讯云「验证码」（Captcha）：使用
onVerify配置项或监听verify事件 -
阿里云「人机验证」：通过
success回调函数接收验证成功结果 - 若你只是用原生
<input type="range">模拟滑块（不推荐用于真实风控场景），可监听change（松手后触发）或input（实时拖动中），但无法代表“验证完成”
以极验 Geetest v4 为例监听拖拽完成
初始化后，通过 onSuccess 获取验证成功凭证：
const handler = window.initGeetest4({
captchaId: 'your-captcha-id',
product: 'bind',
onSuccess: function () {
// ✅ 拖拽完成且验证通过时触发
const result = handler.getValidate();
console.log('验证通过，token:', result);
// 此处可提交表单或调用登录接口
}
}, function (captchaObj) {
// 初始化成功回调，可绑定其他事件（如刷新、错误）
});
注意“完成”不等于“通过”
滑块拖拽结束 ≠ 验证成功。部分 SDK 会先触发拖拽结束（如 dragend），再异步校验行为特征（轨迹、时间、IP 等）。真正可靠的完成监听点是 SDK 明确标识验证成功的回调（如 onSuccess、onVerify），而非 DOM 事件。
避免以下错误做法：
- 监听
input或change到 100% 就认为验证成功（容易被绕过，无服务端校验） - 自己监听
mouseup或touchend（无法判断是否通过风控） - 未等待 SDK 异步校验返回就提交 token（可能为空或无效）
服务端必须二次校验
前端监听到“完成”仅用于流程控制，最终是否放行必须由服务端调用验证码厂商的校验接口（如 /validate）来确认。前端拿到的 token 只是临时凭证，不可信。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
