爬虫必看：图形验证码与滑块验证码识别原理与实战

写爬虫的人，早晚都会撞上验证码这东西。我最早遇到它的时候，正爬一个站点爬得顺风顺水，突然返回一张歪歪扭扭的字母图片，程序当场就断了。当时的第一反应是“绕过去”，换代理、降频率、抢接口，折腾一圈发现大多数办法都治标不治本。真正有用的是把验证码信息识别这件事拆开来看：验证码本质上就是一个自动化的信息识别问题，程序要做的，是从一段有干扰的图像或者交互行为里，提取出服务端期望的“答案”。这篇文章把我做验证码信息识别的思路和踩坑经验整理出来，重点放在图形验证码和滑块验证码这两类最常见的形态，适合刚接触爬虫、被验证码卡住、不知道从哪里下手的开发者参考。

1. 验证码凭什么能拦住爬虫：先搞懂它在拦什么

1.1 验证码拦的不是人，是“自动化的成本”

验证码在技术上是个很精妙的设计：它是一个反向图灵测试，目标就是区分人和程序。人类看一张图片可以瞬间读出字符，但让程序把图像里的信息变成结构化文本，就需要经历图像预处理、字符分割、模式识别这一整套流程。设计者再故意引入扭曲、旋转、干扰线、噪点、背景纹理，目的就是无限拉高程序提取信息的成本。

这里有一个容易被忽略的核心认知：验证码的设计目标从来不是“完全不可识别”，而是“让识别的成本高到不值得”。当一个验证码的识别时间以秒为单位、识别率只有七八成，并且还需要大量标注样本时，自动化的边际收益就被压缩了。所以验证码不是一道数学题，它是一道经济账。弄明白这一点，后续的方案选型就会清晰很多——你不需要追求99%的识别率，你需要的是在可接受的成本内，拿到足够用的识别率。

另一个层面很多人没意识到：验证码其实分两层，一层是视觉识别层，也就是图形验证码、滑块验证码、点选验证码这类需要你“看懂图”的；另一层是行为风控层，比如无感验证码，它压根不让你识别任何图像，而是通过设备指纹、浏览器环境、鼠标轨迹、历史行为来判断你是不是真人。视觉层可以用图像算法去打，行为层就要靠工程手段去伪装和绕行。这篇文章讲的两种验证码恰好横跨了这两层，所以后续会同时涉及图像算法和请求侧工程。

1.2 常见验证码形态与识别难度对比

我按实际项目里遇到的概率，把验证码形态和对应的破解难度先摸了个底，如表所示：

从这张表能看出，多数爬虫场景里图形码和滑块码占到了八成以上。图形验证码是基础中的基础，滑块验证码则是分水岭——跨过滑块之后，你对“模拟真人操作”这件事的理解会上一个台阶。所以这篇文章的主线就把精力放在这两种上。

2. 图形验证码：从像素到字符串的完整提词流水线

2.1 预处理四板斧：灰度、二值、降噪、裁边

图形验证码识别的第一道工序不是识别，而是“清理”。验证码图片给到程序时是一堆RGB像素，里面真正有用的只是字符轮廓。第一步做灰度化，把三通道的颜色信息压缩成单通道亮度。颜色信息对字符识别几乎没有贡献，但是灰度化之后计算量直接降到三分之一，后续所有图像运算都会快不少。

第二步是二值化。灰度图像每个像素的取值是0到255，二值化就是选一个阈值，把像素分成黑白两类。关键问题是阈值怎么选。我试过固定阈值，比如直接取127，效果很飘——不同站点验证码的背景深浅不一样，同一个阈值在这个站好使，换个站就全黑或者全白了。后来改用Otsu算法自动求阈值，它会根据图像的灰度分布自动选一个让类间方差最大的分割点，实测下来对绝大多数验证码都够用，尤其适合字符和背景对比度尚可的图。如果对比度很差，就得先做一步增强，比如先高斯模糊再求差，但这种情况相对少见。

