1. 从一次被限流的深夜调试说起凌晨两点我盯着终端里刷屏的429 Too Many Requests报错第无数次怀疑自己是不是选错了技术路线。那是一个跨境电商订单同步的小项目需求很朴素定时抓取几个平台的订单数据汇总到自己的报表里。结果刚跑通第一版脚本第二天就被目标站点的风控拦在了门外——不是封 IP而是页面直接返回一个空壳所有数据字段全是空的。后来我才搞明白问题出在 reCAPTCHA v3 上。它不像 v2 那样弹个我不是机器人的复选框让你点而是悄无声息地在后台给每一次请求打分分数低于阈值就直接判定为机器人返回的内容自然就是残缺的。这个机制最坑的地方在于它不报错它只是让你拿不到数据。你以为是选择器写错了其实是风控在背后默默给你判了刑。这篇文章想聊的就是我在 Python 环境下跟 reCAPTCHA v3 周旋这段时间攒下来的一些实战经验。核心不是教你破解——那个词本身就不准确reCAPTCHA v3 没有验证码给你破——而是讲清楚它的评分逻辑、Python 自动化工具requests、playwright在这个场景下的取舍、以及怎么通过行为模拟和环境伪装把分数维持在一个看起来像真人的区间。适合有一定 Python 基础、正在做数据采集或自动化测试、被 429 和空数据折磨过的朋友。需要提前说明的是下面所有内容都基于公开的技术原理和我在自己项目中的实践目标是让自动化脚本的行为更接近正常用户而不是对抗任何安全机制。理解这一点后面的思路才顺。2. reCAPTCHA v3 到底在评什么分2.1 它不是一个验证码而是一个持续打分系统很多人第一次接触 v3 会懵页面上什么都没有怎么就算验证了这正是 v3 的设计哲学——它把验证从一次性的交互变成了一个持续的后台评估。你在页面上的每一次鼠标移动、每一次滚动、每一次点击的间隔时间甚至你加载页面时浏览器暴露出来的一堆环境参数都会被收集起来交给后台的模型算一个 0.0 到 1.0 之间的分数。这个分数不会直接展示给你而是通过一个隐藏字段或者回调函数传给网站后端。网站自己设定一个阈值比如 0.5高于这个分数就放行低于就拒绝或者要求二次验证。所以你会看到一个很奇怪的现象同样的代码有时候能跑通有时候跑不通因为分数是浮动的它取决于你这次请求的行为特征够不够像人。理解这一点非常关键。这意味着你的对手不是一个静态的规则引擎而是一个动态的机器学习模型。你没法用一套固定的参数一劳永逸只能尽量让自己的请求在统计特征上靠近真实用户。2.2 评分模型最在意的几类信号根据公开资料和我自己反复测试的观察v3 的评分大致会参考这几类信号我按重要性排个序信号类别具体内容对分数的影响浏览器环境User-Agent、WebGL 指纹、Canvas 指纹、时区、语言、屏幕分辨率极高环境不一致直接判低分行为轨迹鼠标移动曲线、滚动速度、点击位置分布、键盘输入节奏高纯 requests 请求几乎没有这类信号请求时序页面加载到首次交互的间隔、请求之间的时间分布中高机械式等间隔请求很可疑网络特征IP 信誉、请求头顺序、TLS 指纹中数据中心 IP 天然吃亏历史行为同一会话内的访问路径、Cookie 累积中新会话冷启动分数偏低这张表是我踩了无数坑之后总结的不是官方文档。但你可以拿它当排查清单用分数上不去的时候从第一行往下逐项检查基本能定位到问题。2.3 为什么纯 requests 方案注定走不远我一开始图省事直接用 requests 加代理池硬怼。结果很惨前几十个请求还能拿到数据之后就全是空壳。原因很简单requests 发出的请求在 v3 眼里就是裸奔——没有浏览器指纹没有行为轨迹请求头顺序还是 Python 默认的那一套。这种请求在模型里的特征太明显了几乎等于举着牌子说我是脚本。那 requests 就完全不能用了吗也不是。如果你的目标站点对 v3 的依赖很轻或者你只是做低频的接口调用requests 配合合理的请求头伪装和请求间隔还是能撑一阵子的。但一旦涉及需要执行 JavaScript 才能拿到 token 的页面requests 就彻底没戏了因为 v3 的 token 是在浏览器环境里动态生成的你没法在纯 HTTP 层面复现。这就是为什么后来我转向了 playwright。它本质上是一个真实浏览器的自动化控制层能跑完整的 JS能暴露真实的浏览器指纹能模拟鼠标和键盘。代价是资源消耗大、速度慢但在这个场景下慢一点换来的是稳定这笔账划算。3. 工具选型requests 和 playwright 的边界在哪3.1 先判断你的目标站点属于哪一类不是所有带 v3 的站点都需要上 playwright。我一般会先做一个小测试用 requests 发一个请求看返回的 HTML 里关键数据字段在不在。如果在说明这个站点的 v3 校验可能只作用于某些敏感接口普通页面还是放行的那 requests 就够了。如果返回的是空壳或者跳转到一个验证页那就得上浏览器方案。还有一个更直接的判断方法打开浏览器的开发者工具看 Network 面板里有没有对https://www.google.com/recaptcha/api.js或者类似地址的请求。如果有而且页面加载后有个grecaptcha.execute的调用那基本可以确定 v3 在起作用纯 requests 方案要慎重。3.2 playwright 相比 selenium 的优势在哪我两个都用过最后留在 playwright 上主要因为几点自动等待机制playwright 的元素操作自带等待不用像 selenium 那样到处写WebDriverWait代码干净很多。网络拦截能力可以直接监听和修改页面发出的请求这在分析 v3 的 token 生成流程时特别有用。多浏览器支持一致Chromium、Firefox、WebKit 用同一套 API切换成本低。反检测做得更细默认情况下 playwright 暴露的自动化特征比 selenium 少虽然也不是完全干净但起点更高。当然 selenium 生态更成熟社区资料多如果你团队已经在用 selenium也没必要为了这个项目硬切。工具是次要的思路才是主要的。3.3 一个容易被忽略的坑playwright 的同步和异步模式热词里有个报错我印象很深playwright._impl._errors.Error: It looks like you are using Playwright Sync API inside the asyncio loop。这个坑我踩过。playwright 的 Python 版本有同步和异步两套 API同步 API 不能在 asyncio 事件循环里调用。如果你在用 FastAPI、aiohttp 这类异步框架就必须用async_playwright否则一跑就报这个错。我的建议是如果项目本身就是异步架构从一开始就用异步 API别想着混用。如果只是写个独立脚本同步 API 更省心代码可读性也好。这个选择要在动手前定下来中途换会很痛苦。4. 用 playwright 构建一个像人的会话4.1 环境准备与基础配置先把环境搭起来。Python 版本建议 3.9 以上playwright 对版本有一定要求。pip install playwright playwright install chromiumplaywright install这一步会下载浏览器内核国内网络环境下可能会慢耐心等或者配置镜像源。装完之后可以跑一个最简单的脚本验证from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.goto(https://example.com) print(page.title()) browser.close()注意这里我用了headlessFalse。调试阶段强烈建议开着浏览器窗口你能亲眼看到页面在干什么比盯着日志猜高效得多。等逻辑稳定了再切回无头模式。4.2 启动参数里的反检测细节默认启动的 Chromium 会暴露一些自动化特征比如navigator.webdriver为 true。虽然 playwright 在这方面比早期的 selenium 好但还是有一些参数值得加上browser p.chromium.launch( headlessFalse, args[ --disable-blink-featuresAutomationControlled, --no-sandbox, --disable-dev-shm-usage, ] )--disable-blink-featuresAutomationControlled这个参数能去掉一部分自动化标记。--no-sandbox和--disable-dev-shm-usage主要是解决 Linux 环境下内存不足导致的崩溃本地开发不一定需要但部署到容器里基本是标配。另外创建上下文的时候可以指定一些贴近真实用户的参数context browser.new_context( viewport{width: 1920, height: 1080}, user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ..., localezh-CN, timezone_idAsia/Shanghai, )viewport 别用默认的 1280x720那个尺寸在真实用户里占比不高。user_agent 要和你的操作系统、浏览器版本对得上别搞出一个 Windows 的 UA 配一个 Mac 的字体列表这种矛盾是风控模型最喜欢的特征。4.3 注入脚本抹掉明显的自动化痕迹光靠启动参数还不够有些属性是在页面 JS 执行时才暴露的。可以在页面加载前注入一段脚本覆盖掉这些属性context.add_init_script( Object.defineProperty(navigator, webdriver, { get: () undefined }); Object.defineProperty(navigator, plugins, { get: () [1, 2, 3, 4, 5] }); Object.defineProperty(navigator, languages, { get: () [zh-CN, zh, en] }); )这段脚本会在每个页面加载前执行把navigator.webdriver改成 undefined给 plugins 和 languages 填上合理的值。这些都是很基础的伪装但确实能骗过一部分检测。要注意的是别过度伪装比如给一个 Chrome 的 UA 却声明了一堆 Firefox 才有的插件反而弄巧成拙。4.4 模拟真实的行为轨迹环境伪装只是第一步行为轨迹才是 v3 评分的重头戏。一个真实的用户打开页面后不会立刻精准地点击某个按钮而是会先扫一眼鼠标动一动可能滚一下页面然后才去点。我一般会封装几个辅助函数import random import time def human_delay(min_sec0.5, max_sec2.0): time.sleep(random.uniform(min_sec, max_sec)) def human_scroll(page): for _ in range(random.randint(1, 3)): page.mouse.wheel(0, random.randint(200, 600)) human_delay(0.3, 0.8) def human_move_and_click(page, selector): element page.query_selector(selector) box element.bounding_box() x box[x] box[width] * random.uniform(0.3, 0.7) y box[y] box[height] * random.uniform(0.3, 0.7) page.mouse.move(x, y, stepsrandom.randint(10, 25)) human_delay(0.1, 0.3) page.mouse.click(x, y)mouse.move的steps参数很关键它决定了鼠标是瞬移过去还是分步移动过去。真实用户的鼠标轨迹是连续的steps 设大一点轨迹就更自然。点击位置也别总点正中心在元素范围内随机偏移一点更像人。这些细节单独看都很小但累积起来对分数的影响是实打实的。我做过对比测试加了行为模拟的脚本连续跑两小时的存活率比不加的高出一大截。5. 请求节奏与限流规避的实战策略5.1 429 报错的本质是节奏问题热词里429 Too Many Requests和exceeded retry limit出现频率极高说明这是大家共同的痛点。429 的本质是你在单位时间内的请求量超过了服务端的容忍阈值。这个阈值可能是按 IP 算的也可能是按会话算的还可能是按接口算的。很多人遇到 429 的第一反应是加代理换 IP这招有时候管用但治标不治本。如果你的请求节奏本身就是机械的换再多 IP 也只是把被封的时间往后推。真正要解决的是节奏问题。5.2 用随机化打破机械感机械的节奏是什么样的每隔固定时间发一个请求请求间隔方差极小。这种模式在统计上一眼就能看出来是脚本。要打破它就得引入随机性import random import time def smart_sleep(base3.0, jitter2.0): delay base random.uniform(-jitter, jitter) delay max(0.5, delay) time.sleep(delay)base 是基础间隔jitter 是抖动范围。这样每次的间隔都在一个区间内随机波动而不是固定值。更进一步可以模拟阅读时间——如果抓的是列表页点进详情页之前多停一会儿模拟用户在阅读如果抓的是详情页返回列表的间隔短一点。这种有节奏的起伏比均匀的随机更接近真实。5.3 指数退避处理 429当 429 真的发生了别硬刚。正确的做法是退避重试而且退避的时间要指数增长def request_with_backoff(func, max_retries5): for attempt in range(max_retries): try: return func() except Exception as e: if 429 in str(e): wait (2 ** attempt) random.uniform(0, 1) print(f遇到限流等待 {wait:.1f} 秒后重试) time.sleep(wait) else: raise raise Exception(重试次数耗尽)第一次等 1 秒左右第二次 2 秒第三次 4 秒以此类推。这样既给了服务端喘息的时间也避免了短时间内反复触发限流。我一般把 max_retries 设在 5 次左右再多就说明这个 IP 或者这个时段确实不适合继续跑了该换策略了。5.4 会话复用与 Cookie 管理playwright 的 context 是可以复用的。与其每次请求都新建一个 context不如在一个 context 里完成一系列操作让 Cookie 和会话状态自然累积。v3 的评分会参考会话历史一个老会话的分数通常比全新的会话高。context browser.new_context() page context.new_page() page.goto(https://target-site.com) human_delay(1, 2) human_scroll(page) # 后续操作都在这个 page 上进行如果需要在多个任务间共享登录状态可以用context.storage_state()把状态存下来下次直接加载context.storage_state(pathstate.json) # 下次 context browser.new_context(storage_statestate.json)这个技巧在需要登录的场景下特别有用省去了反复登录的麻烦也减少了触发风控的机会。6. 那些让我熬夜的报错与排查链路6.1 空数据但无报错最隐蔽的坑前面提过v3 低分时不会报错只是返回空数据。我第一次遇到的时候花了两个小时检查 CSS 选择器以为是页面结构变了。后来用page.content()把完整 HTML 打出来一看发现关键数据区域整个是空的才意识到是风控在作祟。排查这类问题的正确姿势是先确认 HTML 里有没有数据再怀疑选择器。如果 HTML 里就没有那问题在请求层面如果有但选择器取不到那才是选择器的问题。这个顺序能帮你省下大量时间。6.2 同步异步混用导致的诡异报错It looks like you are using Playwright Sync API inside the asyncio loop这个报错字面意思很清楚但实际排查起来容易绕弯。因为报错的位置往往不在你调用 playwright 的地方而是在某个异步框架的深处。我的经验是一旦看到这个报错直接全局搜索sync_playwright把所有用到的地方改成async_playwright别试图局部修补。6.3 浏览器启动失败与依赖缺失在 Linux 服务器上部署时经常遇到浏览器启动失败报一堆.so文件找不到。这是因为 Chromium 依赖一些系统库。playwright 提供了一个命令来安装这些依赖playwright install-deps chromium这个命令需要 root 权限。如果是在容器里建议直接在 Dockerfile 里跑这一步别等到运行时才发现缺库。我吃过这个亏本地跑得好好的一上服务器就崩排查了半天才发现是缺了libnss3之类的库。6.4 内存泄漏与长时间运行的稳定性playwright 跑久了会吃内存尤其是反复新建 page 和 context 的时候。如果脚本要长时间运行建议定期重启 browser 实例或者用 context 池来管理。我一般的做法是每处理完 100 个任务就重启一次 browser虽然有点粗暴但能有效避免内存涨到把机器拖垮。另外记得在 finally 块里关闭资源try: # 业务逻辑 finally: context.close() browser.close()别小看这一步很多跑着跑着就卡死的问题根源就是资源没释放。7. 关于稳定性的几点个人体会做这类自动化项目心态上要接受一个现实没有一劳永逸的方案。风控模型在更新你的策略也得跟着调整。今天能跑通的参数下个月可能就失效了。所以与其追求一个完美配置不如建立一套快速排查和调整的流程。我现在的习惯是每次脚本跑出异常数据先记录下当时的请求头、时间戳、返回内容摘要攒够一定样本后回头分析规律。很多时候问题不是突然出现的而是慢慢累积的——比如某个参数在特定时段特别容易触发风控这种规律只有靠数据积累才能发现。还有一点别把请求频率压得太极限。我知道很多人想的是能跑多快跑多快但在这个场景下慢就是快。一个每小时稳定抓 100 条的脚本比一个每分钟抓 50 条但十分钟后被封的脚本长期产出高得多。把节奏放慢把行为做真剩下的交给时间。最后分享一个我常用的小技巧在脚本里加一个健康检查环节每隔一段时间用 requests 发一个轻量请求探测目标站点的响应状态如果发现返回异常就主动暂停主任务等一段时间再恢复。这个机制帮我避免了好几次大规模的空跑省了不少电费和心情。