写爬虫的人早晚都会撞上验证码这东西。我最早遇到它的时候正爬一个站点爬得顺风顺水突然返回一张歪歪扭扭的字母图片程序当场就断了。当时的第一反应是“绕过去”换代理、降频率、抢接口折腾一圈发现大多数办法都治标不治本。真正有用的是把验证码信息识别这件事拆开来看验证码本质上就是一个自动化的信息识别问题程序要做的是从一段有干扰的图像或者交互行为里提取出服务端期望的“答案”。这篇文章把我做验证码信息识别的思路和踩坑经验整理出来重点放在图形验证码和滑块验证码这两类最常见的形态适合刚接触爬虫、被验证码卡住、不知道从哪里下手的开发者参考。1. 验证码凭什么能拦住爬虫先搞懂它在拦什么1.1 验证码拦的不是人是“自动化的成本”验证码在技术上是个很精妙的设计它是一个反向图灵测试目标就是区分人和程序。人类看一张图片可以瞬间读出字符但让程序把图像里的信息变成结构化文本就需要经历图像预处理、字符分割、模式识别这一整套流程。设计者再故意引入扭曲、旋转、干扰线、噪点、背景纹理目的就是无限拉高程序提取信息的成本。这里有一个容易被忽略的核心认知验证码的设计目标从来不是“完全不可识别”而是“让识别的成本高到不值得”。当一个验证码的识别时间以秒为单位、识别率只有七八成并且还需要大量标注样本时自动化的边际收益就被压缩了。所以验证码不是一道数学题它是一道经济账。弄明白这一点后续的方案选型就会清晰很多——你不需要追求99%的识别率你需要的是在可接受的成本内拿到足够用的识别率。另一个层面很多人没意识到验证码其实分两层一层是视觉识别层也就是图形验证码、滑块验证码、点选验证码这类需要你“看懂图”的另一层是行为风控层比如无感验证码它压根不让你识别任何图像而是通过设备指纹、浏览器环境、鼠标轨迹、历史行为来判断你是不是真人。视觉层可以用图像算法去打行为层就要靠工程手段去伪装和绕行。这篇文章讲的两种验证码恰好横跨了这两层所以后续会同时涉及图像算法和请求侧工程。1.2 常见验证码形态与识别难度对比我按实际项目里遇到的概率把验证码形态和对应的破解难度先摸了个底如表所示验证码类型识别原理破解难度典型工程成本常见场景纯数字/字母图形码对扭曲字符做OCR或模板匹配入门级低预处理之后即可识别普通站点登录、注册带干扰的图形码字符分割 分类识别中等需要调预处理参数可能要用分类模型电商、社区类站点滑块验证码缺口定位 拖动轨迹模拟中高图像算法和轨迹算法都要写好交易、支付前后风控点选文字验证码目标检测 语义理解高需要上目标检测模型风控严格的业务无感验证码不做图像识别检测环境与行为高重点是浏览器环境和指纹伪装大型互联网平台从这张表能看出多数爬虫场景里图形码和滑块码占到了八成以上。图形验证码是基础中的基础滑块验证码则是分水岭——跨过滑块之后你对“模拟真人操作”这件事的理解会上一个台阶。所以这篇文章的主线就把精力放在这两种上。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_size2): 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, steps60): 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%以上。训练一个小网络不难难的是把数据质量做扎实。