第三步是降噪。很多验证码会在背景里撒细线干扰，这些干扰在二值图上表现为挨得很近的散点。我常用形态学开运算，也就是先腐蚀后膨胀，把孤立噪点消掉。这里有个参数要小心：腐蚀会把字符边缘一起变细，如果开运算的核选大了，字符笔画细的直接被消没了。一般从2x2的核开始试，字符笔画粗的可以适当加大。

最后一步是裁边。验证码图片四周经常会有一圈无用边框，边框的灰度变化在分割阶段会干扰连通域分析。直接用像素赋值把边缘几行几列涂黑即可，不需要真的裁剪尺寸，这样能保留原图的坐标体系，后面定位字符位置时不至于错位。

2.2 字符分割：投影法和连通域怎么选

预处理完成后，图片已经变成一张比较干净的黑白图，接下来要把每个字符单独切出来。最常用的两种手段是投影法和连通域法。

投影法的思路很直白：对二值图按列统计前景像素数量，统计结果会形成一个“柱状图”，字符区域柱子高，字符间隙柱子低。我按这个波谷位置把图片切开，就能得到每个字符的左右边界。同理对行做一次投影，能切出上下边界。这种方法的优点是不需要任何训练，速度极快；缺点是一旦字符发生粘连，两个字符之间根本没有空白列，投影法就失效了。

连通域法则用像素的“连成一片”特性来分割。OpenCV的connectedComponentsWithStats函数会把图像中所有独立的连通区域找出来，每个区域自带外接矩形框。在字符不重叠、不粘连的情况下，连通域法比投影法更稳定，因为它不依赖字符间是否存在空白列，只要笔画是断开的，它就能正确区分。实际项目里我一般先做连通域分析，看输出框的数量和字符总数对不对；如果输出框过多，说明噪声没清干净，回去调整降噪参数；如果输出框过少，说明字符有粘连，这时再考虑用投影法或者其他断开手段。分割之后建议把每个字符统一缩放到固定尺寸，比如28x28或32x32，方便后续识别阶段用同一套特征。

2.3 识别引擎怎么选：OCR、模板匹配还是上模型

字符被切出来之后，剩下的问题是“这个图像是哪个字符”。我试过三条路线，按性价比排序是这样的。

第一是通用OCR引擎。这类工具的好处是零训练成本，拿来就能用，尤其适合字体端正、无干扰的纯数字验证码。但遇到扭曲严重、加了干扰线的验证码时，识别率会掉得很难看，基本不太能用。我现在的建议是：只把OCR当第一拍试试，能用就用，不能用别死磕。

第二是模板匹配。如果验证码的字体固定，字符集又有限——比如只有0到9的数字——那么每个字符准备一张标准模板图，把切出来的字符逐张和模板做相似度对比，取分数最高的那个作为识别结果。这个方案识别速度极快，CPU上毫秒级出结果，而且不用训练。缺点是模板库要覆盖字符的字体、粗细、颜色差异，每个变体都得存一张。优点是维护成本低，加两个模板就能覆盖一种新样式。

第三是训练一个小型分类网络。当字符扭曲严重、字体多变、干扰强时，前两种方案都容易识别错，这时候CNN就体现出优势了。我实际用过一个小型卷积网络，四个卷积层加两个全连接层，字符类别几十个，训练样本几百张，识别率就能到95%以上，比OCR和模板匹配都稳。但代价是必须准备标注数据、训练环境和推理代码，工程链路比较重。

所以我的选型建议是阶梯式的：先OCR试水，不行上模板匹配，还不行再考虑分类模型。不要一上来就训练模型，验证码识别最大的坑就是把简单问题复杂化。很多时候你花了两天调模型，不如花两小时多标两个模板，后者识别率可能还更高。

2.4 一套够用的OpenCV预处理代码

下面这段是我在实际项目里经常用的预处理函数，输入验证码图片路径，输出一张清理干净的单通道二值图：

