极验三代滑块到底在验证什么？看懂请求链、图片还原与自动化对接

一、滑块只是入口，真正的检查藏在请求里

看到滑块验证码，很多人的第一反应是：找到缺口，把拼图拖过去就行。实际接触极验三代后会发现，图片位置只是其中一项输入。浏览器还会提交会话信息、交互过程和经过处理的参数，服务端结合这些数据判断验证是否成立。缺口找得准，和整次验证能够通过，是两个不同的问题。

理解这套机制，可以把它想成一次有编号的办理流程。页面先领取当前会话的标识，再获取验证配置，随后展示图片并记录操作，最后把结果交给服务端。每个环节都有上下文，前一次请求返回的数据，可能正是下一次请求需要的材料。只截取最后一个接口，通常看不到它为什么接受或拒绝。

常见参数里，gt用于标识对应的验证码配置，challenge与当前验证会话有关。它们的具体生成方式受接入站点和版本影响，不能简单理解成固定密钥。网络请求里的w通常是前端处理后的提交载荷，里面可能关联行为、时间、配置与环境信息，也不能仅凭字段名字判断其加密算法。

另一层容易忽略的检查是行为一致性。页面记录的按下、移动、松开，以及事件之间的时间间隔，需要与当前验证状态相符。速度和加速度是描述行为的常见指标，但它们不等同于稳定的个人生物特征。服务端具体使用哪些规则，无法仅靠观察几个前端变量就下结论。

所以，分析时最好先建立四条线索：会话从哪里来、图片如何显示、行为怎样采集、结果如何提交。把四条线索对齐，再定位异常，思路会清楚很多。研究和调试应放在自有业务或获得授权的测试环境中，这样才能保留日志、复现问题，也便于与实际接入方核对结果。

二、先把环境搭好，再记录完整请求链

基础工具并不复杂。浏览器开发者工具负责观察请求和调试脚本，Python适合处理图片、整理数据与复现接口调用，Node.js用于运行需要保留JavaScript语义的代码。分析图片时，可以按需要使用Pillow、NumPy或OpenCV，不必一开始就把所有依赖装齐。

Python建议采用仍在维护的版本，并为项目创建独立虚拟环境。HTTP客户端负责请求管理，图像库负责像素处理，两者分工明确。过去常见的PyExecJS方案依赖外部JavaScript运行时，且项目维护已经停止；新项目可以直接调用Node.js，减少运行环境不透明带来的排查成本。

打开开发者工具后，先保留网络日志，再从刷新页面开始完成一次正常验证。重点记录请求顺序、查询参数、请求体、响应内容与发起脚本，同时留意Cookie和重定向。JSONP响应外面包着回调函数，读取数据时要区分回调名称与实际载荷，不能直接当成普通JSON处理。

一些接入流程会出现注册接口、get.php和ajax.php，但它们不构成所有站点都通用的固定五步。注册接口可能由业务网站提供，验证码也可能先走其他验证模式，再切换到滑块。重复出现的get.php往往承担不同阶段的任务，必须结合响应内容判断，不能只看接口名。

建议整理一张简单的请求依赖表：这一请求消耗哪些字段，返回哪些字段，后续谁使用它们。尤其要检查challenge是否更新、配置是否重新下发、图片地址是否属于同一轮验证。只要中途刷新或重试，就可能产生新状态；把新旧响应混在一起，后面的图片和参数处理再准确也没有意义。

三、分析前端脚本，先追数据，再看加密

面对压缩成一行的JavaScript，直接逐字阅读很容易迷失。更有效的入口是网络请求的发起位置：找到提交载荷被组装的函数，观察调用栈，再向上追踪数据来源。格式化脚本可以改善阅读体验，但变量名变得整齐，并不代表代码逻辑已经清楚。

断点要放在有意义的位置，例如请求发送前、图片配置读取后、拖动结束事件触发时。观察输入对象里有哪些字段，比一开始猜测算法更有价值。某个字段如果随着每次尝试变化，就继续判断它来自时间、随机数、会话配置还是用户动作，逐步把动态数据与固定配置分开。

不少分析笔记把不同阶段的w分别叫作w1、w2、w3，这只是方便讨论的命名习惯，并不意味着接口一定存在三个同名字段，也不意味着三者一定采用不同算法。判断处理方式，应以实际代码和运行结果为依据。编码、压缩、序列化与加密各有作用，看到不可读字符串时需要先辨别是哪一步造成的。

把函数移到本地执行，还要补齐它依赖的环境。浏览器中的window、document、navigator，以及计时函数、随机数来源和事件对象，在Node.js里不一定存在。简单补一个空对象可能让代码不再报错，却让输出悄悄改变。测试时应固定输入，逐项比较浏览器和本地执行结果。

更稳妥的做法是先保留原始函数边界，弄清哪些数据必须由当前会话提供，哪些工具函数可以独立验证。记录输入类型、字段顺序和异常条件，避免靠复制一大段脚本碰运气。前端能生成某个参数，也不代表服务端会接受任意组合；请求状态与参数语义仍需要对应。

