OCR 是个不性感的活儿。当所有人都在追 LLM agent、追多模态生成的时候，还有一群人在跟扫描件、PDF、票据、古籍死磕。但只要你做过一次"把 200 页合同喂给大模型"的尝试，就会明白：OCR 没死，它只是从台前退到了幕后，变成了整条数据管道里最不起眼、却最容易翻车的那一环。
2026 年，OCR 工具的格局比你想的清晰。老牌劲旅 Tesseract 依然在跑，PaddleOCR 已经把星数拉到八万级别，百度新掏出来的 Unlimited-OCR 直接喊出"一次性长程解析"的口号。三款工具，三种哲学，解决的根本不是同一个问题。这篇横评不搞排名，只帮你搞清楚一件事：你的场景，到底该用谁。
一个值得注意的趋势是：大模型把文档理解的门槛砸低了，反而把 OCR 的价值抬高了。原因很简单--LLM 再聪明，喂进去的如果是乱码，出来的也是幻觉。OCR 是大模型吃数据之前的"咀嚼"环节，嚼不好，后面全白费。所以 2026 年选 OCR，不再是选"谁的识别率高"，而是选"谁吐出来的东西能被下游直接用"。
先把话说在前面：以下 star 数据来自 GitHub API，截至 2026-07-29，实时变动。文中涉及的性能与定位对比为代表性对比，非亲自压测——我梳理的是公开信息与官方描述的差异，不是我在同一台机器上跑的 benchmark。你要是真要上线，自己测一遍永远是第一原则。
一、三款工具的真实画像：谁在解决什么问题
PaddlePaddle/PaddleOCR——86469 星，Python，Apache-2.0
官方一句话定位：强大轻量的 OCR 工具包，把 PDF/图片转结构化数据对接 LLM，支持 100+ 语言。关键词是"工具包"和"对接 LLM"。它不是给你识别一张验证码用的，它的野心是成为文档智能化的前置引擎——你扔进去一份扫描合同，它吐出来的不是一堆乱码文本，而是结构化字段，直接喂给下游大模型做信息抽取。最近一次 push 在 2026-07-22，活跃度没问题。底层依赖飞桨（PaddlePaddle）框架，这是它唯一的"重"——你得装一套飞桨，不是随便 pip install 就完事。
tesseract-ocr/tesseract——75617 星，C++，Apache-2.0
经典开源 OCR 引擎，没有之一。它从惠普实验室一路活到了今天，比你认识的大多数程序员年纪都大。C++ 写的，性能硬核，但"硬核"的另一面是"难搞"——你不是装个 Python 包就完事，你得编译，得配 traineddata 语言包，得跟各种 binding（pytesseract、Tesseract.NET）打交道。它的定位是"引擎"，不是"解决方案"。你买的是一台发动机，至于装到什么车上、怎么调教，全看你自己的工程能力。
baidu/Unlimited-OCR——20124 星，Python，MIT，2026-06-18 建
这是三款里最年轻、最野的一个。仓库 6 月才建，一个月干到两万星，说明踩中了真痛点。它的口号很直白："Unlimited OCR Works: 一次长程解析时代"。翻译成人话就是：别的 OCR 遇到长文档要么切片、要么丢页、要么直接崩，它想一次性把一份超长文档吃进去、解析完。MIT 许可，最宽松，商用几乎没有顾虑。但要注意它太新了——文档、生态、踩坑总结都还稀薄，你得做好当早期用户的准备。
二、一张表看懂差异
把三款工具的核心维度拉成一张表。再看一遍提醒：star 数截至 2026-07-29，实时变动；性能描述为代表性对比，非亲自压测。
| 维度 | PaddleOCR | Tesseract | Unlimited-OCR |
|---|---|---|---|
| GitHub Stars | 86,469 | 75,617 | 20,124 |
| 主语言 | Python | C++ | Python |
| 许可证 | Apache-2.0 | Apache-2.0 | MIT |
| 最近活跃 | 2026-07-22 push | 持续活跃 | 2026-06-18 建，活跃 |
| 定位 | 多语言工具包，对接 LLM | 经典 OCR 引擎 | 长文档一次性解析 |
| 语言覆盖 | 100+ 语言 | 多语言（依赖 traineddata 包，精度因语言而异） | 主打长文档解析 |
| 部署难度 | 中（需装飞桨框架） | 中高（C++ 编译 + 语言包 + binding） | 低-中（Python，但生态新） |
| 核心优势 | 结构化输出、LLM 友好 | 极致稳定、嵌入式友好 | 超长文档不切片一次吃完 |
| 适合人群 | 做文档智能化、RAG 管线的 | 嵌入式/离线/追求极致掌控的 | 票据、合同、长报告批量处理的 |
这张表不是让你"谁星多选谁"。星数只说明社区关注度，不代表它适合你的场景。Tesseract 星比 PaddleOCR 少一万，但如果你做的是嵌入式设备上的离线 OCR，PaddleOCR 再火也帮不了你——飞桨那套依赖你塞不进边缘设备。
三、按场景对号入座：别选最强的，选最对的
场景一：多语言 + 对接 LLM → PaddleOCR
如果你在做 RAG 系统、文档问答、知识库搭建，需要把扫描件/PDF 转成结构化文本再喂给大模型——PaddleOCR 是目前最顺手的选择。原因就两个：一是它原生支持 100+ 语言，你不用自己折腾语言包；二是它的输出设计就是冲着"对接下游"去的，布局还原、表格识别、版面分析这些功能它都内置，省掉你一堆后处理。
实操上注意一点：PaddleOCR 的 100+ 语言不等于 100+ 语言都准。中英文是主力调优对象，小语种的精度会有落差。上线前一定要用你的真实数据跑一遍准确率，别被"支持 100+ 语言"的数字忽悠了。另外它依赖飞桨，部署环境比纯 pip 包重，Docker 镜像体积做好心理准备。
场景二：经典稳定 / 嵌入式 → Tesseract
Tesseract 的价值在两个极端场景：一是你需要在资源受限的设备上跑 OCR（树莓派、工控机、离线盒子），二是你需要一个"已经跑了几十年、bug 基本被踩完"的东西。C++ 引擎的性能上限和稳定性，是 Python 系工具比不了的。它也是很多商业 OCR 服务的底层引擎，可靠程度经过验证。
但代价是工程成本。你得处理编译、语言包加载、binding 适配这一堆事。如果你团队没有 C++ 能力，或者你的需求只是"快速搭个文档识别 demo"，Tesseract 会把你拖进环境配置地狱。它的输出是纯文本流，版面还原、表格结构这些你得自己写后处理。选它之前问自己一句：你是要发动机，还是要整车？要整车，看看别的。
场景三：超长文档一次性解析 → Unlimited-OCR
这是 Unlimited-OCR 最锐利的差异化。传统 OCR 遇到 100 页的 PDF，标准操作是切片——按页拆开，逐页识别，再拼回去。切片策略本身就是坑：表格被切两半、跨页引用断裂、页眉页脚干扰。Unlimited-OCR 的思路是"别切了，一次吃完"，这对票据、合同、长报告这类需要全局上下文的文档很实用。
但请带着清醒的预期上船。这个仓库 2026 年 6 月才建，到我现在写这篇文章才一个多月。两万星说明需求真实，但也意味着：文档可能不全，边界 case 没人替你踩过，生产环境的稳定性数据几乎没有。我的建议是先在非关键链路上试跑，攒够了真实数据再决定要不要上生产。MIT 许可很友好，但"许可友好"不等于"工程成熟"。
四、选型建议与避坑指南
把三个工具放一起，我的选型逻辑其实就三句话：要 LLM 对接和多语言，PaddleOCR；要极致稳定和嵌入式，Tesseract；要一次性啃长文档，Unlimited-OCR。但有几个坑，不管你选哪个都得知道。
坑一：语言精度差异。 任何 OCR 工具的"支持 N 种语言"都是个统计数字，不代表每种语言都好用。中文、英文是所有工具的舒适区，阿拉伯语、东南亚小语种、手写体，精度会断崖式下跌。永远用你的真实业务数据做准确率测试，别信 README 里的 demo。
坑二：长文档性能。 "支持长文档"和"长文档跑得快跑得稳"是两回事。一次性解析 200 页文档，对内存和显存的压力跟逐页处理完全不同。Unlimited-OCR 虽然主打长文档，但具体多长、多少资源，你得自己量。PaddleOCR 和 Tesseract 如果硬塞长文档，也会有各自的性能拐点。代表性对比能告诉你方向，具体数字请自己压测。
坑三：许可证。 Apache-2.0 和 MIT 都是宽松许可，商用基本没问题。但 Apache-2.0 带专利授权条款，MIT 没有——如果你所在行业对专利条款敏感（比如有些大厂的法务对 Apache 的专利条款有特殊要求），法务那关提前过一下。另外 OCR 模型本身可能用了第三方训练数据，数据来源的合规性是另一层问题，这点任何工具都逃不掉。
坑四：别把 OCR 当终点。 很多人选完 OCR 工具就以为文档数字化搞定了。OCR 只是第一步——识别完的文字还要清洗、结构化、校对、对接下游。选 OCR 工具时，要看它输出的结构化程度：PaddleOCR 给你版面分析和表格结构，Tesseract 给你纯文本流，Unlimited-OCR 给你长文档整体解析。输出的结构化程度，直接决定你后处理工作量的大小。
坑五：版本和模型权重的坑。 OCR 工具的版本迭代比你想的频繁。PaddleOCR 从 PP-OCR 到 PP-OCRv4，每一代模型权重和接口都有变化，升级时容易踩到不兼容的坑。Tesseract 也有 4.x 和 5.x 大版本差异，LSTM 引擎和传统引擎行为不一样。Unlimited-OCR 作为新项目，接口变更频率可能更高。建议锁版本部署，别用 latest 标签，升级前在测试环境验证一遍。
五、备选方案与我的判断
上面三款不是全部。如果你还想多看几个，可以关注 Surya（多语言文档 OCR，支持版面分析和阅读顺序）和 docling（把文档解析为结构化输出，对表格和公式友好）——但本文不展开它们的数据，你感兴趣自己去看仓库。选型这件事，工具多不是好事，容易让你陷入"再看看"的拖延。先定场景，再用场景去卡工具，这是最快路径。
我的判断是：2026 年 OCR 工具的竞争焦点已经从"识别率"转移到了"结构化能力"和"长文档处理能力"。单纯比识别准确率的时代过去了——大家都能把印刷体识别到 95% 以上，差距在版面还原、表格结构、长文档上下文这些难啃的硬骨头。PaddleOCR 押注结构化 + LLM 对接，Tesseract 守着嵌入式和稳定性基本盘，Unlimited-OCR 直接打长文档一次性解析。三条路线，谁也没法通吃。
所以回到开头的问题：PaddleOCR、Tesseract、Unlimited-OCR 怎么选？别问哪个最好，问你的文档是什么、你要喂给谁、你跑在什么环境。答案其实早就写在你的场景里。
参考来源
- PaddlePaddle/PaddleOCR：https://github.com/PaddlePaddle/PaddleOCR
- tesseract-ocr/tesseract：https://github.com/tesseract-ocr/tesseract
- baidu/Unlimited-OCR：https://github.com/baidu/Unlimited-OCR