核心校验逻辑在后端，需综合验证最终偏移量、轨迹特征（速度、加速度、停留点）、耗时及token有效性，仅前端比对偏移或像素无效。
滑动拼图验证码的核心校验逻辑在哪
滑动拼图验证码不是纯前端能完成的——后端必须参与校验。前端只负责生成滑块轨迹、计算偏移量、提交 token 和 trace（轨迹数据），后端用算法判断是否为真实人类操作（比如速度突变、贝塞尔拟合度、停留点分布）。如果只在前端比对图片像素或固定偏移值，等于没设防。
前端怎么生成并提交合法的滑动轨迹数据
浏览器无法直接读取用户鼠标/手指的“真实物理移动”，只能采样 mousedown → mousemove → mouseup 事件。关键点在于：
- 采样频率不能固定（如每 50ms 一次），否则易被脚本识别；建议用
requestAnimationFrame动态采样，间隔在 30–120ms 波动 - 轨迹数据
trace必须包含时间戳、x/y 坐标、事件类型（move/down/up），且需 base64 编码或 JSON 序列化后提交 - 每次拖拽必须绑定唯一
token（由后端下发，单次有效），和图片缺口位置cutX一起参与签名，防止重放
示例提交字段：
{"token": "abc123", "trace": "eyAiZGF0YSI6IFt7IngiOiAxMjMsInkiOiA0NSwic..."}
后端校验时最容易忽略的三个条件
光验证最终偏移量是否接近 cutX 是远远不够的。真实攻击脚本常会伪造“完美直线”轨迹，所以后端必须检查：
立即学习“前端免费学习笔记（深入）”；
-
总耗时：低于 300ms 的基本是机器（人类平均 800–2500ms） -
加速度异常点：连续 3 次采样位移差 > 15px 且时间差 -
悬停行为：在起始点或缺口附近停留 > 200ms 的次数 ≥ 2，说明在观察或调试，需降权或拒绝
Node.js 示例校验片段（伪代码）：
if (trace.duration < 300 || countSuddenJumps(trace) > 1 || countHover(trace) >= 2) { reject(); }
为什么用 Canvas 渲染拼图比 DOM 更安全
DOM 元素（如 <div> 拼图块）可被 CSS 选择器直接定位、尺寸可被 getBoundingClientRect() 精确读取，攻击脚本几行代码就能算出缺口位置。而 Canvas 绘制的图块：
- 不暴露像素坐标，缺口位置由后端动态生成并加密下发
- 前端仅渲染，不持有原始图或 mask 图，截图也无法反推偏移
- 可叠加轻微噪声（如 1px 随机偏移、透明度扰动），让 OCR 或图像比对失效
注意：toDataURL() 导出 canvas 内容会破坏安全模型，严禁调用。