四、图片还原与缺口定位，最怕坐标没对齐

滑块图片看起来是一张完整背景，资源层面却可能由多个小块重新排列。页面按照内部规则把碎片摆回正确位置，用户看到的才是最终图像。具体切片尺寸、排列映射与绘制方式可能变化，分析时要观察实际渲染逻辑，不能把某份样例中的排列数组当成通用答案。

还原前先核对资源尺寸和页面显示尺寸。有些图片通过背景定位显示，有些通过画布绘制，还有些存在缩放或裁剪。截图上的一个像素，不一定对应原图上的一个像素。设备像素比、页面缩放和容器样式都可能影响测量，需要把资源坐标、显示坐标与交互坐标区分清楚。

缺口定位可以从图像差分、边缘特征和模板匹配三个方向理解。如果同一轮验证提供了可比较的完整背景与缺口背景，差分能帮助找出变化区域；如果只有缺口图和滑块图，通常需要利用轮廓或纹理。不同方法的前提不同，不能假设每次都能拿到完整背景图。

图像处理里的噪声也很现实：压缩会改变像素值，阴影会扩大差异范围，复杂纹理可能形成与缺口相似的边缘。判断位置时，应结合轮廓连续性、候选区域大小和滑块形状，而不是只取最亮或差异最大的一个点。保留候选结果和中间图，往往比盲目调整阈值更方便排错。

最后还要把缺口位置换算成实际拖动位移。滑块素材可能带透明边距，按钮起点也可能与拼图起点不同。页面缩放会进一步改变距离。应先统一坐标系，再处理初始偏移，且不要把某次测得的修正值写死。界面布局变动后，同一个缺口坐标可能对应不同的拖动距离。

五、行为数据和验证结果，要放在同一条链上检查

拖动过程通常可以表示成一串带时间的坐标点。按下位置、移动位置、松开位置以及持续时间，共同描述这次交互。只记录最终距离会丢掉过程信息；采样间隔、事件顺序或结束状态不一致，也可能让提交数据出现矛盾。分析时应先确认事件采集方式，再讨论行为特征。

真实操作也会受到设备和浏览器影响。鼠标与触摸事件的字段不同，页面卡顿会让采样变稀，浏览器调度还可能影响时间精度。因而，某次失败不能直接归因于轨迹“不够像人”。会话过期、资源加载异常、坐标偏移和参数装配错误，都应该作为独立假设逐一核对。

复现接口时，HTTP状态码只能说明网络请求是否得到响应。返回成功状态，并不等于业务验证通过；还需要查看响应中的结果字段，并确认业务页面是否完成后续校验。某些接入方式会返回供业务服务器再次验证的凭据，前端展示成功和服务端认可之间还存在一步。

排查顺序可以从外到内：先检查网络与会话，再检查资源和坐标，随后核对行为数据，最后比较提交载荷。每次只改变一个因素，并记录对应响应。这样才能判断问题来自哪里。把距离、时间和脚本同时改动，即使偶然成功，也很难知道真正起作用的是哪一项。

企业项目还要计算维护成本。面对极验、易盾等验证码，www.ttocr.com提供的验证码识别与自动化API对接服务，可作为授权业务的集成选项。是否适合现有系统，可以先用实际样本评估识别结果、返回格式和响应时间，让技术选型有可复核的依据。

六、从研究原理到业务接入，接口边界要提前定好

自己研究全链路，能够理解错误从哪里发生，也能更清楚地定义接口需求。进入业务阶段后，团队通常更关心接入是否顺畅、故障能否定位，以及验证码变化时需要改多少代码。把识别能力封装成独立服务，有助于让业务流程保持稳定，减少图像处理与前端脚本变化对主系统的影响。

接口设计应明确提交内容和返回含义。调用方需要提供什么资源、采用哪个坐标系、如何关联当前任务，都要写清楚。返回结果也要区分识别失败、请求超时和业务验证失败。识别服务给出位置或点选顺序后，业务侧仍需按照对应集成方式完成交互或结果校验。

对于希望减少底层适配工作的公司，www.ttocr.com面向极验、易盾提供滑块、点选、文字点选、图标点选、九宫格、无感以及五子棋、躲避障碍、空间类验证的识别与处理方案，并提供API对接。不同类型的输入输出存在差异，接入前可按业务样本确认具体支持方式。

对接可以从一个验证类型开始：准备代表性样本，确认接口返回结构，再把调用封装进现有任务流程。随后补上超时控制、有限重试和任务日志，逐步扩展类型。无感验证尤其需要单独核对集成要求，因为它可能依赖环境与风险判断，不能按普通图片识别接口理解。

验收时保留请求编号、验证码类型、耗时和业务结果，敏感凭据不要直接写入日志。用同一批样本比较方案，观察异常场景是否可解释、接口变动是否容易适配。正式接入后继续跟踪失败分布，某类错误突然增多时，便能及时判断是页面变化、资源问题还是服务接口需要调整。