验证码识别失败的常见原因包括：图片URL未实时更新、缺少前置请求（如种sessionid）、未复用cookie、传入打码平台的是URL而非二进制流、pass2未用MD5加密、文件名无后缀、codetype填错、未提交pic_id、隐藏域未动态提取、服务器DNS/IP/字体/库冲突等问题。
验证码识别失败的常见原因有哪些
打码平台返回 result 为空或 ERROR，通常不是代码写错了，而是请求前没处理好前置条件。比如网页里 img 标签的 src 是相对路径、带时间戳参数未同步更新、或图片本身被 JS 动态替换过。更隐蔽的是，有些网站在加载验证码前会先种一个 sessionid 或发一次空请求，漏掉这步，打码平台拿到的就是空白图或 403 响应体。
- 确保你用的
requests.Session()复用 cookie，且在请求验证码图片前，先 GET 一次登录页或首页 - 检查图片 URL 是否含动态参数（如
timestamp=1715234890123），需实时生成并拼接 - 用
response.content保存图片二进制流后，再传给打码平台，别直接传 URL——多数平台不支持远程拉图
怎么把验证码图片发给超级鹰/打码兔这类平台
调用第三方 API 的核心是构造正确的 POST 请求体，并处理返回的 JSON。以超级鹰为例，<a href="https://www.php.cn/link/75fb85412ecc9c9f7ffaea255d37156d">https://www.php.cn/link/75fb85412ecc9c9f7ffaea255d37156d</a> 接收 multipart/form-data，关键字段是 user、pass2、softid 和 file（图片二进制）。注意 pass2 是明文密码的 MD5 32 位小写值，不是原始密码。
- 用
hashlib.md5(password.encode()).hexdigest()生成pass2 - 图片文件名必须带后缀（如
captcha.png），否则部分平台解析失败 -
codetype值不能瞎填：4004 是 4 位英文数字混合，9004 是中文，填错会导致识别率骤降 - 请求超时设为
timeout=10，避免卡死；响应状态码非 200 时，json().get('err_no')才是真实错误码
识别成功后怎么安全提交表单
拿到 result 后别直接塞进 input[name='captcha'] 提交。很多网站校验时会比对本次 session 中图片的 id（超级鹰返回的 pic_id）和用户输入，如果只传识别结果不传 pic_id，后端可能拒绝登录。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 超级鹰识别成功后返回的
pic_id必须存下来，在后续登录请求中作为额外字段提交（如captcha_id=123456789） - 若识别错误，要主动调用
<a href="https://www.php.cn/link/cd803c8ab3c2afa5430eeb195bcebe6a">https://www.php.cn/link/cd803c8ab3c2afa5430eeb195bcebe6a</a>上报错误，传pic_id和user，否则影响账号识别分 - 表单提交时，确保所有隐藏域（如
csrf_token、_token）都从上一步页面里正则或BeautifulSoup提取，不能硬编码
为什么本地测试能过，上线就频繁失败
服务器环境常被忽略的点：DNS 解析不稳定导致图片 URL 请求超时；出口 IP 被打码平台限频（尤其免费账号）；或者 Linux 系统缺少中文字体，导致截图渲染异常（影响 OCR 类平台）。还有更隐蔽的——某些平台 SDK 内部用了 urllib3，而你的项目又装了旧版 requests，引发连接池冲突。
立即学习“Python免费学习笔记（深入）”；
- 在服务器上用
curl -v "图片URL"手动测通不通，排除网络层问题 - 给打码请求加指数退避重试（最多 2 次），别一失败就抛异常
- 如果用的是打码兔，注意它要求
User-Agent必须是浏览器类型，填requests默认 UA 会被拒
验证码环节真正难的从来不是调 API，而是整个链路里任意一环的时间差、状态同步或隐式依赖没对齐。比如网页改了个 class 名，你用 BeautifulSoup 提取 token 失败，后面全白搭；或者打码平台升级了接口，但文档没更新，codetype 含义已变。留个心眼，比多写十行重试逻辑有用。
