上周帮朋友处理一批发票报销，图片提三百多张截图堆在文件夹里，文字每张都要手动敲金额和发票号。图片提干到第十七张的文字时候我停了，打开浏览器搜"图片转文字接口"。图片提这事不该这么干。文字

图片文字提取 API，图片提说白了就是文字一条 HTTP 请求的事。你丢一张图过去，图片提它返回一串文本。文字听起来简单，图片提但实际用起来，文字差距全在细节里。图片提

我试过的文字三种路子

最早用的是某云厂商的通用 OCR，免费额度每月一千次。图片提传一张发票截图上去，返回的 JSON 里文字是按行切的，但发票号码和金额混在一起，还得自己写正则去捞。准确率大概九成出头，遇到稍微模糊的图片就开始瞎猜，"0"和"O"分不清是常事。

后来换了一家专门做票据识别的接口。贵了三倍，但它返回的是结构化字段——发票代码、号码、金额、开票日期各占一个 key。省了我写解析逻辑的功夫。这个体验差异让我意识到，通用 OCR 和垂直场景 API 完全是两码事。前者给你一堆文字让你自己拼，后者直接给你拼好的结果。

还有一条路是自己部署。PaddleOCR 开源方案跑在本地，不要钱，但得有一台带显卡的机器。我拿笔记本试了试，CPU 推理一张图要两秒多，三百张就是十分钟。能接受，但维护成本摆在那里——模型更新、环境依赖、并发处理，全是活儿。

调用的时候真正要操心的几件事

图片编码方式。大部分 API 接受 base64 和 URL 两种传法。base64 适合本地文件，但图片大了请求体就膨胀，一张 4MB 的图编码后接近 5.5MB，有些网关直接给你掐了。URL 方式轻量，可你得先把图传到某个可访问的地方，多一步操作。

并发限制。免费套餐通常 QPS 卡在 1 到 2，意味着你开多线程也没用，请求排队等着。我那次三百张图，按 QPS=2 算，光传输就得两分半。付费之后提到 10 QPS，半分钟跑完。钱花在这儿了。

返回格式的坑。有的接口返回纯文本，有的返回带坐标的 JSON，有的还分段落和单行两种模式。选错了模式，表格类的图片提取出来就是一锅粥。我现在的习惯是先拿三张典型图片做测试，确认返回结构符合预期再批量跑。

价格这件事

市面上的定价大概分三档。免费额度普遍在每月 500 到 1000 次，适合个人玩玩。按量付费的话，通用 OCR 大概每千次 1 到 3 块，票据类识别每千次 5 到 15 块。包年套餐折算下来能便宜一半左右，但得预估好用量，买多了浪费。

有个细节值得说：很多厂商的"次"是按图片张数算的，不是按调用次数。一张图里如果有多个区域要识别，有些接口会拆成多次计费。签合同前把计费规则翻出来看清楚，别问我怎么知道的。

什么时候该用，什么时候不该用

批量处理、系统集成、需要稳定输出的场景，用 API 是对的。偶尔提取一两张图，直接用手机自带的文字识别功能就完了，没必要折腾。

我现在的做法是：日常零散需求走系统自带，批量任务走 API，敏感数据自己部署。三条路各管一摊，不冲突。

回到那三百张发票。最后写了个 Python 脚本，调接口跑完，人工复核了二十张，改了两个识别错的金额。前后不到一小时。比手动敲快太多了。