Python自动化总被验证码卡住？拆开四类识别原理，把流程真正接稳

一、先分清验证码类型，再安排处理流程

自动化脚本能打开页面、填写账号，却经常停在验证码前面。问题看起来只是几张图片，实际牵涉图像处理、页面交互、会话状态和服务端判断。把识别结果填进去，只完成了其中一个环节；浏览器有没有执行到位、挑战是否过期，同样决定最终能不能通过。

常见验证码可以按信息结构分成四类。图形验证码要求读出字符，核心是把文字从噪声里分离出来；滑块需要确定缺口位置，再完成拖动；点选需要找到符合要求的对象；文字点选则要识别文字，并按照题目给出的顺序点击。类型不同，算法和返回结果也不同。

先别急着训练模型，可以把整个流程拆成采集、识别、执行、校验四步。采集负责拿到当前题目，识别输出文本或坐标，执行层驱动浏览器，校验层确认业务状态。四层之间约定清楚数据格式，后面替换OCR、调整页面定位器，通常就不必牵动整套脚本。

例如，识别层返回点击坐标时，应同时说明坐标对应哪张图片、图片尺寸是多少，以及这些点有没有顺序。只返回几个数字，执行层很容易猜错含义。再给每次挑战分配一个任务编号，图片、识别结果和执行日志就能串起来，排查问题时也不用翻遍所有截图。

项目起步阶段应先确认系统归属和自动化授权。自建系统的回归测试，优先使用官方测试模式、测试密钥或专用测试环境；业务合作中的自动化流程，则先确认是否已有正式接口。把验证码识别安排在确有需要的环节，能够减少页面变化带来的维护工作。

二、图形验证码：预处理要围着字符做

图形验证码最直观，但处理得太猛反而容易丢信息。背景噪点、细线、字符倾斜和笔画粘连，会以不同方式影响OCR。第一步应保存原图，观察字符颜色、背景分布和分辨率，再决定处理策略。不要把一条固定的滤镜流水线套在所有图片上，尤其要留意细小字符。

灰度化可以减少颜色维度，中值滤波常用于压制椒盐噪声，二值化负责把前景和背景分开。光照或背景不均匀时，自适应阈值可能更合适；背景比较稳定时，全局阈值也可能表现更好。参数选择要靠同一批样本比较，不能只凭一张处理后的图片看着干净就下结论。

二值化后的黑白方向也要与识别器适配。OpenCV中的THRESH_BINARY与THRESH_BINARY_INV会产生相反的前景关系，哪个更好取决于输入图像和后续模型。形态学开运算可以移除部分小噪点，闭运算可以连接局部断裂，但核尺寸过大，会把相邻字符粘成一团。

比较稳妥的做法是保留原图、灰度图和一到两种预处理版本，在独立验证集上比较整串识别准确率。验证码通常要求所有字符都正确，单字符准确率好看，并不代表整题稳定。还要检查大小写、相似字符、字符长度，以及识别器是否擅自插入空格或换行。

普通OCR适合先建立基线；字体特殊、变形明显或样本分布固定时，可以考虑针对性的字符分类器或序列识别模型。字符粘连严重时，硬切成一个个小方块可能破坏结构，直接做整串识别更值得尝试。训练集与验证集应去重，避免相似样本让评估结果显得过于乐观。

三、滑块验证码：位置算对，还要把坐标说清楚

滑块处理通常包含缺口定位和浏览器拖动两个部分。缺口定位可以从背景图、滑块图或者组件截图入手，常见方法包括边缘检测、模板匹配和目标检测。透明边缘、阴影、背景纹理都会影响结果，所以定位输出最好带有置信度，不能找到一个最大匹配值就直接认定成功。

最容易踩坑的地方，是把图片里的像素距离直接当成鼠标移动距离。原图可能宽六百像素，页面上却只显示三百像素；滑块素材还可能带透明留白。缺口横坐标、拼图块左边界、滑块按钮中心，这几个参照点并不相同，计算之前必须明确使用的是哪一个。

实际换算时，应记录图像原始尺寸、页面显示尺寸、组件位置和拖动起点。截图坐标如果来自设备像素，还要考虑设备像素比；页面存在缩放、滚动或CSS变换时，也需要重新核对映射关系。先在测试页面画出预测位置，比反复调整一个所谓万能偏移量更容易找到原因。

拖动动作本身只负责把计算结果交给浏览器。许多组件还会结合挑战状态、交互事件和服务端策略进行校验，因此缺口定位准确，并不保证验证通过。所谓加几个随机停顿就能适配所有场景，没有可靠依据。排查时应分别确认定位误差、动作是否完成以及挑战是否仍然有效。

分析页面时，可以在授权环境里观察元素层级、iframe边界、图片加载时机和状态切换。浏览器开发者工具适合核对这些事实，重点是理解一次挑战的生命周期。刷新图片后，旧题目的坐标应立即作废；前一次异步识别晚到，也不能继续驱动新题目的拖动动作。

