滑动验证码破解不能靠图像识别硬刚，因光照、噪声等干扰导致cv2.matchTemplate失效；有效路径是逆向行为逻辑，抓包定位验证请求并复现浏览器滑动轨迹生成逻辑。
滑动验证码破解为什么不能靠“图像识别”硬刚？
绝大多数人一上来就想用 OpenCV 或 OCR 识别缺口位置，结果卡在光照、背景噪声、滑块阴影、动态模糊上——cv2.matchTemplate 在真实网站（如极验 v3、网易易盾）里基本失效。真正有效的路径是逆向行为逻辑：抓包定位验证请求链路，复现浏览器滑动轨迹的生成逻辑，而非像素比对。
实操建议：
- 先用浏览器开发者工具过滤
XHR，找到触发验证成功的请求（通常是/ajax.php?captcha-solution或类似带lottery/validate的接口） - 断点调试前端 JS，重点追踪
getTrack、generateTrack、getSlideResult这类函数，它们往往用时间戳 + 鼠标坐标生成加密轨迹数组 - 避开直接调用
document.getElementById模拟拖拽——现代验证会检测MouseEvent.movementX和事件触发频率，纯 JS 注入无效
点选验证码怎么绕过“必须人工点击”的限制？
点选类（如腾讯防水墙、阿里云盾）本质是行为采集 + 图像语义理解双校验。你点得再准，如果 touchstart 到 touchend 间隔太短、坐标跳变突兀、缺少 hover 停留，后端直接返回 {"result":false,"reason":"abnormal_behavior"}。
关键不是“点哪”，而是“怎么点”：
立即学习“Python免费学习笔记（深入）”；
- 必须还原真实鼠标移动路径：从起始位置分段匀速移动到目标区域，中间插入 1–2 次小幅抖动（±3px），并在每个候选图标前停留 80–150ms
- 禁用
element.click()，改用driver.execute_script("arguments[0].dispatchEvent(new MouseEvent('click', {bubbles: true}));", elem)模拟原生事件流 - 注意坐标系转换：网页缩放（
window.devicePixelRatio）、iframe 嵌套、滚动偏移都会导致getBoundingClientRect()返回值与实际点击位置偏差，需手动补偿
用 Selenium + undetected-chromedriver2 还会被识别吗？
会，而且很常见。很多站点（如京东登录页）已把 webdriver 属性、navigator.permissions.query 返回值、chrome.loadTimes() 等 20+ 个指纹特征纳入风控模型。单纯换掉 undetected-chromedriver2 不足以过关。
有效缓解手段：
- 启动时注入
--disable-blink-features=AutomationControlled并立即执行driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", {...})覆盖navigator.webdriver为undefined - 禁用图片加载：
prefs = {"profile.managed_default_content_settings.images": 2}，减少资源请求特征 - 避免使用
find_element_by_xpath（已弃用且触发额外日志），统一用find_element(By.XPATH, "...")，降低 DOM 查询模式暴露风险
有没有真正能落地的轻量级方案？
有，但仅限于中低风险场景（如企业后台、非高频采集）。推荐组合：requests + execjs + 手动维护的 JS 上下文。
例如极验 v4 的滑动验证，核心是解密一段混淆 JS 中的 getDistance 函数：
const distance = getDistance(imgData, sliderImgData); // 实际是 canvas 像素差值计算
你可以把这段 JS 提取出来，用 execjs.compile(js_code).call("getDistance", img_data, slider_data) 直接跑出距离值，再代入公开的轨迹生成算法（GitHub 上有多个复现版 generate_tracks），最后 POST 到验证接口。全程不启浏览器，速度快、内存低、特征干净。
但要注意：一旦目标站升级 JS 加密方式（比如引入 WebAssembly 或服务端动态下发混淆密钥），这套逻辑就立刻失效——这类验证码的对抗本质是持续更新的 JS 逆向战，没有一劳永逸的解法。