import cv2 import numpy as np def clean_captcha(img_path, kernel_size=2): img = cv2.imread(img_path) gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # Otsu自动阈值二值化，前景变白色 _, binary = cv2.threshold(gray, 0, 255, cv2.THRESH_BINARY_INV | cv2.THRESH_OTSU) # 开运算去噪点 kernel = np.ones((kernel_size, kernel_size), np.uint8) cleaned = cv2.morphologyEx(binary, cv2.MORPH_OPEN, kernel) # 裁掉四周边框 h, w = cleaned.shape cleaned[:2, :] = 0 cleaned[h-2:, :] = 0 cleaned[:, :2] = 0 cleaned[:, w-2:] = 0 return cleaned

这段代码跑通之后，再配合模板匹配，我在某个模拟项目的图形验证码上把识别率从50%提到了80%以上。一个比较实用的调试技巧是：把中间过程图全部存下来，逐张查看是哪一步出了问题。灰度图、二值图、开运算后、裁边后的图各存一张，肉眼比对很快就能定位问题出在降噪还是分割阶段。不要直接在最终识别结果上猜，那样效率太低。

3. 滑块验证码：缺口定位和人类轨迹模拟缺一不可

3.1 滑块验证码的校验逻辑比你想的更复杂

图形验证码解决的是“图像里是什么”，滑块验证码解决的则是“你是不是一个真实的人”。很多人以为滑块验证码的核心是找到缺口拖过去，其实只对了一半。

滑块验证码的完整校验维度是这样的：服务端拿到手的不只是一个“最后的横坐标”，还包括整个拖动过程中的坐标序列、每个点的时间戳、鼠标移动的加速度曲线、是否有键盘事件穿插、甚至浏览器的画布指纹。它可以看作“图像识别+行为识别”二合一。如果你只找到缺口位置，然后程序直线匀速地把滑块拖过去，轨迹数据一出来就暴露了——真人拖动不可能是一条速度恒定的直线，人的手部运动受肌肉控制，启动阶段会有轻微抖动，中间可能减速停顿，快到终点的时候会小心微调。这些微观特征服务器端都记录在案。

所以滑块验证码的正确打开方式是双线程：图像线程负责精确找到缺口位置，行为线程负责生成一段尽可能像人拖出来的轨迹。缺一不可。位置对了但轨迹生硬，照样过不了校验。

3.2 缺口定位：模板匹配为主，边缘检测兜底

缺口定位的第一种方法是用滑块小图标去背景大图上做模板匹配。多数滑块验证码会返回两张图：一张带缺口的大背景图，一张滑块小图标，滑块图标恰好就是缺口处被抠掉的那一块。用OpenCV的matchTemplate拿滑块小图去背景图上滑动打分，得分最高的位置就是缺口中心。这段代码非常短：

import cv2 def find_gap(bg_path, slider_path): bg = cv2.imread(bg_path, 0) slider = cv2.imread(slider_path, 0) res = cv2.matchTemplate(bg, slider, cv2.TM_CCOEFF_NORMED) _, max_val, _, max_loc = cv2.minMaxLoc(res) return max_loc[0] # 返回缺口左上角的x坐标

这个方法又快又稳，但有一个前提必须注意：背景图和滑块小图的尺寸比例一致。现在很多平台为了适配高分屏，会给2倍图或者3倍图，如果其中一个缩放比例不同，匹配结果直接是乱的。我踩过这个坑，最后统一把两张图缩放到同一个宽度再匹配，分数才恢复正常。

第二种方法是拿不到滑块小图时的兜底方案：对背景图做Canny边缘检测，再用轮廓分析找出缺口位置。缺口的边缘特征比较独特，通常是一段密集的、非水平方向的边缘簇，通过对轮廓外接矩形的宽高比例做过滤，可以锁定缺口区域。这个方案对截图质量特别敏感，光照、阴影都会影响边缘提取效果，所以我只在模板匹配失效时用它。

3.3 轨迹不是“把滑块拖过去”这么简单

