验证码识别失败主因是目标网站反爬机制，需动态构造请求参数、严格匹配请求头与cookie、正确上传图片及codetype，并确保验证码获取与提交间状态一致、时效合规、IP行为正常。
验证码识别失败时，requests 返回的 200 响应里却没图
很多爬虫卡在这一步：发请求拿到响应，response.status_code == 200，但 response.content 是空的、乱码、或返回了“请启用 JS”之类提示。这不是打码平台的问题，是目标网站做了反爬——比如用 JavaScript 动态生成验证码 URL，或校验 Referer/UA/cookie 是否匹配登录态。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用浏览器开发者工具（Network → Img）抓到真实验证码图片的请求 URL，注意它是否带时间戳、随机参数（如
/captcha?t=1712345678901），这类参数必须每次动态构造 - 检查请求头：
Referer必须和上一页一致，User-Agent要和你模拟登录时用的一致，且 cookie 必须包含有效的 sessionid - 如果图片地址是 base64 内嵌在 HTML 里的（比如
data:image/png;base64,...），别直接当 URL 请求，要先提取 base64 字符串再解码为 bytes
调用打码平台 API 时，post 提交的字段名和格式容易错
主流平台（如超级鹰、打码兔、云打码）都要求 POST 图片二进制数据，但字段名不统一：image、pic、file 都可能出现；有的还要额外传 codetype（如 1902 表示 4 位纯数字），漏了就直接返回“参数错误”。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
files={'image': ('captcha.png', image_bytes, 'image/png')}方式上传，别用data传 raw bytes，否则服务端收不到文件 -
codetype不是随便填的，得查平台文档对应表；例如超级鹰的1902是“4位字母数字”，而9004是“中文+英文+数字”，选错识别率断崖下跌 - 别忽略返回的
err_no字段：值为0才代表成功，-10001是账号余额不足，-10004是图片格式不支持（比如传了 WebP 却只认 PNG/JPG）
识别结果拿到后，submit 表单时被服务器拒绝
常见现象是：打码平台返回了正确字符串（比如 "Ab3x"），但 POST 登录表单时服务器返回 "验证码错误" 或 403。问题往往不在识别本身，而在「验证码和提交动作之间状态脱节」。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 验证码有生命周期，从下载到提交一般不能超过 60 秒；如果中间加了人工确认、调试断点、或识别耗时过长（某些平台平均 2~5 秒），很可能已失效
- 确保提交请求的 cookie 和获取验证码时完全一致，尤其注意
PHPSESSID、JSESSIONID等会话标识是否被 requests.Session() 自动维护住 - 有些网站把验证码 ID（如
captcha_id=abc123）藏在隐藏字段里，提交时必须一并带上，否则服务端无法关联识别结果
本地测试能过，上线后批量识别成功率暴跌
本地跑 10 次全对，部署到服务器或用代理池后，识别率掉到 30% —— 大概率是 IP 或行为特征触发了平台风控。打码平台本身会对高频、同 UA、同 IP 的识别请求限流或降权。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 每个打码账号每天有调用上限（如超级鹰免费版 100 次/天），超限后返回的
err_no是-9999，不是网络错误，别重试 - 避免短时间密集请求：两次调用间隔至少 1.5 秒，用
time.sleep(1.5)控制节奏，比加线程锁更稳妥 - 如果用代理 IP，确保代理能正常加载图片（有些代理不支持二进制传输），可先用
curl -x http://your-proxy -F "image=@captcha.png" https://api.xxx.com/invoke手动验证通路
真正麻烦的从来不是“怎么调 API”，而是验证码背后那套动态生成、绑定会话、限时校验、IP 关联的机制。漏掉其中一环，识别结果再准也没用。
