如果你只想要一个名字，综合来看，我觉得还是PaddleOCR更符合中国宝宝体质。
我先让 PaddleOCR、RapidOCR、OpenOCR、EasyOCR、Tesseract 和 macOS Vision 跑了 36 张资格赛，再留下 4 款跑完 300 张正式测试。最后答案：
- 手机实拍、店招和远处文字，选 PaddleOCR；
- 要跨平台、速度快，处理短批次图片，我会选 RapidOCR；
- 想在 Python 里找一个速度、内存和实景效果比较平衡的方案，可以看 OpenOCR。
EasyOCR 和 Tesseract 都能在本机离线运行，但这次没有通过中文质量资格赛。
测试环境： Apple M5 MacBook Air、同一批图片、同一套评分规则。
测试数据： 300 张图片
这次正式集分成六类，每类 50 张：
- 软件、网页和聊天截图；
- 票据、表单和表格；
- 商品标签、说明书和包装；
- 手机实拍与 A4 扫描模拟；
- 低对比、旋转、压缩和特殊字体；
- 外部真实场景图片。
图 1：正式集分成六类，每类 50 张；这里各展示一张代表样本。
前 250 张是自建样本。我先确定文字真值，再用固定脚本和随机种子生成图片。里面有中文小字、中英混排、日期、金额、小数点、百分号、型号、网址、阴影、模糊、透视和整页旋转。
后 50 张来自 ChineseOCRBench 的固定子集，用来补真实店招、街景和复杂背景。这个数据集给的是图片中的问题与目标答案，不是整张图片的完整转录。
所以我没有硬造一个“300 张总准确率”：
- 250 张自建图，计算全文字符错误率和全文完全正确率；
- 50 张实景图，计算目标文字是否完整出现在输出中；
- 金额、日期、型号等，再单独计算关键字段是否完整命中。
全文字符错误率，也就是表里的 CER，越低越好。¥1,280.50 少了小数点，或者把 净 识别成 凈，都会被记下来。
每款工具先预热 3 次，每张图连续运行 3 次，耗时取中位数。模型缓存完成后，我还用系统级断网沙箱重新跑了一遍，6 款都能在禁止网络访问的情况下出结果。
资格赛
资格赛由 24 张自建图片和 12 张外部实景图组成。目的是判断一款工具值不值得继续跑 300 张。
图 2：资格赛中的 12 张外部实景图及目标答案。结果如下：
| 工具 | 24 张自建图全文 CER | 12 张实景目标命中率 | P50 耗时 | 本次进程峰值内存 |
|---|---|---|---|---|
| EasyOCR | 22.07% | 8.33% | 2.059 秒 | 7727 MB |
| OpenOCR | 11.53% | 83.33% | 0.579 秒 | 828 MB |
| PaddleOCR | 7.87% | 83.33% | 4.048 秒 | 3938 MB |
| RapidOCR | 5.15% | 83.33% | 0.341 秒 | 1986 MB |
| Tesseract | 31.97% | 0% | 0.308 秒 | 119 MB |
| macOS Vision | 5.40% | 25% | 0.234 秒 | 135 MB |
Tesseract 很轻，也很成熟，但这次的中文全文字符错误率达到 31.97%，12 张实景图一个目标都没有完整命中。
EasyOCR 的结果比 Tesseract 好一些，可是依然明显落后，而且进程峰值内存反而是资格赛里最高的。它第一次自动下载模型时还碰到了证书错误，最后是手工下载官方模型并校验后才跑起来。
两款都不是“不能用”，只是放进这次中文场景里，没有必要继续消耗正式测试时间。最后进入 300 张的是 PaddleOCR、RapidOCR、OpenOCR，再加上不属于开源主榜的 macOS Vision 控制组。
正赛结果
图 3：四款工具在 300 张正式测试图片上的主榜结果。
| 工具 | 自建全文 CER | 自建全文全对 | 实景目标命中 | 关键字段正确率 | P50 | P95 | 本次进程峰值内存 |
|---|---|---|---|---|---|---|---|
| OpenOCR | 3.35% | 48.0% | 72.0% | 84.42% | 0.449 秒 | 0.587 秒 | 805 MB |
| PaddleOCR | 2.04% | 71.2% | 90.0% | 97.37% | 5.314 秒 | 9.606 秒 | 4276 MB |
| RapidOCR | 0.46% | 67.2% | 62.0% | 97.26% | 0.574 秒 | 0.751 秒 | 5201 MB |
| macOS Vision | 0.38% | 77.6% | 32.0% | 96.32% | 0.232 秒 | 0.274 秒 | 136 MB |
只在 Mac 上处理文档，我会先用 Vision
Vision 是最出乎我意料的。
在 250 张有全文真值的图片上，它的字符错误率只有 0.38%，P50 耗时 0.232 秒。逐图补测的 Swift 子进程峰值最高约 136 MB。截图、表格、扫描模拟、商品标签，甚至 90°整页，它都处理得很稳。
而且它不需要额外安装 Python 环境和模型。对“在 Mac 上给截图做搜索”“把扫描件转成文字”“在本机知识库前加一层 OCR”这些任务，它是最省事的起点。
问题也非常明确：50 张外部实景图只完整命中 16 张，也就是 32%。例如目标是“老北京铜锅涮肉”的图片，另外三款都读对了，Vision 读成了“老北京铜镀江肉”。
所以我的判断不是“Vision 最强”，而是：Mac 本地文档优先试它，远景招牌不要迷信它。
实拍店招和远处文字，PaddleOCR 明显更稳
PaddleOCR 在 50 张外部实景图里命中 45 张，达到 90%。这是这次各项结果里差距最明显的一列。
一张医院外景图，目标文字是“人民医院”。OpenOCR 读成“人民医防”，RapidOCR 读成“人民医际”，Vision 没有命中，只有 PaddleOCR 完整读对。
另一张很小的“集士港店”，PaddleOCR、OpenOCR 和 Vision 都命中了，RapidOCR 返回空白。再换到“摊摊老火锅”，结果也一样。
图 4：三张实景图的目标文字命中对照。
但 PaddleOCR 的资源消耗以及耗时比较大。P50 是 5.314 秒，P95 达到 9.606 秒；在这台无风扇的 MacBook Air 上跑 300 张，体感和另外三款完全不是一个速度。长进程峰值约 4.28 GB。
如果任务是手机拍照、街景、店招，或者“宁愿慢一点，也不要漏掉远处目标”，我会选 PaddleOCR。
如果是处理大量规则文档和截图，不一定值得付这个时间。
RapidOCR 很快，不过资源回收好像有问题
RapidOCR 在自建图上的全文字符错误率是 0.46%，P50 0.574 秒，关键字段正确率 97.26%。对截图、表格、扫描模拟和旋转页来说，它很接近 Vision，又保留了 Python、ONNX 和跨平台部署的便利。
如果只看前一半数据，我原本会把它列为最均衡的开源选择。
真正的问题在长进程里出现了。
主榜每张跑 3 次，连续处理 300 张时，记录到的进程峰值达到 5.20 GB。为了排除“峰值统计只是记住了过去”的可能，我又让它单进程跑了一遍，每张只识别一次，并记录当前 RSS。结果从开始时约 564 MB，一路增长到约 3.30 GB。
我又把 300 张按类别拆成 6 个独立进程，每段 50 张。重启确实消除了前一段的累积，但最后 50 张复杂实景内部仍然涨到了约 3.13 GB。
所以这里不能偷懒写成“每 50 张重启一次就解决了”。更可靠的做法是：
- 把它用于短批次；
- 生产服务限制 worker 生命周期；
- 持续监控 RSS，达到阈值就回收进程；
- 如果主要处理实景照片，先拿自己的图片再做一次小样本验证。
RapidOCR 仍然是我会选的跨平台快速方案，只是这个内存边界必须跟推荐一起说。
OpenOCR没什么特别出彩的
OpenOCR 的 P50 是 0.449 秒，进程峰值约 805 MB，外部实景命中 72%。
它没有 Vision 那么省资源，没有 PaddleOCR 的实景命中率，也没有 RapidOCR 在自建图上的低错误率。反过来看，它在速度、实景和内存之间比较平衡，安装也比我预想得顺。
需要注意两点。
第一，它在这批自建图上的全文字符错误率是 3.35%，关键字段正确率 84.42%，金额符号和标点变体会吃掉不少严格分。第二，默认日志非常详细，300 张正式测试的日志接近 2 MB。真做成服务时，最好先把日志级别收一下。
如果你要的是一个 Python 方案，又不想承受 PaddleOCR 的耗时，OpenOCR 值得和 RapidOCR 一起拿自己的数据试。
小插曲
正式主榜里，我把 PaddleOCR 的文档方向分类、文档矫正和文字行方向分类都关了，保持基础 OCR 管线。结果 5 张 90°整页的字符错误率都在 85% 以上，几乎不可用。
这到底是模型能力不行，还是配置没开？
我单独开启官方方向模块，只补测这 5 张。结果全部降到 0 字符错误，单张耗时在 7.01—7.34 秒之间。
这个补测不能偷偷并入主榜，因为我没有用同一配置重跑全部 300 张。它真正说明的是：
- 需要处理手机横拍、扫描歪页，就开启方向模块；
- 输入方向本来就稳定，可以关掉它换速度和更少的模型；
- 比较 OCR 时，必须把“基础配置”和“增强配置”写清楚，否则同一款工具可以被写成两个完全不同的故事。
把旋转页、远景小字、空输出和错字放在一起看，四款工具各自的边界会更直观：
图 5：旋转、漏检与误识别等代表性失败样本。
如果现在让我直接选，我会这样装
只在 Mac 上用：先调系统 Vision。它对文档、截图和扫描件足够准，也最轻。
跨平台、短批次：先试 RapidOCR。速度和自建文档质量都好，但服务端要控制进程寿命。
实景照片优先：选 PaddleOCR。它在这次外部图片上的优势不是一点点，只是要接受更长耗时。
想找中间路线：把 OpenOCR 加入自己的小样本测试。它没有一列最亮眼，却可能是更容易接受的折中。
至于 Tesseract 和 EasyOCR，中文识别拉完了。
强调一下：不包含 PDF 阅读顺序、表格结构恢复和公式解析。换机器、换图片分布，答案可能变化。
以上就是这次的侦察。
如果对你有用，顺手点个赞 +「♥️」。
想第一时间收到前线情报，关注「硅基斥候S01」。我们，下次侦察见。
