做电商后台自动化的朋友多少都被滑块拼图验证码拦过路。尤其是京东这类大平台登录、下单、批量操作时滑块验证码出现的频率不低。我最初也想过用现成的打码平台但接第三方服务一是要花钱二是数据要过别人服务器心里总不踏实三是响应速度不稳定跑批量任务时经常卡在等待上。后来决定自己用 RPA 思路做一套从图像识别到模拟拖拽全走本地效果反而比预期好很多。这篇文章就从我的实战角度把 RPA 处理京东滑块拼图验证码的完整思路拆开讲清楚包括缺口识别、轨迹模拟、踩坑记录。适合刚接触 RPA 自动化、想自己搞定滑块验证的朋友也适合已经在做电商自动化但总被验证码卡住的老手。1. 项目概述与需求拆解1.1 核心需求解析先说清楚这是个什么事。滑块拼图验证码本质上就是平台用来区分“真人操作”和“机器操作”的一道关卡。界面上一张背景图上面有一块拼图缺口下面一个滑块你需要把滑块拖到一个正确位置让拼图块和缺口对齐系统才会放你通过。RPA 要处理这个问题需要拆成三步来看。第一步拿到背景图。页面上的背景图可能是一张完整的图片也可能是被打乱拼过的。要识别缺口位置必须先拿到这张图的完整数据。这里有个细节很多平台的滑块背景图会用 CSS 样式切成好几块直接截图会拿到带偏移的碎片处理起来很麻烦需要先做图像拼接或者找到原图接口。第二步算出缺口坐标。拿到完整背景图后用图像处理算法找出“拼图块应该嵌入的位置”。对人来说一眼能看出来的缺口程序需要用像素级对比来定位最常用的是 OpenCV 的边缘检测和轮廓查找。第三步模拟人类拖拽。算出距离之后RPA 要驱动鼠标完成从当前位置到目标位置的移动。注意这一步如果直接让鼠标“瞬移”过去平台的风控引擎一下子就能识别出来。真实人类的拖拽是有加速度、有抖动、有微调过程的必须模拟出类似曲线才能降低被识别的风险。这三步每一步都有坑后面我展开讲。1.2 适用场景与前置准备什么场景下你会碰到这个需求我自己遇到最多的是这三类电商批量操作比如定时上架商品、批量修改价格库存、自动回复买家消息。账号登录时经常遇到滑块。数据采集需要从商品页抓取竞品价格、评价内容频繁请求时会触发滑块验证。日常脚本巡检用 RPA 脚本代替人工做页面巡检页面在加载时弹出了验证码脚本就卡住了。做这套方案不需要特别高端的硬件配置一台普通办公电脑就够跑。软件层面我用的是一套完全免费的开源组合Python 3.9、OpenCV 库、Playwright 浏览器自动化框架。之所以选 Playwright 而不是老牌的 Selenium是因为 Playwright 对浏览器指纹的伪装支持更好而且自带截图和处理 iframe 的能力这对处理验证码场景非常有用。注意下面的方案只适用于你对自己账号进行合法的自动化操作或者在被授权的业务场景中使用。批量注册、恶意爬取、绕过平台正常风控等行为不在讨论范围内。技术本身是中性的怎么用取决于你自己。2. 核心技术原理与方案选型2.1 缺口识别OpenCV 图像处理滑块拼图验证码的核心是先要找到拼图块应该被放到哪里。这个“在哪里”就是缺口在整张背景图中的像素坐标。多平台滑块的缺口都是一个和背景图有明显色差、边缘清晰的形状块最常见的是圆形。我的做法是下面这套流程抓取背景图。将彩色图转为灰度图。用 Canny 边缘检测提取边缘。用 HoughCircles 或者轮廓查找定位缺口中心。结合拼图块的凸起高光点做二次确认。第一次做的时候我直接拿着不处理的原图去做 Canny结果检测出来的边缘线条非常多根本分不清哪个是缺口。后来发现关键在于预处理先用高斯模糊去掉背景里的噪点纹理再调整边缘检测的阈值。像素数据要精确到具体像素这里分享一下关键代码import cv2 import numpy as np def find_gap_position(bg_img): # bg_img: 背景图的OpenCV矩阵 BGR格式 # 先转灰度 gray cv2.cvtColor(bg_img, cv2.COLOR_BGR2GRAY) # 高斯模糊去掉背景纹理干扰 blurred cv2.GaussianBlur(gray, (5, 5), 0) # Canny边缘检测阈值需要根据实际图片微调 edges cv2.Canny(blurred, 100, 200) # 查找轮廓 contours, _ cv2.findContours( edges, cv2.RETR_TREE, cv2.CHAIN_APPROX_SIMPLE ) # 遍历轮廓找到面积适中的那个排除大背景和细小噪点 target None for c in contours: area cv2.contourArea(c) if area 500 or area 50000: continue # 用最小外接圆拟合 (x, y), radius cv2.minEnclosingCircle(c) if 15 radius 60: target (int(x), int(y)) break return target这段代码的核心思路是先找边缘再用几何特征做筛选。实际使用中缺口区域的边缘强度通常比背景纹理强得多所以阈值选择很关键。如果你发现识别出的位置总是偏移多半是 Canny 的阈值设置不合理或者缺口本身被阴影覆盖了。2.2 距离换算从像素到像素识别出缺口的像素坐标后还需要算出滑块要从当前位置“走”多少像素。这个距离不是简单的两个坐标相减因为滑块按钮本身有一定宽度拼图的最终停放位置是“拼图块的左边缘”与“缺口的左边缘”对齐而不是“滑块中心”与“缺口中心”对齐。我常用的计算公式是distance gap_left_x - slider_left_x - offset其中 offset 是滑块按钮中心点到滑块条起点的间隔这个值通常需要实测几次确定。不同的页面、不同的滑块尺寸offset 都不一样。还有一个坑页面可能不是 100% 缩放的如果电脑开启了显示缩放比如 125%、150%截图的像素和实际拖拽的像素就会不一致。我在代码里加了 DPI 校准用 JS 拿window.devicePixelRatio来做换算。const dpr window.devicePixelRatio; // 实际鼠标移动像素 截图像素差 / dpr这个坑踩过一次就长记性了。最初脚本在自己电脑上运行得好好的拿到一台高分屏笔记本上跑滑块永远停不到位。排查了半天最后发现是 DPI 缩放的问题。2.3 轨迹模拟对抗风控的关键很多做 RPA 的人会忽略这一步以为只要距离算对了把滑块拖过去就行。但实际拖过去之后平台返回的结果还是“验证失败”。为什么因为机器人拖拽和人类拖拽的轨迹特征完全不同。人类移动鼠标是先快后慢或先慢后快有自然的加速减速过程。轨迹不是一条直线有轻微的上下抖动。到达目标位置后会有小幅度的来回调整然后再松手。而 RPA 直接拖拽的轨迹通常是起点到终点一条直线速度恒定毫无抖动。风控引擎通过鼠标事件的时间间隔和坐标变化很容易就能判定这不是人类行为。我的解决方案是生成一条符合物理规律的模拟轨迹。用一个简单但有效的算法将总距离拆成多段每段设置不同的速度并在纵向上叠加正弦波噪声模拟人手抖动。import random import math def human_like_track(distance): track [] current 0 t 0 # 分三段加速、匀速、减速微调 phases [ (0.3, 1.8), # 前30%距离速度较快加速阶段 (0.5, 0.8), # 中间50%距离匀速 (0.2, 0.3), # 最后20%距离减速微调 ] for ratio, speed in phases: seg_dist distance * ratio while current seg_dist: step random.uniform(0.5, 1.5) * speed current step # 模拟纵向抖动 y_offset int(5 * math.sin(t * 0.5) random.uniform(-2, 2)) track.append((int(current), y_offset)) t 1 # 最后补一个回到目标位置的微调 track.append((distance, 0)) return track如果你用的是 Playwright可以把这些轨迹点通过 CDP 协议直接注入鼠标事件比 Playwright 自带的 hover 和 mouse.down/up 组合更底层可控性更高。3. 实操过程与核心环节实现3.1 基础设施搭建环境准备先说我本地的环境配置。我用的是 Python 3.9装了以下这些关键库pip install opencv-python playwright numpy playwright install chromium版本选择上有一个经验OpenCV 用开源版就够不需要装 contrib 版。numpy 必须装因为 OpenCV 的图片数据本质就是 numpy 数组。Playwright 会自动下载一个独立的 Chromium 内核这个内核和系统里装的浏览器互不干扰跑自动化脚本时更干净。如果你下载 Playwright 浏览器特别慢可以设置国内镜像源。网上有很多现成的配置方法我这里不展开了。3.2 完整识别流程从截图到坐标我用 Playwright 作为浏览器自动化框架。打开目标页面后定位到滑块验证码的 iframe 或者容器节点然后分四步操作第一步截图。用 Playwright 的element.screenshot()直接截取背景图的元素。这里有个优势Playwright 会等页面稳定之后再截图避免图片还没加载完就开识别。第二步识别。把截图交给上面提到的find_gap_position()函数拿到缺口中心坐标。如果背景图是完整的一张长图还需要从元素的实际尺寸和截图尺寸的比例来还原坐标。第三步计算距离。用 JS 在页面中获取滑块按钮的getBoundingClientRect()拿到按钮左边缘的位置然后算出需要拖拽的像素距离。第四步拖拽。把生成好的轨迹点通过 Playwright 注入进去。整体流程串起来是这样的from playwright.sync_api import sync_playwright def solve_slider(page): # 1. 定位验证码背景图元素 bg_el page.wait_for_selector(#captcha_bg, timeout5000) bg_el.screenshot(pathbg.png) # 2. 读取并识别缺口 bg_img cv2.imread(bg.png) gap_x, gap_y find_gap_position(bg_img) # 3. 获取滑块按钮位置 slider page.locator(#captcha_slider) box slider.bounding_box() start_x box[x] box[width] / 2 start_y box[y] box[height] / 2 distance gap_x - start_x - offset # 4. 生成轨迹并执行拖拽 track human_like_track(distance) page.mouse.move(start_x, start_y) page.mouse.down() for x, y in track: page.mouse.move(start_x x, start_y y, steps1) page.mouse.up()这里注意不同的验证码样式元素选择器完全不同。我上面写的是通用占位符实际项目中你需要用浏览器开发者工具去确认验证码容器、背景图、滑块按钮的真实选择器。这一点特别重要因为京东前端的元素 class 名更新很频繁写死选择器的脚本跑一段时间就会失效需要重新定位。3.3 动态容错识别失败后的自动重试第一次跑完整个流程我发现成功率大概在 70% 左右剩下的 30% 是识别偏差、拖拽轨迹异常、页面点击被拦截等问题。要提升整体通过率不能只靠优化单次识别还得加容错机制。我的容错方案是在外层套了一个重试循环for attempt in range(5): try: solve_slider(page) # 验证是否通过等待滑块容器消失或出现成功提示 page.wait_for_selector(#captcha_success, timeout2000) print(第{}次尝试通过.format(attempt1)) break except Exception as e: print(第{}次失败: {}.format(attempt1, str(e))) # 刷新验证码重新来 page.click(#captcha_refresh) page.wait_for_timeout(1000)这个循环很实用。验证码页面一般都有“刷新”按钮失败之后点一下刷新重新出题再试。每次刷新后背景图会变但识别算法不依赖具体图片内容只要结构一致就能继续跑。注意重试次数不要太夸张单次验证连续失败太多次可能会触发更高级的风控甚至短暂封禁操作权限。我自己的经验是 3 到 5 次以内比较安全如果 5 次都失败建议暂定几分钟再继续让页面冷静一下。3.4 与业务脚本的对接方式滑块验证码很少是一个孤立需求它通常是某个业务流程中的一环比如“登录→滑块→进入后台→批量操作”。所以有一个好的对接方式很重要。我自己习惯把滑块处理封装成一个独立函数这样调用方不关心内部实现只需要传入page对象。比如下面的登录场景def login_with_captcha(page, username, password): page.goto(https://example.com/login) page.fill(#username, username) page.fill(#password, password) page.click(#login_btn) # 等待验证码出现 try: page.wait_for_selector(#captcha_bg, timeout3000) solve_slider(page) except: print(本次登录未出现滑块验证码) page.wait_for_url(**/dashboard)封装成独立函数的好处是滑块验证的细节完全被隔离后面如果京东更新了验证码样式只需要改solve_slider()内部逻辑业务代码一行都不用动。这个思路放到任何 RPA 项目里都适用。4. 常见问题与排查技巧实录写这部分之前我又把几个月来跑这套脚本碰到的各种问题整理了一遍。下面这几个坑基本是每个做滑块识别自动化的朋友都会遇到的按出现频率排序。4.1 缺口识别偏移现象滑块拖到了位置但还是提示验证失败或者拼图块停在了缺口边缘。原因分析这个问题的根源通常有两个。一个是缺口检测时候选轮廓选错了比如把背景中某个边缘纹理当成了缺口。另一个是背景图和实际页面显示尺寸不一致。页面上的图片可能被 CSS 拉伸过或者object-fit: cover导致图片做了裁剪你看到的图和截下来的图根本不是同一张。排查方法把识别后的缺口坐标画在图上人工看一下识别结果是不是对的。这是我排查的第一步十次里有七次问题在这里就暴露了。检查元素宽度和截图像素。用el.bounding_box()拿到的宽度要和截图的宽度对得上对不上就有缩放问题。由于平台的背景图经常是两张图拼在一起的一张带拼图块的图一张纯背景的图缺口位置在纯背景图上的坐标需要从接口返回的数据里拿。如果走截图识别路线就忽略带拼图块的那张只用纯背景的。这里放一个调试用的可视化小技巧代码很简单但救了我好几次# 在识别结果上画红色圆点 debug_img bg_img.copy() cv2.circle(debug_img, (gap_x, gap_y), 10, (0, 0, 255), 2) cv2.imwrite(debug_show.png, debug_img)4.2 拖拽被判定为机器行为现象轨迹识别代码看着没问题缺口也准了但验证还是失败。刷新几次换新图也不行。原因分析问题出在鼠标事件层面。有些滑块验证码不光是看你鼠标最后停在哪而是记录整个拖拽过程的mousedown、mousemove、mouseup事件时序。如果事件间隔太均匀、轨迹点太规整就触发风控了。我的改进做法在轨迹中加入随机停顿比如拖到 30% 位置时停 0.1 到 0.3 秒模拟人类犹豫的过程。纵向抖动不能是完美正弦波要叠加随机噪声。完美正弦波本身也是一个特征一看就是程序生成的。拖拽总时长控制在 1 到 2 秒太快太慢都容易出问题。不用 Playwright 的drag_to()方法这个方法生成的事件太规整我很早就放弃它了改为手动mouse.move配合mouse.down/up。4.3 元素定位不到或页面结构变化现象脚本昨天跑得好好的今天突然报TimeoutError等不到验证码元素出现。原因分析前端改版了或者验证码只在特定触发条件才出现。这个在电商场景非常常见页面模板隔几周就换一次是常态。应对思路选择器不要写太深。优先用#id其次用稳定的 classheader 嵌套层级深的选择器尽量不要用。做好等待策略。用 Playwright 的wait_for_selector而不是固定sleep页面加载快慢不会影响稳定性。把验证码容器相关的选择器提取为一个配置项页面改版时只改配置不动主逻辑。4.4 识别速度太慢影响整体效率现象跑了几百次之后统计发现一次滑块通过平均要花 8 秒其中识别占了 5 秒。批量任务做起来太慢。原因分析主要慢在 OpenCV 的轮廓检测上如果背景图画质高、分辨率大像素级别操作本来就耗时。加上我那时用了cv2.imread从硬盘读图磁盘 IO 也增加了延迟。优化措施把截图直接作为内存数据传给 OpenCV不走硬盘。用 numpy 把截图转成矩阵以后识别耗时能从 5 秒降到 1 秒以内。只是一行代码的差别速度提升非常明显。# 不要这样 bg_img cv2.imread(bg.png) # 改成这样 img_array np.asarray(bytearray(screenshot_bytes), dtypenp.uint8) bg_img cv2.imdecode(img_array, cv2.IMREAD_COLOR)4.5 常见问题速查表问题可能原因解决方案缺口定位偏左/偏右未考虑滑块按钮宽度offset 不准确实测 offset加入距离换算拖过去但验证失败轨迹太机械被风控识别使用分段变速纵向抖动轨迹截图是空白/灰色背景图用了懒加载或 canvas 绘制等图片加载完成后再截图或改用接口拉图高分屏下识别不准DPI 缩放导致像素比例不对用 devicePixelRatio 校正坐标连续重试后触发二次验证短时间尝试太频繁限制重试次数加入冷却时间4.6 被风控后的冷静期处理这是我额外想讲的一个经验。有时候滑块验证失败太多次页面会弹出一个更难处理的验证方式比如按顺序点击文字。遇到这种情况我现在的做法是直接停机冷却而不是继续硬刚。冷却期建议 10 到 15 分钟。这段时间可以处理其他自动化任务或者插入一个人工介入的等待节点。RPA 项目切记稳定的核心不是单点成功率多高而是失败之后能不能优雅地降级。5. 资源消耗与效果评估跑这个方案一个月后我记录了一些真实数据供参考。我拿一台普通的办公电脑跑CPU 是几年前的 i5内存 8G没有独立显卡。整个识别流程的 CPU 占用率大概在 20% 到 30% 之间内存占用约 500MB这在 RPA 项目里算比较轻量的。如果遇到高分辨率大图峰值会再高一些但不会影响日常办公。成功率方面我把“首次识别并拖拽成功”和“重试后成功”分别做了统计。首次成功率大约在 75%这个数字主要受验证码图片复杂度影响有的图缺口和背景颜色极其接近人眼都费劲算法就更难重试后的综合通过率能超过 95%因为我设了 5 次重试上限而且每次重试会刷新图片。重试成功率比首次高很多是因为第一次失败通常能反馈出偏移方向代码里保存了这个偏差值在后续重试中做了补偿。耗时方面单次滑块处理从截图到松手大约 2 到 3 秒加上失败重试平均 4 到 6 秒。这个速度比人工操作的 2 到 3 秒稍慢但胜在稳定和不知疲倦跑几百次都不用休息。如果你的业务场景对速度要求极高可以考虑多账号并行跑但我不建议在同一台机器上跑太多并发容易触发更严格的风控。6. 写在最后的一点体会这套方案跑下来我最深的一个感受是RPA 处理滑块验证码真正难的不是写代码而是理解平台风控的思考方式。风控引擎判断的核心不是你有没有拖到正确位置而是你“怎么”拖过去的。位置对了不代表行为对这就像一个人能走到终点和在路上怎么走的区别。另外一点经验之谈是别迷信网上现成的所谓“秒过验证码”的脚本。那种脚本往往针对特定页面写死了元素和参数换个页面就没用而且很容易被平台的反制措施盯上。自己动手写的好处是你能完全掌控每一步出了问题也方便排查。把识别、轨迹、容错这些模块拆开每个部分单独测试这时候你再拼装起来稳定性会比直接拿来主义好得多。后续我还在这个方案基础上加了验证码图片的自动缓存方便分析失败案例也方便遇到页面升级时快速回溯。个人体会是这类问题没有一劳永逸的方案平台改版、风控升级我们这边的识别策略也得跟着迭代。保持对页面的监控定期跑一下自测用例才能让你的 RPA 脚本在长期运行中不掉链子。 
长河君 · 2026/10/17 3:01:09 · 阅读 1.2k RPA实战：用OpenCV和Playwright破解滑块拼图验证码
做电商后台自动化的朋友多少都被滑块拼图验证码拦过路。尤其是京东这类大平台登录、下单、批量操作时滑块验证码出现的频率不低。我最初也想过用现成的打码平台但接第三方服务一是要花钱二是数据要过别人服务器心里总不踏实三是响应速度不稳定跑批量任务时经常卡在等待上。后来决定自己用 RPA 思路做一套从图像识别到模拟拖拽全走本地效果反而比预期好很多。这篇文章就从我的实战角度把 RPA 处理京东滑块拼图验证码的完整思路拆开讲清楚包括缺口识别、轨迹模拟、踩坑记录。适合刚接触 RPA 自动化、想自己搞定滑块验证的朋友也适合已经在做电商自动化但总被验证码卡住的老手。1. 项目概述与需求拆解1.1 核心需求解析先说清楚这是个什么事。滑块拼图验证码本质上就是平台用来区分“真人操作”和“机器操作”的一道关卡。界面上一张背景图上面有一块拼图缺口下面一个滑块你需要把滑块拖到一个正确位置让拼图块和缺口对齐系统才会放你通过。RPA 要处理这个问题需要拆成三步来看。第一步拿到背景图。页面上的背景图可能是一张完整的图片也可能是被打乱拼过的。要识别缺口位置必须先拿到这张图的完整数据。这里有个细节很多平台的滑块背景图会用 CSS 样式切成好几块直接截图会拿到带偏移的碎片处理起来很麻烦需要先做图像拼接或者找到原图接口。第二步算出缺口坐标。拿到完整背景图后用图像处理算法找出“拼图块应该嵌入的位置”。对人来说一眼能看出来的缺口程序需要用像素级对比来定位最常用的是 OpenCV 的边缘检测和轮廓查找。第三步模拟人类拖拽。算出距离之后RPA 要驱动鼠标完成从当前位置到目标位置的移动。注意这一步如果直接让鼠标“瞬移”过去平台的风控引擎一下子就能识别出来。真实人类的拖拽是有加速度、有抖动、有微调过程的必须模拟出类似曲线才能降低被识别的风险。这三步每一步都有坑后面我展开讲。1.2 适用场景与前置准备什么场景下你会碰到这个需求我自己遇到最多的是这三类电商批量操作比如定时上架商品、批量修改价格库存、自动回复买家消息。账号登录时经常遇到滑块。数据采集需要从商品页抓取竞品价格、评价内容频繁请求时会触发滑块验证。日常脚本巡检用 RPA 脚本代替人工做页面巡检页面在加载时弹出了验证码脚本就卡住了。做这套方案不需要特别高端的硬件配置一台普通办公电脑就够跑。软件层面我用的是一套完全免费的开源组合Python 3.9、OpenCV 库、Playwright 浏览器自动化框架。之所以选 Playwright 而不是老牌的 Selenium是因为 Playwright 对浏览器指纹的伪装支持更好而且自带截图和处理 iframe 的能力这对处理验证码场景非常有用。注意下面的方案只适用于你对自己账号进行合法的自动化操作或者在被授权的业务场景中使用。批量注册、恶意爬取、绕过平台正常风控等行为不在讨论范围内。技术本身是中性的怎么用取决于你自己。2. 核心技术原理与方案选型2.1 缺口识别OpenCV 图像处理滑块拼图验证码的核心是先要找到拼图块应该被放到哪里。这个“在哪里”就是缺口在整张背景图中的像素坐标。多平台滑块的缺口都是一个和背景图有明显色差、边缘清晰的形状块最常见的是圆形。我的做法是下面这套流程抓取背景图。将彩色图转为灰度图。用 Canny 边缘检测提取边缘。用 HoughCircles 或者轮廓查找定位缺口中心。结合拼图块的凸起高光点做二次确认。第一次做的时候我直接拿着不处理的原图去做 Canny结果检测出来的边缘线条非常多根本分不清哪个是缺口。后来发现关键在于预处理先用高斯模糊去掉背景里的噪点纹理再调整边缘检测的阈值。像素数据要精确到具体像素这里分享一下关键代码import cv2 import numpy as np def find_gap_position(bg_img): # bg_img: 背景图的OpenCV矩阵 BGR格式 # 先转灰度 gray cv2.cvtColor(bg_img, cv2.COLOR_BGR2GRAY) # 高斯模糊去掉背景纹理干扰 blurred cv2.GaussianBlur(gray, (5, 5), 0) # Canny边缘检测阈值需要根据实际图片微调 edges cv2.Canny(blurred, 100, 200) # 查找轮廓 contours, _ cv2.findContours( edges, cv2.RETR_TREE, cv2.CHAIN_APPROX_SIMPLE ) # 遍历轮廓找到面积适中的那个排除大背景和细小噪点 target None for c in contours: area cv2.contourArea(c) if area 500 or area 50000: continue # 用最小外接圆拟合 (x, y), radius cv2.minEnclosingCircle(c) if 15 radius 60: target (int(x), int(y)) break return target这段代码的核心思路是先找边缘再用几何特征做筛选。实际使用中缺口区域的边缘强度通常比背景纹理强得多所以阈值选择很关键。如果你发现识别出的位置总是偏移多半是 Canny 的阈值设置不合理或者缺口本身被阴影覆盖了。2.2 距离换算从像素到像素识别出缺口的像素坐标后还需要算出滑块要从当前位置“走”多少像素。这个距离不是简单的两个坐标相减因为滑块按钮本身有一定宽度拼图的最终停放位置是“拼图块的左边缘”与“缺口的左边缘”对齐而不是“滑块中心”与“缺口中心”对齐。我常用的计算公式是distance gap_left_x - slider_left_x - offset其中 offset 是滑块按钮中心点到滑块条起点的间隔这个值通常需要实测几次确定。不同的页面、不同的滑块尺寸offset 都不一样。还有一个坑页面可能不是 100% 缩放的如果电脑开启了显示缩放比如 125%、150%截图的像素和实际拖拽的像素就会不一致。我在代码里加了 DPI 校准用 JS 拿window.devicePixelRatio来做换算。const dpr window.devicePixelRatio; // 实际鼠标移动像素 截图像素差 / dpr这个坑踩过一次就长记性了。最初脚本在自己电脑上运行得好好的拿到一台高分屏笔记本上跑滑块永远停不到位。排查了半天最后发现是 DPI 缩放的问题。2.3 轨迹模拟对抗风控的关键很多做 RPA 的人会忽略这一步以为只要距离算对了把滑块拖过去就行。但实际拖过去之后平台返回的结果还是“验证失败”。为什么因为机器人拖拽和人类拖拽的轨迹特征完全不同。人类移动鼠标是先快后慢或先慢后快有自然的加速减速过程。轨迹不是一条直线有轻微的上下抖动。到达目标位置后会有小幅度的来回调整然后再松手。而 RPA 直接拖拽的轨迹通常是起点到终点一条直线速度恒定毫无抖动。风控引擎通过鼠标事件的时间间隔和坐标变化很容易就能判定这不是人类行为。我的解决方案是生成一条符合物理规律的模拟轨迹。用一个简单但有效的算法将总距离拆成多段每段设置不同的速度并在纵向上叠加正弦波噪声模拟人手抖动。import random import math def human_like_track(distance): track [] current 0 t 0 # 分三段加速、匀速、减速微调 phases [ (0.3, 1.8), # 前30%距离速度较快加速阶段 (0.5, 0.8), # 中间50%距离匀速 (0.2, 0.3), # 最后20%距离减速微调 ] for ratio, speed in phases: seg_dist distance * ratio while current seg_dist: step random.uniform(0.5, 1.5) * speed current step # 模拟纵向抖动 y_offset int(5 * math.sin(t * 0.5) random.uniform(-2, 2)) track.append((int(current), y_offset)) t 1 # 最后补一个回到目标位置的微调 track.append((distance, 0)) return track如果你用的是 Playwright可以把这些轨迹点通过 CDP 协议直接注入鼠标事件比 Playwright 自带的 hover 和 mouse.down/up 组合更底层可控性更高。3. 实操过程与核心环节实现3.1 基础设施搭建环境准备先说我本地的环境配置。我用的是 Python 3.9装了以下这些关键库pip install opencv-python playwright numpy playwright install chromium版本选择上有一个经验OpenCV 用开源版就够不需要装 contrib 版。numpy 必须装因为 OpenCV 的图片数据本质就是 numpy 数组。Playwright 会自动下载一个独立的 Chromium 内核这个内核和系统里装的浏览器互不干扰跑自动化脚本时更干净。如果你下载 Playwright 浏览器特别慢可以设置国内镜像源。网上有很多现成的配置方法我这里不展开了。3.2 完整识别流程从截图到坐标我用 Playwright 作为浏览器自动化框架。打开目标页面后定位到滑块验证码的 iframe 或者容器节点然后分四步操作第一步截图。用 Playwright 的element.screenshot()直接截取背景图的元素。这里有个优势Playwright 会等页面稳定之后再截图避免图片还没加载完就开识别。第二步识别。把截图交给上面提到的find_gap_position()函数拿到缺口中心坐标。如果背景图是完整的一张长图还需要从元素的实际尺寸和截图尺寸的比例来还原坐标。第三步计算距离。用 JS 在页面中获取滑块按钮的getBoundingClientRect()拿到按钮左边缘的位置然后算出需要拖拽的像素距离。第四步拖拽。把生成好的轨迹点通过 Playwright 注入进去。整体流程串起来是这样的from playwright.sync_api import sync_playwright def solve_slider(page): # 1. 定位验证码背景图元素 bg_el page.wait_for_selector(#captcha_bg, timeout5000) bg_el.screenshot(pathbg.png) # 2. 读取并识别缺口 bg_img cv2.imread(bg.png) gap_x, gap_y find_gap_position(bg_img) # 3. 获取滑块按钮位置 slider page.locator(#captcha_slider) box slider.bounding_box() start_x box[x] box[width] / 2 start_y box[y] box[height] / 2 distance gap_x - start_x - offset # 4. 生成轨迹并执行拖拽 track human_like_track(distance) page.mouse.move(start_x, start_y) page.mouse.down() for x, y in track: page.mouse.move(start_x x, start_y y, steps1) page.mouse.up()这里注意不同的验证码样式元素选择器完全不同。我上面写的是通用占位符实际项目中你需要用浏览器开发者工具去确认验证码容器、背景图、滑块按钮的真实选择器。这一点特别重要因为京东前端的元素 class 名更新很频繁写死选择器的脚本跑一段时间就会失效需要重新定位。3.3 动态容错识别失败后的自动重试第一次跑完整个流程我发现成功率大概在 70% 左右剩下的 30% 是识别偏差、拖拽轨迹异常、页面点击被拦截等问题。要提升整体通过率不能只靠优化单次识别还得加容错机制。我的容错方案是在外层套了一个重试循环for attempt in range(5): try: solve_slider(page) # 验证是否通过等待滑块容器消失或出现成功提示 page.wait_for_selector(#captcha_success, timeout2000) print(第{}次尝试通过.format(attempt1)) break except Exception as e: print(第{}次失败: {}.format(attempt1, str(e))) # 刷新验证码重新来 page.click(#captcha_refresh) page.wait_for_timeout(1000)这个循环很实用。验证码页面一般都有“刷新”按钮失败之后点一下刷新重新出题再试。每次刷新后背景图会变但识别算法不依赖具体图片内容只要结构一致就能继续跑。注意重试次数不要太夸张单次验证连续失败太多次可能会触发更高级的风控甚至短暂封禁操作权限。我自己的经验是 3 到 5 次以内比较安全如果 5 次都失败建议暂定几分钟再继续让页面冷静一下。3.4 与业务脚本的对接方式滑块验证码很少是一个孤立需求它通常是某个业务流程中的一环比如“登录→滑块→进入后台→批量操作”。所以有一个好的对接方式很重要。我自己习惯把滑块处理封装成一个独立函数这样调用方不关心内部实现只需要传入page对象。比如下面的登录场景def login_with_captcha(page, username, password): page.goto(https://example.com/login) page.fill(#username, username) page.fill(#password, password) page.click(#login_btn) # 等待验证码出现 try: page.wait_for_selector(#captcha_bg, timeout3000) solve_slider(page) except: print(本次登录未出现滑块验证码) page.wait_for_url(**/dashboard)封装成独立函数的好处是滑块验证的细节完全被隔离后面如果京东更新了验证码样式只需要改solve_slider()内部逻辑业务代码一行都不用动。这个思路放到任何 RPA 项目里都适用。4. 常见问题与排查技巧实录写这部分之前我又把几个月来跑这套脚本碰到的各种问题整理了一遍。下面这几个坑基本是每个做滑块识别自动化的朋友都会遇到的按出现频率排序。4.1 缺口识别偏移现象滑块拖到了位置但还是提示验证失败或者拼图块停在了缺口边缘。原因分析这个问题的根源通常有两个。一个是缺口检测时候选轮廓选错了比如把背景中某个边缘纹理当成了缺口。另一个是背景图和实际页面显示尺寸不一致。页面上的图片可能被 CSS 拉伸过或者object-fit: cover导致图片做了裁剪你看到的图和截下来的图根本不是同一张。排查方法把识别后的缺口坐标画在图上人工看一下识别结果是不是对的。这是我排查的第一步十次里有七次问题在这里就暴露了。检查元素宽度和截图像素。用el.bounding_box()拿到的宽度要和截图的宽度对得上对不上就有缩放问题。由于平台的背景图经常是两张图拼在一起的一张带拼图块的图一张纯背景的图缺口位置在纯背景图上的坐标需要从接口返回的数据里拿。如果走截图识别路线就忽略带拼图块的那张只用纯背景的。这里放一个调试用的可视化小技巧代码很简单但救了我好几次# 在识别结果上画红色圆点 debug_img bg_img.copy() cv2.circle(debug_img, (gap_x, gap_y), 10, (0, 0, 255), 2) cv2.imwrite(debug_show.png, debug_img)4.2 拖拽被判定为机器行为现象轨迹识别代码看着没问题缺口也准了但验证还是失败。刷新几次换新图也不行。原因分析问题出在鼠标事件层面。有些滑块验证码不光是看你鼠标最后停在哪而是记录整个拖拽过程的mousedown、mousemove、mouseup事件时序。如果事件间隔太均匀、轨迹点太规整就触发风控了。我的改进做法在轨迹中加入随机停顿比如拖到 30% 位置时停 0.1 到 0.3 秒模拟人类犹豫的过程。纵向抖动不能是完美正弦波要叠加随机噪声。完美正弦波本身也是一个特征一看就是程序生成的。拖拽总时长控制在 1 到 2 秒太快太慢都容易出问题。不用 Playwright 的drag_to()方法这个方法生成的事件太规整我很早就放弃它了改为手动mouse.move配合mouse.down/up。4.3 元素定位不到或页面结构变化现象脚本昨天跑得好好的今天突然报TimeoutError等不到验证码元素出现。原因分析前端改版了或者验证码只在特定触发条件才出现。这个在电商场景非常常见页面模板隔几周就换一次是常态。应对思路选择器不要写太深。优先用#id其次用稳定的 classheader 嵌套层级深的选择器尽量不要用。做好等待策略。用 Playwright 的wait_for_selector而不是固定sleep页面加载快慢不会影响稳定性。把验证码容器相关的选择器提取为一个配置项页面改版时只改配置不动主逻辑。4.4 识别速度太慢影响整体效率现象跑了几百次之后统计发现一次滑块通过平均要花 8 秒其中识别占了 5 秒。批量任务做起来太慢。原因分析主要慢在 OpenCV 的轮廓检测上如果背景图画质高、分辨率大像素级别操作本来就耗时。加上我那时用了cv2.imread从硬盘读图磁盘 IO 也增加了延迟。优化措施把截图直接作为内存数据传给 OpenCV不走硬盘。用 numpy 把截图转成矩阵以后识别耗时能从 5 秒降到 1 秒以内。只是一行代码的差别速度提升非常明显。# 不要这样 bg_img cv2.imread(bg.png) # 改成这样 img_array np.asarray(bytearray(screenshot_bytes), dtypenp.uint8) bg_img cv2.imdecode(img_array, cv2.IMREAD_COLOR)4.5 常见问题速查表问题可能原因解决方案缺口定位偏左/偏右未考虑滑块按钮宽度offset 不准确实测 offset加入距离换算拖过去但验证失败轨迹太机械被风控识别使用分段变速纵向抖动轨迹截图是空白/灰色背景图用了懒加载或 canvas 绘制等图片加载完成后再截图或改用接口拉图高分屏下识别不准DPI 缩放导致像素比例不对用 devicePixelRatio 校正坐标连续重试后触发二次验证短时间尝试太频繁限制重试次数加入冷却时间4.6 被风控后的冷静期处理这是我额外想讲的一个经验。有时候滑块验证失败太多次页面会弹出一个更难处理的验证方式比如按顺序点击文字。遇到这种情况我现在的做法是直接停机冷却而不是继续硬刚。冷却期建议 10 到 15 分钟。这段时间可以处理其他自动化任务或者插入一个人工介入的等待节点。RPA 项目切记稳定的核心不是单点成功率多高而是失败之后能不能优雅地降级。5. 资源消耗与效果评估跑这个方案一个月后我记录了一些真实数据供参考。我拿一台普通的办公电脑跑CPU 是几年前的 i5内存 8G没有独立显卡。整个识别流程的 CPU 占用率大概在 20% 到 30% 之间内存占用约 500MB这在 RPA 项目里算比较轻量的。如果遇到高分辨率大图峰值会再高一些但不会影响日常办公。成功率方面我把“首次识别并拖拽成功”和“重试后成功”分别做了统计。首次成功率大约在 75%这个数字主要受验证码图片复杂度影响有的图缺口和背景颜色极其接近人眼都费劲算法就更难重试后的综合通过率能超过 95%因为我设了 5 次重试上限而且每次重试会刷新图片。重试成功率比首次高很多是因为第一次失败通常能反馈出偏移方向代码里保存了这个偏差值在后续重试中做了补偿。耗时方面单次滑块处理从截图到松手大约 2 到 3 秒加上失败重试平均 4 到 6 秒。这个速度比人工操作的 2 到 3 秒稍慢但胜在稳定和不知疲倦跑几百次都不用休息。如果你的业务场景对速度要求极高可以考虑多账号并行跑但我不建议在同一台机器上跑太多并发容易触发更严格的风控。6. 写在最后的一点体会这套方案跑下来我最深的一个感受是RPA 处理滑块验证码真正难的不是写代码而是理解平台风控的思考方式。风控引擎判断的核心不是你有没有拖到正确位置而是你“怎么”拖过去的。位置对了不代表行为对这就像一个人能走到终点和在路上怎么走的区别。另外一点经验之谈是别迷信网上现成的所谓“秒过验证码”的脚本。那种脚本往往针对特定页面写死了元素和参数换个页面就没用而且很容易被平台的反制措施盯上。自己动手写的好处是你能完全掌控每一步出了问题也方便排查。把识别、轨迹、容错这些模块拆开每个部分单独测试这时候你再拼装起来稳定性会比直接拿来主义好得多。后续我还在这个方案基础上加了验证码图片的自动缓存方便分析失败案例也方便遇到页面升级时快速回溯。个人体会是这类问题没有一劳永逸的方案平台改版、风控升级我们这边的识别策略也得跟着迭代。保持对页面的监控定期跑一下自测用例才能让你的 RPA 脚本在长期运行中不掉链子。