缺口定位只是第一步，后面还有轨迹模拟这个大头。我见过不少朋友在滑块验证码上的做法是：定位缺口后，用selenium的action_chains直接拖过去，速度设置成固定值，结果一次都没过。原因前面已经说过，服务端在观察你“怎么拖”。

一个人类拖鼠标的过程大致是这样：从滑块起点出发，起初有一个缓慢的加速过程，手速逐渐起来；中间阶段比较稳定，可能会有小幅的匀速甚至减速；接近缺口时速度会明显下降，因为要精确对准；最后可能有左右微调，然后松手。这个过程对应到轨迹序列上，就是每个时间点的位移增量不相等，而是先增大再减小。轨迹点之间的时间间隔也应该有轻微抖动，完全等间隔本身就是一种机器特征。

更讲究一点的做法是把y轴也考虑进去。真人拖动滑块时鼠标不会完全保持在同一高度，而是一条带着轻微上下抖动的曲线。我早期写的轨迹生成函数只模拟了x轴，y轴恒为某个固定值，结果被风控判定为非人类操作。加上y轴随机抖动之后，通过率才恢复正常。

3.4 一个基础的轨迹生成实现

下面是一段生成人类风格轨迹的Python示例，思路是分段变速加随机扰动：

import random def generate_trace(distance, steps=60): trace = [] current = 0 v = 0 for i in range(steps): progress = i / steps # 前40%加速，中间30%保持速度，后30%减速 if progress < 0.4: v += random.uniform(0.3, 0.8) elif progress < 0.7: v = max(v, random.uniform(1.5, 2.5)) else: v = max(v - random.uniform(0.2, 0.5), 0.2) current += v if current >= distance: current = distance trace.append(round(current, 2)) # 确保最后一个点精确落在目标距离 if trace[-1] != distance: trace.append(distance) # 给y轴加一点随机抖动 y_trace = [round(random.uniform(-2, 2) + base, 1) for base in [random.uniform(-3, 3)] * len(trace)] return list(zip(trace, y_trace))

这段代码生成的轨迹是位移序列，满足“先加速、再匀速、后减速”的特征，末尾有微调，y轴也带抖动。要注意的是，不同的滑块验证码对采样频率要求不同，有的服务端每10毫秒记录一个点，有的每20毫秒记录一个，生成的轨迹点数需要按真实拖动时间换算，而不是固定给60个点。拿到目标站点的真实采样率再调节奏，成功率会明显提高。

4. 识别以外的路：会话维护、请求伪装和打码平台

4.1 会话状态维护是第一优先级的“无验证码”方案

做验证码识别的终极目标是不用识别验证码。这个话听起来像废话，但确实是最重要的工程经验。很多站点的验证码并非每次请求都会触发，而是有一个风险计数器：短时间请求次数过多、请求头异常、会话异常的时候，验证码才会弹出来。换句话说，验证码是“行为惩罚”而不是“默认关卡”。

我改掉“每次请求都重新建连接”的坏习惯、改用会话保持之后，验证码出现的频率肉眼可见地下降了一半以上。实现方式很简单，用requests.Session保持连接池和Cookie，登录成功后把Cookie存下来，后续请求都走同一个会话对象。登录态在，请求行为正常，很多验证码触发器根本就不会启动。这套方案零成本，效果还最稳定，应该作为所有爬虫项目的第一道防线。

4.2 请求头与浏览器指纹：伪装得像一个真人

会话保持之外，请求头伪装也很关键。最基础的是保证User-Agent、Accept、Accept-Language、Referer这些字段和真实浏览器一致。但这里有个容易被忽略的细节：请求头的顺序、某些自定义字段的有无，都可能被服务端用来判断请求真假。我见过有些站点会校验Sec-Fetch-Site、Sec-Fetch-Mode这类浏览器自动添加的安全元数据，少一个字段就触发风控，进而弹验证码。

