滑块验证码为什么总拖不动CSS 坐标、DPR 与原生鼠标事件现象很典型元素找得到、坐标算得出、脚本也点了滑块纹丝不动或者动了一半弹回去报请控制滑块拼合缺口。换 Playwright、换 Selenium、换 Puppeteer结果一样。这类问题我踩了不止一次最后通杀的方案不是换框架而是换输入层不再用浏览器合成事件改用操作系统原生鼠标事件。下面把坐标换算的推导、坑位和一份能直接跑的代码都写清楚。一、先分清三套坐标系绝大多数拖不动的问题根源是坐标不在同一套坐标系里。坐标系谁在用取值来源CSS 视口坐标页面 JS、getBoundingClientRect()rect.x / rect.y屏幕 CSS 坐标浏览器窗口在屏幕上的位置视口原点 CSS 坐标物理像素坐标操作系统鼠标事件屏幕 CSS 坐标 × DPR关键点物理坐标 (视口原点CSS 元素CSS坐标) × DPR在 Windows 上DPR 通常不是 1。我本机是1.5150% 缩放。如果你直接把getBoundingClientRect()的值喂给ctypes的鼠标事件就会系统性偏移 1.5 倍——滑块要么不动要么滑过头。视口原点怎么拿最容易踩的坑用window.screenX / window.screenY。// 后台标签页里这两个值会返回 0window.screenX// 0window.screenY// 0标签页处于后台时visibilityState hidden浏览器不会给它真实的窗口位置返回值是 0。你拿 0 当原点算出来的坐标自然全错。可靠做法先Page.bringToFront把标签切到前台再用 CDP 的Browser.getWindowBounds拿窗口位置视口原点 窗口位置 浏览器工具栏高度。实测下来更省事的办法是标定一次在页面上放一个已知位置的元素用截图 像素比对反推原点。我本机标定结果是CSS (239, 566)这个值在一个稳定的窗口布局下长期有效。二、为什么合成事件过不了风控滑块的判定不只看轨迹还会看事件来源。通过 CDPInput.dispatchMouseEvent或element.dispatchEvent(new MouseEvent(...))发出的事件isTrusted属性是false。风控脚本只要读一下这个属性就能区分真人动的鼠标和程序伪造的事件。document.addEventListener(mousemove,e{console.log(e.isTrusted);// 真人: true 脚本: false});Playwright 的mouse.move()同理——它走的是 CDP Input 域本质是合成事件。解法绕过浏览器事件栈直接调用操作系统 API 产生真实的鼠标输入。Windows 上就是user32.dll的SendInput/mouse_event。这样产生的事件浏览器认为是真实硬件输入isTrusted为 true。三、轨迹不能一条直线拖过去真实鼠标移动的特征加速度是先快后慢中间有微小抖动不是匀速直线起手有短暂停顿到位后可能有回拉修正机器拖动的典型特征一次 mouseMove 直达终点或者严格等距的匀速移动。这两种都会被判机器。模拟策略实测有效把总距离切成20–40 段速度用先加速、后减速的缓动函数ease-out 更像真人收手每步叠加±1 px 的垂直抖动到位后停顿 100–200 ms再释放importmath,random,timedefmake_track(distance,steps30):生成先快后慢、带轻微抖动的轨迹偏移量offsets[]foriinrange(steps):t(i1)/steps# ease-out起步快收尾慢xdistance*(1-math.pow(1-t,2))yrandom.uniform(-1.2,1.2)offsets.append((x,y))returnoffsets四、一份能跑的最小实现下面是核心部分Windows Pythonctypes直接调SendInputimportctypesfromctypesimportwintypes ULONG_PTRctypes.POINTER(ctypes.c_ulong)INPUT_MOUSE0MOUSEEVENTF_MOVE0x0001MOUSEEVENTF_LEFTDOWN0x0002MOUSEEVENTF_LEFTUP0x0004MOUSEEVENTF_ABSOLUTE0x8000classMOUSEINPUT(ctypes.Structure):_fields_[(dx,wintypes.LONG),(dy,wintypes.LONG),(mouseData,wintypes.DWORD),(dwFlags,wintypes.DWORD),(time,wintypes.DWORD),(dwExtraInfo,ULONG_PTR)]classINPUT(ctypes.Structure):_fields_[(type,wintypes.DWORD),(mi,MOUSEINPUT)]def_send(flags,dx0,dy0):miMOUSEINPUT(dx,dy,0,flags,0,None)inpINPUT(INPUT_MOUSE,mi)ctypes.windll.user32.SendInput(1,ctypes.byref(inp),ctypes.sizeof(inp))def_abs(x,y):物理像素 → SendInput 的 0..65535 归一化坐标wctypes.windll.user32.GetSystemMetrics(0)hctypes.windll.user32.GetSystemMetrics(1)returnint(x*65535/w),int(y*65535/h)defdrag(x0,y0,distance,dpr1.5,origin(239,566),cssNone): x0, y0 : 元素在页面里的 CSS 坐标 css : 元素相对视口的 CSS 坐标若已含视口偏移则传 None # 1) CSS → 屏幕 CSS → 物理像素sx(origin[0]x0)*dpr sy(origin[1]y0)*dpr px,py_abs(sx,sy)_send(MOUSEEVENTF_ABSOLUTE|MOUSEEVENTF_MOVE,px,py)time.sleep(0.08)_send(MOUSEEVENTF_LEFTDOWN)time.sleep(0.05)last0fordx,dyinmake_track(distance*dpr):# 距离同样要乘 DPRstep_xsxdx step_ysydy ax,ay_abs(step_x,step_y)_send(MOUSEEVENTF_ABSOLUTE|MOUSEEVENTF_MOVE,ax,ay)time.sleep(random.uniform(0.008,0.022))lastdx time.sleep(0.15)_send(MOUSEEVENTF_LEFTUP)returnTrue用法# 从页面拿到滑块的 CSS 坐标rectpage.evaluate(() { const r document.querySelector(.slider).getBoundingClientRect(); return {x:r.x, y:r.y, w:r.width, h:r.height} })# 目标位移CSS 像素实测目标缺口位置 - 滑块初始位置dist168drag(rect[x]rect[w]/2,rect[y]rect[h]/2,dist)五、还有几个细节决定成败1. 目标位移不要写死。缺口的 x 位置每次都变正确做法是从背景图里算取滑块图与背景图的像素差找最匹配的偏移。写死距离只能碰运气。2. iframe 里的元素要叠偏移。如果验证码在内层 iframegetBoundingClientRect()给的是相对 iframe 的坐标必须加上 iframe 本身在页面里的位置如果 iframe 跨窗口还得再叠一层。3. 结果判定要轮询不要 sleep。拖动之后是异步校验固定 sleep 3 秒既可能不够也可能浪费。正确做法for_inrange(40):ifpage.evaluate(() !!document.querySelector(.success)):returnTruetime.sleep(0.25)returnFalse4. 别信文案信状态。有些验证码失败时会保留上一次的验证成功文案或者失败态只是换了个 class。判断依据要用接口响应或DOM 状态位不要匹配验证通过这四个字。六、效果与边界这套做法在阿里云验证码 2.0、字节系拼图、百度轨迹验证上都实测通过单次拖动耗时不到 1 秒。但要说清楚边界不要用于批量刷量。本文只讨论自动化流程里必须过一次验证的场景频率控制是另一个话题。坐标标定依赖窗口布局。窗口最大化状态、显示器缩放比例变了都要重新标定一次 DPR 和视口原点。风控会升级。今天能过的轨迹明天可能不行。所以拖动逻辑要写成可替换模块别硬编码进主流程。七、自检清单遇到拖不动按这个顺序查isTrusted是 true 还是 false → 决定要不要换原生事件DPR 是不是 1 → 不是就乘上去视口原点是不是 0 → 用window.screenX拿到的 0 多半是假的位移是不是写死的 → 改成从图里算轨迹是不是一条直线 → 切段 抖动 停顿判定是不是 sleep → 改轮询六条都对上滑块基本就动了。