必须由后端生成验证码题并返回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，是后端漏传或传错值。
