滑动验证码必须前后端协同完成，前端仅采集行为并提交Token，需拦截submit、等待组件异步验证通过后才提交，且token字段名、位置、格式须与后端严格一致。
滑动验证码不是前端能独立完成的校验
它必须配合后端接口，前端只负责采集用户操作行为并提交 token。直接在 form 里加 required 或用 checkValidity() 是无效的——浏览器根本不知道滑动结果是否合法。
常见错误现象：submit 事件触发后表单立刻提交，滑动框还没验证、甚至没加载完；或者前端伪造 token 字段绕过校验，导致后端收不到有效凭证。
- 滑动组件（如极验、腾讯云 TCAPTCHA、或自研）初始化后，会返回一个
validate方法或onSuccess回调，必须等这个时机才允许提交 - 不要把滑动结果塞进隐藏域后就不管了，要确保提交时该字段真实存在且非空，比如检查
document.getElementById('geetest_token').value - 后端验证失败时，应返回明确错误码（如
{"success": false, "msg": "verify failed"}），前端据此阻止提交并提示，而不是靠 http 状态码判断
form submit 前必须手动拦截并插入异步验证
html 表单默认同步提交，但滑动验证是异步的（要发请求、等服务端返回 token）。不拦截就会跳过验证直接发包。
使用场景：登录、注册、评论提交等需要防机器刷的入口。
立即学习“前端免费学习笔记（深入）”；
- 给
form绑定onsubmit事件，第一行写Event.preventDefault() - 调用滑动组件的
verify()或getValidate()方法，它通常返回 promise，await它再决定是否真正提交 - 如果组件不支持 Promise（如老版极验），要用
onSuccess回调 + 标志位控制，避免重复提交 - 别在
click事件里直接submit()表单，那会跳过onsubmit钩子，也绕过你的验证逻辑
token 字段名和传输方式必须前后端对齐
很多问题出在字段名拼错、大小写不一致，或把 token 放错位置（比如塞进 query String 而不是 request body）。
参数差异示例：geetest_challenge、geetest_validate、geetest_seccode 是极验 v3 的三个必需字段；而腾讯云用的是 ticket 和 randstr。
- 确认后端文档要求的字段名，严格匹配，包括下划线/驼峰/大小写
- token 一般随表单数据一起 POST，不是单独发请求；如果用
fetch提交，确保body是FormData或正确序列化的 json - chrome DevTools 的 Network 面板里点开提交请求，检查 Payload 是否包含该字段、值是否非空、格式是否像一串 base64 或哈希值
- 某些 SDK 会在验证成功后自动往
form插入隐藏域，但若你动态创建表单或用 Vue/React 管理状态，得手动 append 或同步到 state
移动端 touch 事件干扰导致滑动失败
在 ios safari 或部分安卓 webview 中，表单内嵌滑动组件容易因 touchmove 默认行为被阻止而无法拖动，或拖拽后没触发验证回调。
性能 / 兼容性影响：不处理会导致用户反复尝试、误以为功能坏了，实际是事件被吃掉了。
- 给滑动容器加 CSS：
touch-action: manipulation，禁用双指缩放和滚动干扰 - 避免在
body或父级绑touchstart/touchmove并调用preventDefault()，除非你精确控制作用范围 - 测试真机，特别是 iOS 16+，Safari 对
input聚焦和 touch 事件的处理更激进，有时聚焦输入框会意外中断滑动流程 - 如果用 iframe 加载滑动组件（如极验推荐方式），注意同源策略不影响通信，但
window.parent访问需确保 iframe 已加载完成
事情说清了就结束。最常被忽略的是：滑动成功 ≠ 验证通过，token 必须传给后端且由后端调第三方接口校验，前端只管“有没有”和“是不是空”，别信自己生成的 fake token。