验证码识别服务选哪个好

做爬虫、自动化测试或批量注册流程的人，早晚会卡在验证码这一步：自研模型养不起，接第三方又怕识别率注水、延迟拖垮整条链路。这篇不讲某一家好不好，只给一套可执行的对比框架——先把自己要打的码型列清楚，再拿同一批样本去各家实测，最后对着账单和条款做决定。

做爬虫、自动化测试或者批量注册流程的人，几乎都会在验证码这一步卡住。自己训模型养不起，接第三方又怕两种坑：一是识别率注水，宣传数字和你的实际样本差一大截；二是延迟拖垮整条链路，一个请求多等几百毫秒，整个任务队列就崩。

这篇不讲哪一家最好，因为根本没有统一答案——码型不同、量级不同、合规要求不同，答案就不同。下面给一套能照着走的对比框架：先把自己要打的码盘清楚，再拿同一批样本去各家实测，最后对着账单和条款做决定。价格、成功率排名这类会变的数字，一律到站内页面去看当时的结果，别信截图和口头承诺。

先盘清你要打的是哪几种码

很多人选型第一步就错了：上来就问「哪家识别率高」，却没先数清楚自己业务里到底出现几种码。字符图形码、滑块、点选、旋转、无感验证，这几类对应的能力项完全不一样。一家图形码做得稳，不代表它能碰点选；能过点选的，未必愿意接滑块。

• 把最近一段时间业务日志里真实出现的码型列全，按出现频率排序，别凭印象
• 同一家服务对不同码型的支持深度差别可能很大，要逐类问、逐类测，而不是问一个笼统的「支持吗」
• 记录每种码型的日均量级和并发峰值，这是后面比价、比限速的输入参数
• 标出哪些码型是「必须过」、哪些是「过了更好」，资源有限时优先保证前者
• 如果某类码型占比极低，考虑人工兜底或干脆绕开，别为它拉高整体成本

把码型清单固化成一张表

接入方式：API、SDK 还是人工打码

接入方式决定了你要不要改写现有流程。纯接口返回结果最快，但遇到复杂或新变种码型时成功率会掉；人工打码兜底成功率高，代价是延迟从毫秒级变成秒级甚至分钟级。两者不是替代关系，常见做法是混合：先走接口，失败再转人工。

纯接口

程序直接提交返回结果，延迟低，适合量大的简单码型

SDK 接入

服务商提供你所用语言的封装，省掉自己写签名和重试的活

回调 / 轮询 / 长连接

结果怎么回给你，直接决定现有流程要不要改

人工打码

人来看图给答案，成功率高但延迟大，通常当兜底

混合模式

接口先试，失败自动转人工，要确认这条链路含不含在套餐里

1. 先看返回方式确认候选服务是回调、轮询还是长连接。你的业务如果是同步阻塞等结果，长连接或回调更顺；如果是任务队列，轮询就够。这一步决定改造量。
2. 再看语言封装有现成 SDK 的优先，但别只看有没有，要看你用的版本能不能装上、文档是不是最近还在维护。
3. 最后确认转人工链路混合模式要问清楚：接口失败后转人工是自动的还是你要自己判断，转人工那次算不算单独的计费。

判断标准很简单：如果接入方式逼你重构整条主流程，那它的隐性成本可能比识别费还高。什么情况下不适用——如果你的量极小、对延迟不敏感，那人工打码反而省事，不必强上接口。

识别成功率别信宣传，用你自己的样本测

所有服务商都会说自己识别率高，但那个数字大概率来自他们挑过的样本集。唯一靠谱的办法是拿你自己的真实截图去测，而且要包含最差的情况：模糊的、带干扰线的、边缘截断的、注定识别失败的。只测清晰样本，等于没测。

1. 准备样本集从业务里导出一批真实截图，按码型分类，每类都混入正常样本和困难样本。样本量够跑出稳定比例就行，太少没有参考意义。
2. 盲测同一批同一批样本发给所有候选服务，用同样的提交方式，记录每类码型的通过率，别只看一个总成功率。
3. 记录失败分布不光记「失败了多少」，还要记「失败的是哪类」。有的服务在清晰样本上很强，一遇干扰线就崩。
4. 留档并定期复测把测试样本、结果和时间记下来。服务商会迭代，准确率会变，隔一段时间要用同一批样本复测一次，看趋势。

延迟和并发：拖垮链路往往不是识别率

