uni-app如何实现自定义风格的滑块验证并支持防暴力刷

必须由后端生成验证码题并返回backgroundImg、sliderImg、blockX、blockY四字段，前端仅上报归一化偏移；所有图片需同源或base64；拖拽须用touch事件手动计算并限制范围；提交normalizedOffset而非像素值；后端须绑定captchaId校验且一次一图。

不能靠前端生成缺口图或校验坐标，必须由后端出题、前端只上报归一化偏移，否则防刷形同虚设。

后端必须返回 backgroundImg、sliderImg、blockX、blockY 四个字段

前端自己“挖图”或“算缺口位置”是典型错误。blockX 是缺口在背景图上的真实横坐标（单位 px），后端生成时就固定了，前端只负责把滑块拖到这个 X 附近；blockY 决定缺口图在背景图上的垂直对齐位置，缺它会导致拼图错位。所有图片必须是 base64 或同源 URL，避免小程序/APP 端 canvas drawImage 跨域失败。

• backgroundImg 和 sliderImg 必须来自同一次后端生成，尺寸一致，缩放比例一致
• 若用网络图，安卓真机需先 uni.downloadFile 缓存到本地临时路径再传给 drawImage
• blockX 值不能被前端推导（比如通过图片宽高 + 随机数生成），否则攻击者可绕过请求直接伪造提交

touchmove 中限制 X 轴范围并实时更新滑块 left

别用 @click 或 @longpress 模拟拖拽——它们无法连续捕获位移，且不兼容真机触控精度。必须用 touchstart/touchmove/touchend 手动计算。

• 记录 touchstart 时的 clientX 和滑块初始 left，在 touchmove 中用 e.touches[0].clientX - startX + startLeft 得到实时 left
• 用 Math.max(0, Math.min(computedLeft, maxWidth)) 严格限制范围（例如 maxWidth = 280），防止拖出界后松手触发错误校验
• 滑块 DOM 元素只更新 left 样式，不要每帧重绘 canvas，否则 H5 和小程序性能差异会暴露逻辑漏洞

touchend 里提交 normalizedOffset 而非像素值

提交 left 像素值是危险的：不同屏幕宽度下同一操作产生不同数值，后端容差难统一，还容易被逆向推导出 blockX。

• 正确做法是归一化：const normalized = parseFloat((left / maxWidth).toFixed(3))
• 同时必须附带本次验证的唯一标识，如 captchaId（由后端下发并绑定 session 或手机号）
• 后端收到后，按相同比例反推像素位置：userX = Math.round(normalized * maxWidth)，再与原始 blockX 做 ±5px 容差比对
• 额外加时间戳和简单设备指纹（如 UA 片段 + 屏幕宽高）可辅助风控，但核心仍是服务端绑定 + 归一化校验

防暴力刷的关键不在前端动画或提示语

所谓“防刷”，本质是让同一张图不能被重复提交、也不能被 A 拿去给 B 用。前端加个“3次失败锁1分钟”的 UI 提示毫无意义——攻击者直接跳过 UI 调用接口。

• 每次调用验证接口，后端必须生成新 captchaId，并销毁旧 id 对应的所有图数据
• 用户提交时，后端第一件事是查 captchaId 是否存在且未使用过；第二件事才是比对 normalizedOffset
• 前端 reset 方法（如 refreshScale()）只能重置 UI 状态，不能绕过后端重新发图逻辑
• 如果业务允许，建议滑块验证和短信验证码二选一，而非叠加——叠加反而增加被自动化工具枚举的攻击面

最常被忽略的一点：blockY 不仅影响视觉对齐，iOS 小程序上若 Y 偏移没对准，canvas clip 区域会错位，导致缺口图显示在错误高度，用户永远拼不对——但这不是前端 bug，是后端漏传或传错值。