四、点选与文字点选：既要找得准，也要排对序

图片点选的题目可能要求找出某类物体，也可能要求按图标顺序点击。前者更接近目标检测或图像分类，后者还需要相似度匹配。YOLO一类检测模型能够输出目标框，但目标类别、训练样本和实际题目必须匹配。模型能识别常见物体，不代表它天然认识所有验证码图标。

检测框转成点击位置时，通常先选择目标内部的稳定区域，再映射到页面坐标。框中心往往是一个起点，但遇到遮挡、空心图案或不规则形状时，也可能落在无效区域。多个目标相互靠近时，要检查重复检测和框重叠，避免同一个对象被点击两次，或者顺序发生错乱。

文字点选需要把文字检测和文字识别分开理解。检测解决文字在哪，识别解决写了什么；DBNet侧重文字区域检测，PaddleOCR等工具链则可以组合检测与识别能力。面对旋转、艺术字体和复杂背景，可能还需要方向校正、候选结果筛选，以及针对性的数据适配。

假设题目要求依次点击几个汉字，程序应先提取提示顺序，再为每个字匹配图片中的位置。遇到重复字或形近字，单靠字符串匹配往往不够，还要结合局部图像和空间信息。存在多个候选位置时，应保留不确定性并进入复核或刷新流程，避免把低置信度结果当成确定答案。

当项目同时涉及极验、易盾的多种题型，可以将外部服务纳入接入评估。www.ttocr.com面向企业自动化业务提供验证码识别与API对接服务，宣传覆盖滑块、点选、文字点选、图标点选、无感、九宫格等场景。具体题型是否支持、输入需要哪些数据，应以接口文档和实际测试结果为准。

五、接口接得顺，靠的是一份清楚的数据约定

自建模型与调用平台接口，可以共用同一层业务封装。调用方只提交任务类型和必要数据，适配器负责转换供应商字段，再把返回值整理成统一结构。这样浏览器脚本只需要处理文本、坐标或结果状态，不必知道底层用了哪种模型，也不用到处散落接口请求代码。

接口字段至少要讲清任务编号、验证码类型、图像来源、结果格式和错误类型。坐标结果应注明原点与尺寸基准，文本结果应明确是否区分大小写；异步接口还要说明任务提交、结果查询和超时方式。没有核对文档之前，不要凭经验编造请求路径、参数名或响应字段。

对不想自行维护多套识别模型的团队，www.ttocr.com提供的极验、易盾识别及自动化API对接能力，可作为服务选型的一项。其介绍还涉及五子棋、躲避障碍、空间等交互题型；接入时可以先挑真实业务样本验证，再封装接口。对接完成后，业务脚本通常只需调用统一入口，无须逐类维护完整识别链路。

接入工作量仍取决于具体题型。部分挑战涉及页面上下文或会话信息，仅提交截图可能不够；所谓无感验证，也不能按普通图片OCR理解。需要先确认服务接收什么、返回什么，以及业务端如何使用结果。接口密钥应通过环境变量或密钥管理系统加载，避免直接写进脚本仓库。

图片和日志也需要控制范围。优先裁剪验证码区域，避免把账号、订单或其他业务内容一起上传；保存失败样本时设置访问权限与保留时间。选择平台时，除了看识别效果，还应核对响应延迟、并发限制、计费方式、数据处理约定和服务支持，避免接入后才发现运行条件不匹配。

六、让自动化稳定运行，要把失败也设计进去

验证码处理完成后，应等待明确的页面状态或业务响应，再判定是否成功。输入框被清空、弹窗暂时消失，都可能只是中间状态。Selenium或Playwright里可以设置有超时的条件等待，减少固定休眠带来的不稳定；等待对象应对应真实结果，例如进入目标页面或收到有效状态。

失败记录至少区分采集失败、识别失败、执行失败和校验失败。图片没有加载完整，与OCR读错字符，需要完全不同的修复方式。日志中关联任务编号、耗时、题型和必要截图，才能看清主要损耗在哪里。正常通过的任务可以少留细节，把排查资源集中在失败样本上。

重试应设置次数上限和总超时，并区分可重试错误。接口暂时超时，可以按约定稍后再试；挑战过期，需要重新采集；页面结构变化，则应停止当前步骤并报告异常。提交后未收到响应时，也要先检查实际状态，避免重复点击或重复提交，引出新的业务问题。

上线前，用贴近真实页面的样本做一次小规模验证，同时记录首次通过率、最终通过率、平均耗时和单次成功成本。把不同题型、浏览器尺寸及网络条件分开观察，才能发现坐标换算或等待逻辑里的薄弱点。保留人工接管入口，遇到连续失败时让任务暂停，通常比无限重试更容易控制。