新手选型最容易被识别率吸引，实际把业务搞挂的常常是延迟和并发。先量出自己的延迟基线：整条流程里能留给打码这一步多少毫秒。如果整条链路预算是几百毫秒，而某个服务平均就要这个数，那它再准也不能用。

• 先测自己的容忍上限，再去看服务响应时间，顺序不能反
• 问清并发上限和限速规则：超了是排队、拒绝还是降级
• 关注超时后怎么处理，是给了失败结果还是卡住不给返回
• 高峰期表现要单独测，平均延迟好看不代表峰值不排队
• 把识别耗时纳入监控，它涨了要能第一时间看见

什么时候可以不那么在意延迟——批量离线任务、对时效没要求的场景，晚几十秒无所谓，那可以把权重更多放在成功率上。但只要是对用户可见的流程，延迟优先级应该高于识别率，因为用户等不了。

计费口径：按次、按量还是包月

比价之前先把计费口径问清楚，否则算出来的成本完全没意义。核心三个问题：失败的请求算不算钱，超时重试算几次，人工打码是不是另一个单价。这三个没问明白，后面的月度成本都是猜。

算月度成本的方法：把每种码型的日均量乘上对应单价，加上预估的失败和重试次数，再和包月套餐对比。别只看单次报价就下单，量不稳定的时候包月经常更贵。实时的各家报价和计费规则变化，到 站内价格追踪页（/price-watch） 核对当时的数字。涉及货币金额的判断，一律以你在站内看到的当期数据为准。

稳定性与兜底方案

任何第三方打码服务都会周期性抖动，这不是谁家特有的问题，而是这类服务的常态。既然抖动不可避免，方案里就必须有兜底分支，而不是假设主服务永远在线。判断一个方案健不健壮，看的是它坏掉的时候你的业务怎么活，而不是它好的时候多快。

1. 设计失败分支识别失败后是重试、换备选服务还是转人工，三条路各在什么条件下触发，要提前定好而不是临时想。
2. 准备备选服务至少留一家备选，并尽量让两家的接口字段对齐，切换时改动越小越好。
3. 做成功率监控记录成功率与耗时的趋势线，掉到阈值以下就告警，别等业务方来投诉才发现。
4. 定期演练切换备选不是摆设，隔一段时间真的切一次，确认它还能用，而不是等到出事才第一次用。

合规与数据边界不能跳过

这一段最容易被跳过，也最不该跳过。先确认你要打码的目标站点，其服务条款里是否禁止自动化访问；再看你提交的图片和识别结果里是否涉及个人信息。这两条任何一条踩线，技术方案做得再好都不值得做。

• 目标站点的服务条款要实际读一遍，别假设「大家都在爬所以没问题」
• 问清服务商是否留存你提交的图片和识别结果、留存多久、能不能关闭留存
• 确认数据传输和存储的加密方式，敏感场景要求书面说明
• 涉及用户账号或隐私内容的场景，先评估非第三方打码的替代方案
• 把合规判断的结论留档，人员变动时还能追溯当时的依据

什么情况下不适用——如果你的打码对象是自家测试环境里的模拟验证码，合规压力基本可以忽略；但只要涉及外部站点的真实用户数据，这一步就不能省。合规边界这类条款各家措辞不同，需要逐字对照，站内 中转站目录（/sites） 里整理了各家的资质与使用条款要点，可以配合核对。

一份可以直接照着走的决策清单

前面几节拆开讲的是单点判断，实际做决定时要连起来走一遍。下面这份清单按顺序执行，每一步做完再进下一步，能避免在没想清楚的情况下先签了服务。

1. 列码型与量级把码型清单和日均量级填进表格，标出必须过的和可选过的。
2. 准备真实样本按码型分类导出真实截图，包含困难样本，作为后续盲测的统一输入。
3. 实测成功率与延迟同一批样本发给候选服务，逐类记录通过率和响应时间，留档。
4. 算月度成本按计费口径估算月度消耗，配合 价格追踪页（/price-watch） 的当期数据做对比。
5. 核对合规与留存逐条确认服务条款、数据留存规则，涉及敏感场景先找替代方案。
6. 定主备与兜底确定主服务和备选服务，把失败重试、切换、转人工的触发条件写进流程。
7. 上线后持续看数每周看一次成功率和耗时趋势，数据异常就复测样本或启动切换。

速度这类感受型指标不好纸面比较，站内有现成的测速工具可以直接对不同服务的响应做横向观察，结果比口头描述靠谱。做决定前把这些数字看一遍，比反复问「哪家好」有用得多。