滑动验证码这东西大家都不陌生。但大多数人用的是第三方服务商现成的方案比如某云、某盾接入简单但费用和定制性都是问题。今天我把一套手写滑动验证码完整记录下来前后端代码全开放不依赖任何第三方SDK可以自己部署、自己定制、也能作为安全研究的学习素材。这套方案实现了拼图式滑块的核心机制随机生成缺口、前端拖动拼接、后端校验轨迹与位置。适合想搞懂验证码底层原理或者需要私有化部署验证能力的开发者读完可以直接把代码拿去改造。我最初做这个项目是因为公司内部的某个系统要上滑块验证但数据不出内网不能接外部服务。于是花了一周多时间从切图到轨迹校验完整走通了一条手写方案。过程中踩了不少坑——跨域图片画布污染、不同浏览器的鼠标事件差异、移动端触摸事件兼容、还有后端校验时要防止重放攻击。这篇文章把这些细节全展开配合可运行的完整代码尽量让拿到手的人能少走弯路。1. 整体设计拆解为什么选择拼图式滑块滑动验证码不是只有一种形态常见的就有两种一种是拼图式背景图上有一个缺口拖动滑块把拼图块对齐进去另一种是纯轨道式把滑块从左边拖到右边靠速度判断。我选择实现拼图式核心原因是它的安全强度和交互明确度都更好。先说说验证逻辑背后的思路。拼图式看起来考验的是“对齐”但机器如果知道缺口坐标想对齐根本不难几行代码就能精确移动到目标位置。所以真正的校验不再看“最终对不对”而是看“你过去它的过程像不像人类”。人手的滑动有加速、减速、轻微抖动和神经反应延迟这是机器模拟最刻意的地方。整套系统设计要做的就是前端捕获真实的运动轨迹后端综合距离、耗时、轨迹特征三项给出信任评分。这里有两个关键选型值得说清楚。第一为什么拼图缺口必须“随机”。如果缺口固定在某个位置机器人直接记住坐标就能过那验证码就和没有一样。我实现的方案是每次加载验证码时在允许边界内随机生成两个坐标准一个横向位置X一个纵向位置Y。X规定了拼图块最后的落点Y则决定拼图块在背景图中的高度。两个值都用服务端生成的核心随机数不入库、不重复、一次性有效。第二验证时序上不能用“前端告诉后端答案”这种简单模式。很多新手手写验证码的时候会在前端生成缺口位置再在前端提交时把位置一并POST给后端。这完全没意义——任何人用浏览器调试工具改一下坐标就绕过了。我这里的做法是缺口坐标由后端在初始化接口返回的同时加密进一个一次性Token里。前端提交校验的时候后端不信任前端传上来的坐标只从Token里解密还原真实坐标再和前端传来的拖动距离做比较。这样前端根本没有机会伪造答案因为答案不从前端来。在轨道的交互形态上我也做了取舍。市面上有些方案是按住滑块直接拖拼图这个最简单也有方案是点击按钮触发验证、出现拼图后再拖动。我采用后者初始状态下滑块条上有一个“点击开始”状态的按钮点击后才进入拖动模式。好处是能过滤掉一部分无意识的机械自动行为更重要的是给前端留出鼠标事件绑定的时机避免页面刚加载就拖导致事件丢失。2. 前端核心实现拼图生成、拖动交互与轨迹采集这一部分是整个方案里最直接让用户感知效果的地方也是代码密集区。我拆成三个环节来讲背景与缺口的生成、滑块交互处理、轨迹数据的采集与打包。2.1 背景图与拼图块的生成逻辑组件初始化时前端会请求后端接口拿到一张背景图片和对应的Token。为了演示方便我在纯前端Demo里用Canvas动态生成背景——随机渐变背景加一些随机图形模拟成一张“图”。生产环境中你完全可以把这段动态绘图替换成后端返回的真实图片或者随机从本地图库抽图。拼图块生成的核心是“切图”。我用Canvas的getImageData和putImageData把背景图上某一块区域的像素复制到拼图Canvas里再给拼图块的边缘画上浅浅的描边和阴影视觉上更立体也方便用户在背景缺口上进行比对。function createPuzzlePiece(bgCanvas, gapX, gapY, pieceSize) { const pieceCanvas document.createElement(canvas); pieceCanvas.width pieceSize; pieceCanvas.height pieceSize; const pieceCtx pieceCanvas.getContext(2d); const imageData bgCanvas.getContext(2d).getImageData(gapX, gapY, pieceSize, pieceSize); pieceCtx.putImageData(imageData, 0, 0); pieceCtx.strokeStyle rgba(255,255,255,0.7); pieceCtx.lineWidth 2; pieceCtx.strokeRect(0, 0, pieceSize, pieceSize); pieceCtx.shadowColor rgba(0,0,0,0.4); pieceCtx.shadowBlur 8; pieceCtx.strokeRect(1, 1, pieceSize - 2, pieceSize - 2); return pieceCanvas; }这里有个容易被忽视的细节getImageData处理的是像素级拷贝如果你从一张跨域的图片上截图Canvas会被浏览器标记为“被污染”后续调用toDataURL或getImageData时直接抛安全错误。这就是为什么生产环境的后端接口必须返回同源图片或者让图片资源和接口共用一套域名与CORS策略。我在Demo里用动态绘图天然避开了这个坑但换真实图片时你一定要注意。缺口阴影锚点画法也很重要。用户需要知道把拼图块拖到哪个位置算“到位”。做法是在背景Canvas上以 (gapX, gapY, pieceSize, pieceSize) 为矩形区域绘制一个半透明的白色/黑色矩形并让这个矩形轮廓外圈虚化。我测试下来白色背景上用黑灰色蒙层更不刺眼深色背景上则反过来。2.2 拖动滑块的事件处理细节拖动事件分三件套按下mousedown/touchstart、移动mousemove/touchmove、松开mouseup/touchend。我把状态机写成一个简单的三态常量IDLE表示未激活ACTIVE表示已按下滑块准备拖动DONE表示已完成一次拖动。需要处理的核心点有两个事件绑定时机和坐标系换算。事件绑定时机上初始只给滑块按钮绑定 mousedownmousemove 和 mouseup 不在全局绑定而是等 mousedown 触发后才动态挂到 document 上松手后立即解绑。这样做是为了避免页面在非拖动状态下也响应 mousemove造成不必要的性能开销同时也是为了屏蔽那些先自动模拟 mousemove 再模拟 mousedown 的作弊脚本。坐标系换算直接决定拖动精度。滑块放在整个轨道容器内部轨道左端到缺口中心点的距离和拼图块要移动的距离之间存在一个比例关系。不要把鼠标事件里的clientX直接用要用它相对轨道容器的偏移const rect trackWrap.getBoundingClientRect(); const offsetX e.clientX - rect.left; const maxDist trackWrap.offsetWidth - sliderBtn.offsetWidth; let moveX Math.min(maxDist, Math.max(0, offsetX - startOffset));其中startOffset是按下时鼠标在滑块内部相对滑块左边缘的偏移这样可以把基本都是按在滑块正中的操作归零。如果不减去startOffset滑块会突然“跳一下”观感很怪。这是从真实使用中发现的体验细节新手很容易漏掉。拼图块跟随滑块移动我用的是transform: translate3d(moveX, 0, 0)而不是改left。理由是transform只触发合成层更新不触发布局与重绘60帧拖动手感明显更顺滑尤其在高分屏下。拼图块的CSS样式里预先设置了绝对定位在背景图的左上角位置上translate3d的X值就对应横向位移Y保持不动。2.3 轨迹数据怎么记录才有效后端的“人机判定”完全依赖前端提交的轨迹数据所以我在这块做了严格封装。每次 mousemove 事件触发时记录一个采样点const sample { x: Math.round(moveX), y: Math.round(offsetY), t: Date.now() - startTime }; track.push(sample);完整轨迹由三个字段组成横向位移、纵向坐标因为人手并不能保证完全精准地沿直线拖动会有轻微上下浮动的、还有相对开始拖动的时间差。这三个字段合并起来就是后端判断的原料。采样频率也存在一个平衡点。事件监听每次mousemove都push生成的轨迹数组可能长达几百条。轨迹数据要打包进加密请求里太长了会拖慢请求速度太短了又没有分析价值。实测下来50到200个采样点是比较合理的区间。我这个Demo里自然触发大概会采集100个点左右如果要降采样可以直接对track做间隔抽取。在松手时我会把当前位移、轨迹数组、总耗时、以及页面的User-Agent打成一个对象连同Token一起发给后端。UA在后端校验时可以辅助判断是否出现了可疑的自动化设备指纹。3. 后端校验位置、Token、轨迹三重判定前端把数据POST上来之后后端不能只看“位置对不对”要依次做三道校验Token合法性校验、距离容差校验、轨迹行为特征校验所有校验都通过才算成功。我按实际后端代码的顺序展开。3.1 Token的设计与解密校验初始化时生成的Token我用了对称加密方案后端持有密钥把{gapX, gapY, expireAt, nonce}序列化成JSON字符串加密后返回给前端。前端提交校验时后端先解密、验签然后依次检查过期时间和一次性使用状态。一次性状态这步很关键。Token不能重复使用否则A用户拿到Token校验通过后B用户可以直接重放这个请求。我用了内存中的Redis计数器Token里存一个随机nonce校验完成后向Redis写入这个nonce下次再见到就直接拒绝。生产环境用Redis、本地开发用内存Map都可以。加密细节不多说用AES-GCM密钥只在服务端配置里前端完全没有接触的可能。这样哪怕前端JS被逆向攻击者也只能拿到密文解不出缺口坐标。3.2 距离校验的误差容差设定解密后后端得到真实缺口横坐标gapX。前端传上来的距离是clientX——也就是拼图块最终被拖拽的位移。两者在数值上还有一个映射关系并非相等。因为背景图和拼图块在Canvas坐标系里是1:1关系拼图块的位移就等于缺口坐标这个映射是线性的所以我可以直接比较。但真实拖动不可能每次都精准落在中心点上——人手本来就存在几像素的偏差。距离校验时我设置的容差是正负3像素。容差太小了人类用户会频繁误判太大了机器人就太好过。经过几百次真人和脚本双重复测3像素对正常手指影响很小对精确计算的脚本是显著性障碍。const distanceDiff Math.abs(gapX - clientX); if (distanceDiff 3) { return { pass: false, reason: position_mismatch }; }这段逻辑看起来平平无奇但真正想绕过的攻击者往往在第一步就会放弃——因为他们要让自己的题目“位置校验通过”必须把缺口坐标猜出来或者逆向Token拿到坐标这就把成本拉上去了。3.3 轨迹行为特征的判定思路这是整个手写验证码里最能拉开差距的地方。机器模拟的轨迹和人类轨迹在统计特征上差异明显我梳理出四个打分维度第一是总耗时。人类从按下到松手正常在0.8秒到2.8秒之间。太快0.4秒内说明是脚本直接瞬移太慢超过5秒可能是等待或思考都会扣分。第二是轨迹点数。纯脚本模拟的拖动可能是从起点到终点直接补的几个均匀点而人类拖动通常会产生数十个摆动点。点数过少直接判可疑。第三是加减速曲线。人类拖动滑块启动时会有一个加速过程临近目标点时又会减速、微调。最典型的特征是存在“顿挫”多处小的速度波动而不是匀速直线。我把相邻两采样点之间的位移差分转成速度序列计算速度序列中极值点的分布密度。第四是纵轴抖动幅度。人手沿水平方向拖动时不可能严格保证Y坐标不变总会有1到2像素级的上下浮动。机器模拟则通常保持在一条直线。计算所有轨迹点Y坐标的标准差如果远小于某个阈值很可能就是无机计算出来的。四个维度综合出一个打分。我设定了等级机制总分80分以上直接通过40分以下直接拒绝中间地带提示用户“再试一次”。这个机制不算精尖复杂但足以过滤掉大量初级攻击脚本和纯逻辑校验相比已经是质的提升。对于更高强度的对抗现在公认的方向是引入模型判定——把轨迹数据喂给一个预先训练的异常检测模型或者干脆在深度学习模型里学习人类滑动特征。但作为从零手写的方案统计规则足够覆盖多数应用的需求了。4. 完整代码实现可直接复现下面给出一个可以直接在本地跑通的完整版本。我的设计是不在HTML里写死缺口坐标而是前端初始化时在JS里随机生成同时在后端校验时通过Token解密来比对。为了让演示环境不需要额外装数据库和Redis后端Demo我用了纯内存状态。生产部署时把内存状态换成Redis即可。4.1 后端接口代码Python示例用Python写后端框架用Flask依赖只有flask、pycryptodome代码量可控。我实现了三个核心路由初始化验证码、校验验证码、以及图片生成的静态资源。先看初始化接口import os import json import random import base64 from datetime import datetime, timedelta from flask import Flask, jsonify, request, send_file from Crypto.Cipher import AES import io import time app Flask(__name__) SECRET_KEY byour-secret-key-16bytes def encrypt_token(data): nonce os.urandom(12) cipher AES.new(SECRET_KEY, AES.MODE_GCM, noncenonce) ciphertext, tag cipher.encrypt_and_digest(json.dumps(data).encode()) return base64.b64encode(nonce tag ciphertext).decode() def decrypt_token(token): raw base64.b64decode(token) nonce, tag, ciphertext raw[:12], raw[12:28], raw[28:] cipher AES.new(SECRET_KEY, AES.MODE_GCM, noncenonce) return json.loads(cipher.decrypt_and_verify(ciphertext, tag)) used_tokens set() # 动态背景图生成这里生成的是写有随机数字的图片实际生产可换成真实图片 app.route(/api/captcha/init) def init_captcha(): gap_x random.randint(60, 250) gap_y random.randint(40, 140) piece_size 50 expire_at time.time() 120 payload { gapX: gap_x, gapY: gap_y, pieceSize: piece_size, expireAt: expire_at, nonce: os.urandom(8).hex() } token encrypt_token(payload) # 这里把我的简化生成图形拼图逻辑合并成一份PNG二进制流返回给前端 # 具体后端生成图片的代码在后文给出 return jsonify({ token: token, gapX: gap_x, gapY: gap_y, pieceSize: piece_size })这里我要坦白说一个细节真实的滑动验证码中gapX不应该直接返回给前端。因为直接返回会让前端拿到缺口坐标机器人直接读JS变量就能获取。真实的架构应该是后端返回一张带缺口的背景图和一份加密Token前端从背景上识别缺口位置需要靠视觉比对而不是解析接口字段。Demo里为了先让核心逻辑跑通我先返回明文坐标。想用于生产的话可以删掉返回给前端的gapX/gapY明文字段前端改为对背景图做像素级缺口检测来定位拼图位置。校验接口是重点完整代码如下app.route(/api/captcha/verify, methods[POST]) def verify_captcha(): data request.get_json() token data.get(token) client_x data.get(clientX) track data.get(track) elapsed data.get(elapsed) if not token or client_x is None: return jsonify({pass: False, reason: missing_param}) try: payload decrypt_token(token) except Exception: return jsonify({pass: False, reason: invalid_token}) if payload[nonce] in used_tokens: return jsonify({pass: False, reason: reused_token}) used_tokens.add(payload[nonce]) if time.time() payload[expireAt]: return jsonify({pass: False, reason: token_expired}) gap_x payload[gapX] distance_diff abs(gap_x - client_x) if distance_diff 3: return jsonify({pass: False, reason: position_mismatch}) # 轨迹特征校验 score 100 if elapsed 400: score - 40 elif elapsed 5000: score - 30 if len(track) 10: score - 50 # 计算速度波动 speeds [] for i in range(1, len(track)): dt max(track[i][t] - track[i-1][t], 1) dx abs(track[i][x] - track[i-1][x]) speeds.append(dx / dt) if len(speeds) 2: mean_speed sum(speeds) / len(speeds) variance_speed sum((s - mean_speed) ** 2 for s in speeds) / len(speeds) if variance_speed 1: score - 30 # 计算Y轴抖动 y_values [p[y] for p in track] y_std (sum((y - sum(y_values)/len(y_values))**2 for y in y_values) / len(y_values)) ** 0.5 if y_std 0.5: score - 20 return jsonify({ pass: score 60, score: score, reason: ok if score 80 else need_retry })我用一个简单的评分函数替代了严格的多级规则并且把阈值设置在60分交互上更友好。实际部署时可以根据业务要面对的威胁强度调整阈值。为了确保完整可运行我再补充一段动态生成背景图的函数这里我生成一张带渐变色的矩形构成图作为可用背景import struct import zlib import math def generate_slide_bg(gap_x, gap_y, piece_size): width, height 350, 200 rows [] for y in range(height): row bytearray([0x00]) for x in range(width): # 简单渐变背景 r (x * 255 // width) g (y * 255 // height) % 200 30 b 160 # 缺口的阴影提示区域 if gap_x x gap_x piece_size and gap_y y gap_y piece_size: r 0 g 0 b 0 row bytes([r, g, b]) rows.append(bytes(row)) raw_data b.join(rows) encoder zlib.compressobj(9) data encoder.compress(raw_data) encoder.flush() def chunk(tag, data_bytes): return tag struct.pack(I, len(data_bytes)) data_bytes struct.pack(I, zlib.crc32(tag data_bytes) 0xffffffff) png b\x89PNG\r\n\x1a\n png chunk(bIHDR, struct.pack(IIBBBBB, width, height, 8, 2, 0, 0, 0)) png chunk(bIDAT, data) png chunk(bIEND, b) return png这部分比较基础主要是让没有本地素材的人也能直接生成可用的图片资源。这部分我用了纯Python生成PNG没有引Pillow部署时少一个依赖。4.2 前端完整页面单文件HTML为了省事前端我合并成一个单页HTMLCSS、JS、DOM都在一个文件里方便调试。生产环境拆成独立资源文件即可。!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title手写滑动验证码/title style * { box-sizing: border-box; margin: 0; padding: 0; } body { font-family: PingFang SC, Microsoft YaHei, sans-serif; background: #f5f6f8; display: flex; justify-content: center; align-items: center; height: 100vh; } .captcha-wrap { width: 380px; background: #fff; border-radius: 10px; box-shadow: 0 6px 24px rgba(0,0,0,0.08); padding: 24px; } .captcha-title { font-size: 16px; font-weight: 600; color: #333; margin-bottom: 16px; } .captcha-canvas-wrap { position: relative; width: 350px; height: 200px; margin-bottom: 16px; border-radius: 8px; overflow: hidden; background: #eee; } #bgCanvas { display: block; width: 350px; height: 200px; } #pieceCanvas { position: absolute; top: 0; left: 0; transform: translate3d(0, 0, 0); image-rendering: pixelated; } .slider-track { position: relative; width: 350px; height: 44px; background: #f0f0f0; border-radius: 22px; border: 1px solid #e0e0e0; } .slider-fill { position: absolute; left: 0; top: 0; height: 100%; background: #7bb7f7; border-radius: 22px; width: 0; } .slider-btn { position: absolute; left: 0; top: 0; width: 48px; height: 42px; background: #fff; border: 1px solid #d0d0d0; border-radius: 21px; text-align: center; line-height: 40px; cursor: pointer; font-size: 18px; color: #888; user-select: none; } .slider-btn.active { border-color: #4a9eff; color: #4a9eff; } .status-text { margin-top: 12px; font-size: 14px; color: #666; text-align: center; } /style /head body div classcaptcha-wrap div classcaptcha-title手写滑动验证码演示/div div classcaptcha-canvas-wrap canvas idbgCanvas width350 height200/canvas canvas idpieceCanvas width50 height50/canvas /div div classslider-track idsliderTrack div classslider-fill idsliderFill/div div classslider-btn idsliderBtn→/div /div div classstatus-text idstatusText点击滑块开始验证/div /div script const bgCanvas document.getElementById(bgCanvas); const bgCtx bgCanvas.getContext(2d); const pieceCanvas document.getElementById(pieceCanvas); const pieceCtx pieceCanvas.getContext(2d); const sliderBtn document.getElementById(sliderBtn); const sliderFill document.getElementById(sliderFill); const trackWrap document.getElementById(sliderTrack); const statusText document.getElementById(statusText); let gapX 0, gapY 0, pieceSize 50; let track []; let startTime 0; let dragging false; let startOffsetX 0; const PIECE_SIZE 50; function drawBackground() { bgCtx.fillStyle #2c8cff; bgCtx.fillRect(0, 0, 350, 200); // 随机画几个色块模拟真实图片 const colors [#ffad60, #60d394, #8395e6, #f76d6d, #ffd166]; for (let i 0; i 30; i) { bgCtx.fillStyle colors[Math.floor(Math.random() * colors.length)]; const x Math.random() * 350; const y Math.random() * 200; const w 20 Math.random() * 50; const h 20 Math.random() * 40; bgCtx.fillRect(x, y, w, h); } } function drawGapShadow() { bgCtx.save(); bgCtx.fillStyle rgba(255,255,255,0.6); bgCtx.shadowColor rgba(0,0,0,0.6); bgCtx.shadowBlur 12; bgCtx.beginPath(); bgCtx.rect(gapX, gapY, PIECE_SIZE, PIECE_SIZE); bgCtx.fill(); bgCtx.restore(); } function createPiece() { const imageData bgCtx.getImageData(gapX, gapY, PIECE_SIZE, PIECE_SIZE); pieceCtx.clearRect(0, 0, PIECE_SIZE, PIECE_SIZE); pieceCtx.putImageData(imageData, 0, 0); pieceCtx.strokeStyle rgba(255,255,255,0.8); pieceCtx.lineWidth 2; pieceCtx.strokeRect(0, 0, PIECE_SIZE, PIECE_SIZE); } function resetCaptcha() { gapX 40 Math.random() * 260; gapY 30 Math.random() * 110; track []; sliderBtn.style.left 0px; sliderFill.style.width 0px; pieceCanvas.style.transform translate3d(0, 0, 0); statusText.textContent 点击滑块开始验证; sliderBtn.classList.remove(active); drawBackground(); drawGapShadow(); createPiece(); } sliderBtn.addEventListener(mousedown, (e) { dragging true; startTime Date.now(); track []; const rect trackWrap.getBoundingClientRect(); startOffsetX e.clientX - sliderBtn.getBoundingClientRect().left; sliderBtn.classList.add(active); statusText.textContent 拖动滑块将拼图对准缺口; }); document.addEventListener(mousemove, (e) { if (!dragging) return; const rect trackWrap.getBoundingClientRect(); const maxDist trackWrap.offsetWidth - 48; let moveX Math.min(maxDist, Math.max(0, e.clientX - rect.left - startOffsetX)); sliderBtn.style.left moveX px; sliderFill.style.width moveX px; pieceCanvas.style.transform translate3d(${moveX}px, 0, 0); track.push({ x: Math.round(moveX), y: e.clientY - rect.top, t: Date.now() - startTime }); }); document.addEventListener(mouseup, () { if (!dragging) return; dragging false; sliderBtn.classList.remove(active); const clientX parseInt(sliderBtn.style.left, 10); const elapsed Date.now() - startTime; // 演示模式这里直接做本地比对 const diff Math.abs(gapX - clientX); if (diff 3) { statusText.textContent 验证通过; } else { statusText.textContent 位置有${Math.round(diff)}px偏差请重试; setTimeout(resetCaptcha, 600); } }); resetCaptcha(); /script /body /html这个版本是纯演示的最核心的逻辑都能跑通一看就懂。需要接入真实后端时把集成方案改成下面这样第一步页面加载时用fetch(/api/captcha/init)拿到gapX/gapY/token然后绘制背景和拼图。第二步在鼠标松开时把clientX、track、elapsed和token一起POST到/api/captcha/verify后端返回 pass 判定后前端根据结果显示成功或重试。如果你遇到的第一个版本里用了纯前端本地判断那么恭喜你已经拥有了完整理解拼图式验证码的能力。未来把校验逻辑迁移到后端只需要改一小段代码的请求发送部分整体结构完全不变。4.3 前后端联调时的接口协议定义前端和后端的协作必须靠协议约束。把联调中使用的字段列在下方方便直接当设计文档用字段名类型说明传输方向tokenstring初始化时返回的加密令牌后端生成前端提交gapXnumber缺口横坐标初始化返回生产慎用后端到前端gapYnumber缺口纵坐标后端到前端pieceSizenumber拼图边长后端到前端clientXnumber最终拖动距离前端到后端elapsednumber总耗时毫秒数前端到后端trackarray轨迹采样点列表包含 x/y/t前端到后端这个协议里需要重点强调的是生产环境下别把gapX直接给前端。正确做法是前端拿到背景后用类似“图像匹配”的方式自行估算缺口位置或者让后端把缺口绘制在背景上同时删去明文字段。哪种方案都有利弊但从工程角度讲减小信息泄露面永远是安全优先。5. 上线过程中我踩过的坑与最终推荐参数手写一版能跑的滑块不难但要做到生产可用坑都在细节里。这一章把我在真实环境中被折磨过的问题列出来。5.1 跨域图片导致Canvas被污染最一开始我图省事背景图直接用外链图片结果用户打开页面后识别缺口坐标时报错Unable to get image data from canvas because it has been tainted by cross-origin data。这是Canvas安全策略的直接反馈。解决方案有三个层次优先选择同源图片资源或者在后端代理转发图片避免跨域请求其次如果图片确实只能CDN部署要在服务端为CDN配置正确的CORS响应头Access-Control-Allow-Origin同时前端加载图片时给img标签加上crossOriginanonymous属性最后实在不行就用Canvas自己生成动态背景绕开跨域问题。5.2 移动端触摸事件与手势冲突桌面的鼠标事件在移动端完全失效所以必须兼容touchstart/touchmove/touchend。加了触摸事件后又遇到一个问题用户滑动滑块时页面会跟着上下滚动体验非常差。解决办法是在touchmove里调用e.preventDefault()并把滑块轨道容器CSS里加上touch-action: none。sliderBtn.addEventListener(touchstart, startHandler); document.addEventListener(touchmove, moveHandler, { passive: false }); document.addEventListener(touchend, endHandler);注意{ passive: false }是核心。React的合成事件默认是passive的浏览器会忽略preventDefault必须显式声明。这是我折腾最久的一个坑换了好几种写法才定位到。5.3 恶意脚本会如何针对手写版进行突破做安全对抗要“知彼知己”。这种手写滑动验证码最常见的突破方式有三种第一种是解析前端JS源码直接读取gapX变量得到坐标后模拟拖动到指定位置解决方式是前文说的后端不返回明文坐标第二种是录制真人滑动轨迹后重放解决方式是Token一次性使用、且轨迹和Token绑定第三种是直接用图像识别算缺口位置然后脚本精确移动这已经超出简单规则能防御的范围需要引入更复杂的行为模型。对绝大多数业务系统来说做到“不能仅靠改坐标参数就通过验证”就能挡住90%的脚本了。如果对手硬要拿着专业攻防工具去逆向你的前端那已经不是手写验证码的责任范围需要配合设备指纹、风控服务等更重的机制。5.4 我最终线上使用的参数建议距离容差3px这个值在普通屏幕和触屏上都比较稳妥。如果你面向的是老年用户群体可以酌情放到5px但注意会被更简单的脚本钻空子。Token过期时间120秒太短用户还没看清题目就失效太长又增加重放时间窗。120秒在各类业务场景都比较中庸移动端弱网环境下也够。轨迹采样频率视觉上每30毫秒一个采样点比较合适。可以让前端固定规格化轨迹比如检测到超过200个点时每隔一个采样抽一个凑在80到150之间的数据量。评分阈值我用的是60分通过但实际会发现正常用户的评分经常在70到90之间脚本在40以下。可以跑一段时间后统计自己业务的特征分布再把阈值调到75左右安全性和体验的平衡更好。6. 这套方案后续可以怎么扩展验证码不是静态产品持续对抗才是常态。这套手写代码给了完整的骨架后续我打算在以下方向迭代。第一个方向是把后端校验从规则升级成模型。现在只用了四个维度的统计特征后续可以采集足够多的正负样本训练一个分类模型让轨迹判定的准确率再上一个台阶。其实甚至不需要太复杂的模型一个梯度提升树或者随机森林把速度差分、Y轴方差、加速度峰值、停顿次数、加速度熵这些特征喂进去就能拿到不错的效果。第二个方向是加噪声干扰。目前拼图块的边缘就是简单的矩形固定大小后续可以把方块改成不规则多边形、加进毛刺缺口、加入干扰线或者在背景图上叠加视觉干扰物。这样做的目的是提高脚本图像识别缺口的门槛。第三个方向是前端风控数据采集。滑块轨迹只是人机行为的一路数据还可以结合点击位置偏差、键盘输入节奏、页面滚动模式等用一套前端SDK把这些信号统一上报给风控服务构建更立体的设备指纹和行为画像。第四个方向是兼容性和性能优化。跨端跨浏览器测试、低端机上的Canvas性能调优、灰度发布与阈值动态调整这些都是验证码系统要长期维护的工程要点。我在实际开发这套手写验证码的时候最大的感受是验证码的安全本质上是一个“成本博弈”。你不需要做出一套完全无法攻破的系统——这不现实——你只需要把攻击成本提高到显著超过攻击者预期收益就够了。手写方案的优势恰恰在于你的代码是私有定制的攻击者没法直接套用现成的绕过API或通用破解脚本每一个缺口形状、轨迹逻辑、校验策略都池化了对方的攻破时间。最后分享一个小技巧在开发阶段可以给验证码加上一个调试模式通过URL参数显式指定gapX/gapY、禁用Token有效期、打印完整的后端评分细节。这样联调时能清晰看到每一次失败的扣分点到底卡在距离、轨迹还是耗时上。我就是在调试这个评分模型时才发现原来人类用户拖动滑块的平均速度方差远比我想象的更大规则阈值一开始调到15才会误杀真人。这类细节不把调试日志完整打出来根本发现不了。希望这篇文章能帮你少走这些弯路。 
长河君 · 2026/10/24 4:54:24 · 阅读 1.2k 手写滑动验证码完整实现：前后端拼图拖动与轨迹校验解析
滑动验证码这东西大家都不陌生。但大多数人用的是第三方服务商现成的方案比如某云、某盾接入简单但费用和定制性都是问题。今天我把一套手写滑动验证码完整记录下来前后端代码全开放不依赖任何第三方SDK可以自己部署、自己定制、也能作为安全研究的学习素材。这套方案实现了拼图式滑块的核心机制随机生成缺口、前端拖动拼接、后端校验轨迹与位置。适合想搞懂验证码底层原理或者需要私有化部署验证能力的开发者读完可以直接把代码拿去改造。我最初做这个项目是因为公司内部的某个系统要上滑块验证但数据不出内网不能接外部服务。于是花了一周多时间从切图到轨迹校验完整走通了一条手写方案。过程中踩了不少坑——跨域图片画布污染、不同浏览器的鼠标事件差异、移动端触摸事件兼容、还有后端校验时要防止重放攻击。这篇文章把这些细节全展开配合可运行的完整代码尽量让拿到手的人能少走弯路。1. 整体设计拆解为什么选择拼图式滑块滑动验证码不是只有一种形态常见的就有两种一种是拼图式背景图上有一个缺口拖动滑块把拼图块对齐进去另一种是纯轨道式把滑块从左边拖到右边靠速度判断。我选择实现拼图式核心原因是它的安全强度和交互明确度都更好。先说说验证逻辑背后的思路。拼图式看起来考验的是“对齐”但机器如果知道缺口坐标想对齐根本不难几行代码就能精确移动到目标位置。所以真正的校验不再看“最终对不对”而是看“你过去它的过程像不像人类”。人手的滑动有加速、减速、轻微抖动和神经反应延迟这是机器模拟最刻意的地方。整套系统设计要做的就是前端捕获真实的运动轨迹后端综合距离、耗时、轨迹特征三项给出信任评分。这里有两个关键选型值得说清楚。第一为什么拼图缺口必须“随机”。如果缺口固定在某个位置机器人直接记住坐标就能过那验证码就和没有一样。我实现的方案是每次加载验证码时在允许边界内随机生成两个坐标准一个横向位置X一个纵向位置Y。X规定了拼图块最后的落点Y则决定拼图块在背景图中的高度。两个值都用服务端生成的核心随机数不入库、不重复、一次性有效。第二验证时序上不能用“前端告诉后端答案”这种简单模式。很多新手手写验证码的时候会在前端生成缺口位置再在前端提交时把位置一并POST给后端。这完全没意义——任何人用浏览器调试工具改一下坐标就绕过了。我这里的做法是缺口坐标由后端在初始化接口返回的同时加密进一个一次性Token里。前端提交校验的时候后端不信任前端传上来的坐标只从Token里解密还原真实坐标再和前端传来的拖动距离做比较。这样前端根本没有机会伪造答案因为答案不从前端来。在轨道的交互形态上我也做了取舍。市面上有些方案是按住滑块直接拖拼图这个最简单也有方案是点击按钮触发验证、出现拼图后再拖动。我采用后者初始状态下滑块条上有一个“点击开始”状态的按钮点击后才进入拖动模式。好处是能过滤掉一部分无意识的机械自动行为更重要的是给前端留出鼠标事件绑定的时机避免页面刚加载就拖导致事件丢失。2. 前端核心实现拼图生成、拖动交互与轨迹采集这一部分是整个方案里最直接让用户感知效果的地方也是代码密集区。我拆成三个环节来讲背景与缺口的生成、滑块交互处理、轨迹数据的采集与打包。2.1 背景图与拼图块的生成逻辑组件初始化时前端会请求后端接口拿到一张背景图片和对应的Token。为了演示方便我在纯前端Demo里用Canvas动态生成背景——随机渐变背景加一些随机图形模拟成一张“图”。生产环境中你完全可以把这段动态绘图替换成后端返回的真实图片或者随机从本地图库抽图。拼图块生成的核心是“切图”。我用Canvas的getImageData和putImageData把背景图上某一块区域的像素复制到拼图Canvas里再给拼图块的边缘画上浅浅的描边和阴影视觉上更立体也方便用户在背景缺口上进行比对。function createPuzzlePiece(bgCanvas, gapX, gapY, pieceSize) { const pieceCanvas document.createElement(canvas); pieceCanvas.width pieceSize; pieceCanvas.height pieceSize; const pieceCtx pieceCanvas.getContext(2d); const imageData bgCanvas.getContext(2d).getImageData(gapX, gapY, pieceSize, pieceSize); pieceCtx.putImageData(imageData, 0, 0); pieceCtx.strokeStyle rgba(255,255,255,0.7); pieceCtx.lineWidth 2; pieceCtx.strokeRect(0, 0, pieceSize, pieceSize); pieceCtx.shadowColor rgba(0,0,0,0.4); pieceCtx.shadowBlur 8; pieceCtx.strokeRect(1, 1, pieceSize - 2, pieceSize - 2); return pieceCanvas; }这里有个容易被忽视的细节getImageData处理的是像素级拷贝如果你从一张跨域的图片上截图Canvas会被浏览器标记为“被污染”后续调用toDataURL或getImageData时直接抛安全错误。这就是为什么生产环境的后端接口必须返回同源图片或者让图片资源和接口共用一套域名与CORS策略。我在Demo里用动态绘图天然避开了这个坑但换真实图片时你一定要注意。缺口阴影锚点画法也很重要。用户需要知道把拼图块拖到哪个位置算“到位”。做法是在背景Canvas上以 (gapX, gapY, pieceSize, pieceSize) 为矩形区域绘制一个半透明的白色/黑色矩形并让这个矩形轮廓外圈虚化。我测试下来白色背景上用黑灰色蒙层更不刺眼深色背景上则反过来。2.2 拖动滑块的事件处理细节拖动事件分三件套按下mousedown/touchstart、移动mousemove/touchmove、松开mouseup/touchend。我把状态机写成一个简单的三态常量IDLE表示未激活ACTIVE表示已按下滑块准备拖动DONE表示已完成一次拖动。需要处理的核心点有两个事件绑定时机和坐标系换算。事件绑定时机上初始只给滑块按钮绑定 mousedownmousemove 和 mouseup 不在全局绑定而是等 mousedown 触发后才动态挂到 document 上松手后立即解绑。这样做是为了避免页面在非拖动状态下也响应 mousemove造成不必要的性能开销同时也是为了屏蔽那些先自动模拟 mousemove 再模拟 mousedown 的作弊脚本。坐标系换算直接决定拖动精度。滑块放在整个轨道容器内部轨道左端到缺口中心点的距离和拼图块要移动的距离之间存在一个比例关系。不要把鼠标事件里的clientX直接用要用它相对轨道容器的偏移const rect trackWrap.getBoundingClientRect(); const offsetX e.clientX - rect.left; const maxDist trackWrap.offsetWidth - sliderBtn.offsetWidth; let moveX Math.min(maxDist, Math.max(0, offsetX - startOffset));其中startOffset是按下时鼠标在滑块内部相对滑块左边缘的偏移这样可以把基本都是按在滑块正中的操作归零。如果不减去startOffset滑块会突然“跳一下”观感很怪。这是从真实使用中发现的体验细节新手很容易漏掉。拼图块跟随滑块移动我用的是transform: translate3d(moveX, 0, 0)而不是改left。理由是transform只触发合成层更新不触发布局与重绘60帧拖动手感明显更顺滑尤其在高分屏下。拼图块的CSS样式里预先设置了绝对定位在背景图的左上角位置上translate3d的X值就对应横向位移Y保持不动。2.3 轨迹数据怎么记录才有效后端的“人机判定”完全依赖前端提交的轨迹数据所以我在这块做了严格封装。每次 mousemove 事件触发时记录一个采样点const sample { x: Math.round(moveX), y: Math.round(offsetY), t: Date.now() - startTime }; track.push(sample);完整轨迹由三个字段组成横向位移、纵向坐标因为人手并不能保证完全精准地沿直线拖动会有轻微上下浮动的、还有相对开始拖动的时间差。这三个字段合并起来就是后端判断的原料。采样频率也存在一个平衡点。事件监听每次mousemove都push生成的轨迹数组可能长达几百条。轨迹数据要打包进加密请求里太长了会拖慢请求速度太短了又没有分析价值。实测下来50到200个采样点是比较合理的区间。我这个Demo里自然触发大概会采集100个点左右如果要降采样可以直接对track做间隔抽取。在松手时我会把当前位移、轨迹数组、总耗时、以及页面的User-Agent打成一个对象连同Token一起发给后端。UA在后端校验时可以辅助判断是否出现了可疑的自动化设备指纹。3. 后端校验位置、Token、轨迹三重判定前端把数据POST上来之后后端不能只看“位置对不对”要依次做三道校验Token合法性校验、距离容差校验、轨迹行为特征校验所有校验都通过才算成功。我按实际后端代码的顺序展开。3.1 Token的设计与解密校验初始化时生成的Token我用了对称加密方案后端持有密钥把{gapX, gapY, expireAt, nonce}序列化成JSON字符串加密后返回给前端。前端提交校验时后端先解密、验签然后依次检查过期时间和一次性使用状态。一次性状态这步很关键。Token不能重复使用否则A用户拿到Token校验通过后B用户可以直接重放这个请求。我用了内存中的Redis计数器Token里存一个随机nonce校验完成后向Redis写入这个nonce下次再见到就直接拒绝。生产环境用Redis、本地开发用内存Map都可以。加密细节不多说用AES-GCM密钥只在服务端配置里前端完全没有接触的可能。这样哪怕前端JS被逆向攻击者也只能拿到密文解不出缺口坐标。3.2 距离校验的误差容差设定解密后后端得到真实缺口横坐标gapX。前端传上来的距离是clientX——也就是拼图块最终被拖拽的位移。两者在数值上还有一个映射关系并非相等。因为背景图和拼图块在Canvas坐标系里是1:1关系拼图块的位移就等于缺口坐标这个映射是线性的所以我可以直接比较。但真实拖动不可能每次都精准落在中心点上——人手本来就存在几像素的偏差。距离校验时我设置的容差是正负3像素。容差太小了人类用户会频繁误判太大了机器人就太好过。经过几百次真人和脚本双重复测3像素对正常手指影响很小对精确计算的脚本是显著性障碍。const distanceDiff Math.abs(gapX - clientX); if (distanceDiff 3) { return { pass: false, reason: position_mismatch }; }这段逻辑看起来平平无奇但真正想绕过的攻击者往往在第一步就会放弃——因为他们要让自己的题目“位置校验通过”必须把缺口坐标猜出来或者逆向Token拿到坐标这就把成本拉上去了。3.3 轨迹行为特征的判定思路这是整个手写验证码里最能拉开差距的地方。机器模拟的轨迹和人类轨迹在统计特征上差异明显我梳理出四个打分维度第一是总耗时。人类从按下到松手正常在0.8秒到2.8秒之间。太快0.4秒内说明是脚本直接瞬移太慢超过5秒可能是等待或思考都会扣分。第二是轨迹点数。纯脚本模拟的拖动可能是从起点到终点直接补的几个均匀点而人类拖动通常会产生数十个摆动点。点数过少直接判可疑。第三是加减速曲线。人类拖动滑块启动时会有一个加速过程临近目标点时又会减速、微调。最典型的特征是存在“顿挫”多处小的速度波动而不是匀速直线。我把相邻两采样点之间的位移差分转成速度序列计算速度序列中极值点的分布密度。第四是纵轴抖动幅度。人手沿水平方向拖动时不可能严格保证Y坐标不变总会有1到2像素级的上下浮动。机器模拟则通常保持在一条直线。计算所有轨迹点Y坐标的标准差如果远小于某个阈值很可能就是无机计算出来的。四个维度综合出一个打分。我设定了等级机制总分80分以上直接通过40分以下直接拒绝中间地带提示用户“再试一次”。这个机制不算精尖复杂但足以过滤掉大量初级攻击脚本和纯逻辑校验相比已经是质的提升。对于更高强度的对抗现在公认的方向是引入模型判定——把轨迹数据喂给一个预先训练的异常检测模型或者干脆在深度学习模型里学习人类滑动特征。但作为从零手写的方案统计规则足够覆盖多数应用的需求了。4. 完整代码实现可直接复现下面给出一个可以直接在本地跑通的完整版本。我的设计是不在HTML里写死缺口坐标而是前端初始化时在JS里随机生成同时在后端校验时通过Token解密来比对。为了让演示环境不需要额外装数据库和Redis后端Demo我用了纯内存状态。生产部署时把内存状态换成Redis即可。4.1 后端接口代码Python示例用Python写后端框架用Flask依赖只有flask、pycryptodome代码量可控。我实现了三个核心路由初始化验证码、校验验证码、以及图片生成的静态资源。先看初始化接口import os import json import random import base64 from datetime import datetime, timedelta from flask import Flask, jsonify, request, send_file from Crypto.Cipher import AES import io import time app Flask(__name__) SECRET_KEY byour-secret-key-16bytes def encrypt_token(data): nonce os.urandom(12) cipher AES.new(SECRET_KEY, AES.MODE_GCM, noncenonce) ciphertext, tag cipher.encrypt_and_digest(json.dumps(data).encode()) return base64.b64encode(nonce tag ciphertext).decode() def decrypt_token(token): raw base64.b64decode(token) nonce, tag, ciphertext raw[:12], raw[12:28], raw[28:] cipher AES.new(SECRET_KEY, AES.MODE_GCM, noncenonce) return json.loads(cipher.decrypt_and_verify(ciphertext, tag)) used_tokens set() # 动态背景图生成这里生成的是写有随机数字的图片实际生产可换成真实图片 app.route(/api/captcha/init) def init_captcha(): gap_x random.randint(60, 250) gap_y random.randint(40, 140) piece_size 50 expire_at time.time() 120 payload { gapX: gap_x, gapY: gap_y, pieceSize: piece_size, expireAt: expire_at, nonce: os.urandom(8).hex() } token encrypt_token(payload) # 这里把我的简化生成图形拼图逻辑合并成一份PNG二进制流返回给前端 # 具体后端生成图片的代码在后文给出 return jsonify({ token: token, gapX: gap_x, gapY: gap_y, pieceSize: piece_size })这里我要坦白说一个细节真实的滑动验证码中gapX不应该直接返回给前端。因为直接返回会让前端拿到缺口坐标机器人直接读JS变量就能获取。真实的架构应该是后端返回一张带缺口的背景图和一份加密Token前端从背景上识别缺口位置需要靠视觉比对而不是解析接口字段。Demo里为了先让核心逻辑跑通我先返回明文坐标。想用于生产的话可以删掉返回给前端的gapX/gapY明文字段前端改为对背景图做像素级缺口检测来定位拼图位置。校验接口是重点完整代码如下app.route(/api/captcha/verify, methods[POST]) def verify_captcha(): data request.get_json() token data.get(token) client_x data.get(clientX) track data.get(track) elapsed data.get(elapsed) if not token or client_x is None: return jsonify({pass: False, reason: missing_param}) try: payload decrypt_token(token) except Exception: return jsonify({pass: False, reason: invalid_token}) if payload[nonce] in used_tokens: return jsonify({pass: False, reason: reused_token}) used_tokens.add(payload[nonce]) if time.time() payload[expireAt]: return jsonify({pass: False, reason: token_expired}) gap_x payload[gapX] distance_diff abs(gap_x - client_x) if distance_diff 3: return jsonify({pass: False, reason: position_mismatch}) # 轨迹特征校验 score 100 if elapsed 400: score - 40 elif elapsed 5000: score - 30 if len(track) 10: score - 50 # 计算速度波动 speeds [] for i in range(1, len(track)): dt max(track[i][t] - track[i-1][t], 1) dx abs(track[i][x] - track[i-1][x]) speeds.append(dx / dt) if len(speeds) 2: mean_speed sum(speeds) / len(speeds) variance_speed sum((s - mean_speed) ** 2 for s in speeds) / len(speeds) if variance_speed 1: score - 30 # 计算Y轴抖动 y_values [p[y] for p in track] y_std (sum((y - sum(y_values)/len(y_values))**2 for y in y_values) / len(y_values)) ** 0.5 if y_std 0.5: score - 20 return jsonify({ pass: score 60, score: score, reason: ok if score 80 else need_retry })我用一个简单的评分函数替代了严格的多级规则并且把阈值设置在60分交互上更友好。实际部署时可以根据业务要面对的威胁强度调整阈值。为了确保完整可运行我再补充一段动态生成背景图的函数这里我生成一张带渐变色的矩形构成图作为可用背景import struct import zlib import math def generate_slide_bg(gap_x, gap_y, piece_size): width, height 350, 200 rows [] for y in range(height): row bytearray([0x00]) for x in range(width): # 简单渐变背景 r (x * 255 // width) g (y * 255 // height) % 200 30 b 160 # 缺口的阴影提示区域 if gap_x x gap_x piece_size and gap_y y gap_y piece_size: r 0 g 0 b 0 row bytes([r, g, b]) rows.append(bytes(row)) raw_data b.join(rows) encoder zlib.compressobj(9) data encoder.compress(raw_data) encoder.flush() def chunk(tag, data_bytes): return tag struct.pack(I, len(data_bytes)) data_bytes struct.pack(I, zlib.crc32(tag data_bytes) 0xffffffff) png b\x89PNG\r\n\x1a\n png chunk(bIHDR, struct.pack(IIBBBBB, width, height, 8, 2, 0, 0, 0)) png chunk(bIDAT, data) png chunk(bIEND, b) return png这部分比较基础主要是让没有本地素材的人也能直接生成可用的图片资源。这部分我用了纯Python生成PNG没有引Pillow部署时少一个依赖。4.2 前端完整页面单文件HTML为了省事前端我合并成一个单页HTMLCSS、JS、DOM都在一个文件里方便调试。生产环境拆成独立资源文件即可。!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title手写滑动验证码/title style * { box-sizing: border-box; margin: 0; padding: 0; } body { font-family: PingFang SC, Microsoft YaHei, sans-serif; background: #f5f6f8; display: flex; justify-content: center; align-items: center; height: 100vh; } .captcha-wrap { width: 380px; background: #fff; border-radius: 10px; box-shadow: 0 6px 24px rgba(0,0,0,0.08); padding: 24px; } .captcha-title { font-size: 16px; font-weight: 600; color: #333; margin-bottom: 16px; } .captcha-canvas-wrap { position: relative; width: 350px; height: 200px; margin-bottom: 16px; border-radius: 8px; overflow: hidden; background: #eee; } #bgCanvas { display: block; width: 350px; height: 200px; } #pieceCanvas { position: absolute; top: 0; left: 0; transform: translate3d(0, 0, 0); image-rendering: pixelated; } .slider-track { position: relative; width: 350px; height: 44px; background: #f0f0f0; border-radius: 22px; border: 1px solid #e0e0e0; } .slider-fill { position: absolute; left: 0; top: 0; height: 100%; background: #7bb7f7; border-radius: 22px; width: 0; } .slider-btn { position: absolute; left: 0; top: 0; width: 48px; height: 42px; background: #fff; border: 1px solid #d0d0d0; border-radius: 21px; text-align: center; line-height: 40px; cursor: pointer; font-size: 18px; color: #888; user-select: none; } .slider-btn.active { border-color: #4a9eff; color: #4a9eff; } .status-text { margin-top: 12px; font-size: 14px; color: #666; text-align: center; } /style /head body div classcaptcha-wrap div classcaptcha-title手写滑动验证码演示/div div classcaptcha-canvas-wrap canvas idbgCanvas width350 height200/canvas canvas idpieceCanvas width50 height50/canvas /div div classslider-track idsliderTrack div classslider-fill idsliderFill/div div classslider-btn idsliderBtn→/div /div div classstatus-text idstatusText点击滑块开始验证/div /div script const bgCanvas document.getElementById(bgCanvas); const bgCtx bgCanvas.getContext(2d); const pieceCanvas document.getElementById(pieceCanvas); const pieceCtx pieceCanvas.getContext(2d); const sliderBtn document.getElementById(sliderBtn); const sliderFill document.getElementById(sliderFill); const trackWrap document.getElementById(sliderTrack); const statusText document.getElementById(statusText); let gapX 0, gapY 0, pieceSize 50; let track []; let startTime 0; let dragging false; let startOffsetX 0; const PIECE_SIZE 50; function drawBackground() { bgCtx.fillStyle #2c8cff; bgCtx.fillRect(0, 0, 350, 200); // 随机画几个色块模拟真实图片 const colors [#ffad60, #60d394, #8395e6, #f76d6d, #ffd166]; for (let i 0; i 30; i) { bgCtx.fillStyle colors[Math.floor(Math.random() * colors.length)]; const x Math.random() * 350; const y Math.random() * 200; const w 20 Math.random() * 50; const h 20 Math.random() * 40; bgCtx.fillRect(x, y, w, h); } } function drawGapShadow() { bgCtx.save(); bgCtx.fillStyle rgba(255,255,255,0.6); bgCtx.shadowColor rgba(0,0,0,0.6); bgCtx.shadowBlur 12; bgCtx.beginPath(); bgCtx.rect(gapX, gapY, PIECE_SIZE, PIECE_SIZE); bgCtx.fill(); bgCtx.restore(); } function createPiece() { const imageData bgCtx.getImageData(gapX, gapY, PIECE_SIZE, PIECE_SIZE); pieceCtx.clearRect(0, 0, PIECE_SIZE, PIECE_SIZE); pieceCtx.putImageData(imageData, 0, 0); pieceCtx.strokeStyle rgba(255,255,255,0.8); pieceCtx.lineWidth 2; pieceCtx.strokeRect(0, 0, PIECE_SIZE, PIECE_SIZE); } function resetCaptcha() { gapX 40 Math.random() * 260; gapY 30 Math.random() * 110; track []; sliderBtn.style.left 0px; sliderFill.style.width 0px; pieceCanvas.style.transform translate3d(0, 0, 0); statusText.textContent 点击滑块开始验证; sliderBtn.classList.remove(active); drawBackground(); drawGapShadow(); createPiece(); } sliderBtn.addEventListener(mousedown, (e) { dragging true; startTime Date.now(); track []; const rect trackWrap.getBoundingClientRect(); startOffsetX e.clientX - sliderBtn.getBoundingClientRect().left; sliderBtn.classList.add(active); statusText.textContent 拖动滑块将拼图对准缺口; }); document.addEventListener(mousemove, (e) { if (!dragging) return; const rect trackWrap.getBoundingClientRect(); const maxDist trackWrap.offsetWidth - 48; let moveX Math.min(maxDist, Math.max(0, e.clientX - rect.left - startOffsetX)); sliderBtn.style.left moveX px; sliderFill.style.width moveX px; pieceCanvas.style.transform translate3d(${moveX}px, 0, 0); track.push({ x: Math.round(moveX), y: e.clientY - rect.top, t: Date.now() - startTime }); }); document.addEventListener(mouseup, () { if (!dragging) return; dragging false; sliderBtn.classList.remove(active); const clientX parseInt(sliderBtn.style.left, 10); const elapsed Date.now() - startTime; // 演示模式这里直接做本地比对 const diff Math.abs(gapX - clientX); if (diff 3) { statusText.textContent 验证通过; } else { statusText.textContent 位置有${Math.round(diff)}px偏差请重试; setTimeout(resetCaptcha, 600); } }); resetCaptcha(); /script /body /html这个版本是纯演示的最核心的逻辑都能跑通一看就懂。需要接入真实后端时把集成方案改成下面这样第一步页面加载时用fetch(/api/captcha/init)拿到gapX/gapY/token然后绘制背景和拼图。第二步在鼠标松开时把clientX、track、elapsed和token一起POST到/api/captcha/verify后端返回 pass 判定后前端根据结果显示成功或重试。如果你遇到的第一个版本里用了纯前端本地判断那么恭喜你已经拥有了完整理解拼图式验证码的能力。未来把校验逻辑迁移到后端只需要改一小段代码的请求发送部分整体结构完全不变。4.3 前后端联调时的接口协议定义前端和后端的协作必须靠协议约束。把联调中使用的字段列在下方方便直接当设计文档用字段名类型说明传输方向tokenstring初始化时返回的加密令牌后端生成前端提交gapXnumber缺口横坐标初始化返回生产慎用后端到前端gapYnumber缺口纵坐标后端到前端pieceSizenumber拼图边长后端到前端clientXnumber最终拖动距离前端到后端elapsednumber总耗时毫秒数前端到后端trackarray轨迹采样点列表包含 x/y/t前端到后端这个协议里需要重点强调的是生产环境下别把gapX直接给前端。正确做法是前端拿到背景后用类似“图像匹配”的方式自行估算缺口位置或者让后端把缺口绘制在背景上同时删去明文字段。哪种方案都有利弊但从工程角度讲减小信息泄露面永远是安全优先。5. 上线过程中我踩过的坑与最终推荐参数手写一版能跑的滑块不难但要做到生产可用坑都在细节里。这一章把我在真实环境中被折磨过的问题列出来。5.1 跨域图片导致Canvas被污染最一开始我图省事背景图直接用外链图片结果用户打开页面后识别缺口坐标时报错Unable to get image data from canvas because it has been tainted by cross-origin data。这是Canvas安全策略的直接反馈。解决方案有三个层次优先选择同源图片资源或者在后端代理转发图片避免跨域请求其次如果图片确实只能CDN部署要在服务端为CDN配置正确的CORS响应头Access-Control-Allow-Origin同时前端加载图片时给img标签加上crossOriginanonymous属性最后实在不行就用Canvas自己生成动态背景绕开跨域问题。5.2 移动端触摸事件与手势冲突桌面的鼠标事件在移动端完全失效所以必须兼容touchstart/touchmove/touchend。加了触摸事件后又遇到一个问题用户滑动滑块时页面会跟着上下滚动体验非常差。解决办法是在touchmove里调用e.preventDefault()并把滑块轨道容器CSS里加上touch-action: none。sliderBtn.addEventListener(touchstart, startHandler); document.addEventListener(touchmove, moveHandler, { passive: false }); document.addEventListener(touchend, endHandler);注意{ passive: false }是核心。React的合成事件默认是passive的浏览器会忽略preventDefault必须显式声明。这是我折腾最久的一个坑换了好几种写法才定位到。5.3 恶意脚本会如何针对手写版进行突破做安全对抗要“知彼知己”。这种手写滑动验证码最常见的突破方式有三种第一种是解析前端JS源码直接读取gapX变量得到坐标后模拟拖动到指定位置解决方式是前文说的后端不返回明文坐标第二种是录制真人滑动轨迹后重放解决方式是Token一次性使用、且轨迹和Token绑定第三种是直接用图像识别算缺口位置然后脚本精确移动这已经超出简单规则能防御的范围需要引入更复杂的行为模型。对绝大多数业务系统来说做到“不能仅靠改坐标参数就通过验证”就能挡住90%的脚本了。如果对手硬要拿着专业攻防工具去逆向你的前端那已经不是手写验证码的责任范围需要配合设备指纹、风控服务等更重的机制。5.4 我最终线上使用的参数建议距离容差3px这个值在普通屏幕和触屏上都比较稳妥。如果你面向的是老年用户群体可以酌情放到5px但注意会被更简单的脚本钻空子。Token过期时间120秒太短用户还没看清题目就失效太长又增加重放时间窗。120秒在各类业务场景都比较中庸移动端弱网环境下也够。轨迹采样频率视觉上每30毫秒一个采样点比较合适。可以让前端固定规格化轨迹比如检测到超过200个点时每隔一个采样抽一个凑在80到150之间的数据量。评分阈值我用的是60分通过但实际会发现正常用户的评分经常在70到90之间脚本在40以下。可以跑一段时间后统计自己业务的特征分布再把阈值调到75左右安全性和体验的平衡更好。6. 这套方案后续可以怎么扩展验证码不是静态产品持续对抗才是常态。这套手写代码给了完整的骨架后续我打算在以下方向迭代。第一个方向是把后端校验从规则升级成模型。现在只用了四个维度的统计特征后续可以采集足够多的正负样本训练一个分类模型让轨迹判定的准确率再上一个台阶。其实甚至不需要太复杂的模型一个梯度提升树或者随机森林把速度差分、Y轴方差、加速度峰值、停顿次数、加速度熵这些特征喂进去就能拿到不错的效果。第二个方向是加噪声干扰。目前拼图块的边缘就是简单的矩形固定大小后续可以把方块改成不规则多边形、加进毛刺缺口、加入干扰线或者在背景图上叠加视觉干扰物。这样做的目的是提高脚本图像识别缺口的门槛。第三个方向是前端风控数据采集。滑块轨迹只是人机行为的一路数据还可以结合点击位置偏差、键盘输入节奏、页面滚动模式等用一套前端SDK把这些信号统一上报给风控服务构建更立体的设备指纹和行为画像。第四个方向是兼容性和性能优化。跨端跨浏览器测试、低端机上的Canvas性能调优、灰度发布与阈值动态调整这些都是验证码系统要长期维护的工程要点。我在实际开发这套手写验证码的时候最大的感受是验证码的安全本质上是一个“成本博弈”。你不需要做出一套完全无法攻破的系统——这不现实——你只需要把攻击成本提高到显著超过攻击者预期收益就够了。手写方案的优势恰恰在于你的代码是私有定制的攻击者没法直接套用现成的绕过API或通用破解脚本每一个缺口形状、轨迹逻辑、校验策略都池化了对方的攻破时间。最后分享一个小技巧在开发阶段可以给验证码加上一个调试模式通过URL参数显式指定gapX/gapY、禁用Token有效期、打印完整的后端评分细节。这样联调时能清晰看到每一次失败的扣分点到底卡在距离、轨迹还是耗时上。我就是在调试这个评分模型时才发现原来人类用户拖动滑块的平均速度方差远比我想象的更大规则阈值一开始调到15才会误杀真人。这类细节不把调试日志完整打出来根本发现不了。希望这篇文章能帮你少走这些弯路。