更高阶的指纹伪装涉及浏览器渲染环境检测，包括Canvas指纹、WebGL参数、字体列表、屏幕分辨率等等。如果你的程序连浏览器环境都没有，那服务端很可能直接判定为异常请求。在实际项目中，无头浏览器加反检测参数是常见做法，能极大降低触发验证码的概率。

4.3 打码平台：什么时候值得花钱买稳定

自己写识别方案的收益是有上限的。当你面对上千种验证码变体、识别率卡在80%上不去，或者验证码量一天几万次时，自己做就不划算了。这时候接入打码平台反而是最优解。平台的通用做法是接收验证码图片，返回识别文本，延迟一般在1到3秒，接口逻辑非常简单。

我个人的建议是做一个本地识别为主、平台兜底的混合策略。本地识别成功率高的直接过，识别置信度低的再发给平台，这样既控制了成本，又保证了整体通过率。需要提醒的是，平台识别延迟有抖动，如果不做并发控制和超时重试，高峰期会拖慢整个采集流程。另外，不要把图片直接刷给平台看能不能识别，先确认目标站点允许这种做法、实际授权范围内使用再接，这个不用我多说。

4.4 限速与重试：把验证码的触发概率降下来

最后还有一个经常被忽略但非常有效的工程手段：控制请求节奏。我在代码里加一个简单的随机等待，每次请求间隔在2到5秒之间随机，请求量不变的情况下验证码出现次数降了很多。原理还是那个：验证码是风控系统的响应，请求行为越像人，触发概率越低。重试策略也要设计：识别失败之后不要立即重试，先休眠几秒再试；连续失败三次就彻底退避，等更长时间再继续。这套“请求节流”配合“会话保持”，比任何识别算法都能帮你省事。

5. 我踩过的几个验证码识别大坑

5.1 预处理参数不能一套打天下

我最早图省事，把所有站点的验证码都丢给同一套预处理参数。结果同一个函数在A站识别率90%，到B站直接掉到50%。原因也很简单：不同站点的验证码生成器字体、干扰方式、背景纹理完全不一样，Otsu阈值和开运算核大小的最优值自然也不同。正确做法是把预处理配置做成“每个站点一份参数”，先用一批样本自动跑一遍调参，把参数固化到配置里，再接入实时识别流程。多花半天做这个配置化，后面会省下大量调试时间。

5.2 滑块识别对图片质量极其敏感

滑块验证码的图片识别环节特别容易受到截图方式影响。我遇到过背景图带半透明阴影，缺口边缘发虚，模板匹配分数怎么都上不去；也遇到过滑块小图标带透明通道，直接OpenCV读出来边缘是黑的，匹配结果一塌糊涂。解决办法很粗暴但有效：把透明通道删掉，或者把小图标粘贴到一张白色背景上再匹配。还有一个通用技巧是匹配前把两张图都转成灰度图并做直方图均衡化，能显著提升不稳定情况下的匹配成功率。

5.3 服务端校验的维度比你想的多

有一段时间我的滑块验证码明明缺口位置对了，轨迹也非常平滑，成功率依然很低。后来仔细排查才发现问题出在y坐标：我生成的轨迹在y轴上几乎没有变化，全程一条直线。真实的人手拖动鼠标，哪怕只拖滑块，y轴也会有几像素的随机抖动，这是肌肉细微颤动的结果。从这个教训延伸出来的经验是：不要只盯着x轴，时间戳间隔、y轴抖动、起始位置的微小偏移，这些“不完美”才是真人特征。风控系统识别的恰恰是完美的机器特征。

5.4 别低估标注数据对识别率的影响

最后想说一下分类模型方案的数据问题。如果验证码复杂到必须用CNN，你最大的瓶颈往往不是模型结构，而是标注数据。字符类别可能只有几十个，但每个类别的字体、扭曲、干扰变化非常丰富，如果只标注几十张就开训练，模型泛化能力会很差，换个字体就识别错。我后来把样本量提升到每个类别200张以上，并做了平移、旋转、缩放、加噪声的数据增强，模型的识别率才稳定到95%以上。训练一个小网络不难，难的是把数据质量做扎实。