企业官网建设流程全解析

简介：这是为 C# WinForm 开发者准备的 Tesseract OCR 集成演示工程，基于 Visual Studio 2019 与 .NET Framework 4.7.2 环境，适合需要为桌面软件增加图片文字识别功能的开发者，无论工具类程序还是业务系统都可借鉴，对刚接触 OCR 的开发者尤其友好。工程演示了从加载图片、配置 OCR 参数到识别并显示文字的核心流程，代码结构清晰，可直接打开运行学习。压缩包共 21 个文件，约 32.16MB，包含 6 个 C# 源文件、5 个 DLL 依赖库、1 个 traineddata 语言模型，以及 config、resx、解决方案等配套文件，其中 2 个 resx 资源文件辅助界面显示，2 个配置文件承载初始参数，DLL 与语言模型都可以直接复用到自有项目中，省去自行编译与下载依赖的麻烦。目前已有 522 人学习该演示项目，压缩包内还附带可直接运行的 exe，便于先体验再改代码。总体来看，这份代码不仅演示了 WinForm 下 Tesseract OCR 的封装与调用，还提供了可迁移的基础代码和运行库，能帮助开发者缩短集成周期，更快落地 OCR 功能。

1. 先把这个标题翻译成人话：C# WinForms 里的 Tesseract 能救什么急

很多第一次搜 C# winform tesseract-ocr 演示代码的人，都是被同一个任务逼来的：客户丢来一堆截图和扫描件，说“把字读出来存进表里”，而你手里只有一个 WinForms 桌面程序，没有服务器，也不想为一小撮图片单独部署识别服务。这个标题就是在回答这件事：在本地调用 Tesseract OCR 引擎，把图片里的印刷体文字提取成字符串。它的价值是零授权成本、离线可用、集成路径短，特别适合内部工具、上位机小助手和批量归档；适合人群也很明确——数据量不大、以“能读出来”为底线、想先跑通再谈优化的人。建议你先别纠结原理，按第二章把最小工程跑起来，拿一张票据实测，再判断它接不接得住业务。

2. 为什么是 Tesseract 而不是 PaddleOCR 或 Windows 自带 OCR：三个方案先掰开

2.1 三个方案的定位差异：成本、部署形态、中文效果

在动手写代码之前，先把这个选型问题说清楚，因为后面所有代码都押在这里。对 WinForms 桌面程序来说，OCR 无非三条路：Windows.Media.Ocr 是 Windows 10/11 自带的，不用装第三方库，但它是 UWP 风格的 API，在 WinForms 里要包一层桥接，中文识别依赖系统语言包，可控性很差；PaddleOCR 的中文识别准确率最好，但它是 Python 生态，C# 端要么包一个本机 HTTP 服务，要么走 gRPC，部署体积和依赖复杂度都上了一个台阶；Tesseract 是 GPL 协议的开源引擎，C# 侧有现成 NuGet 封装，引擎和语言包都是本地文件，进程内调用，最契合桌面工具这种“小、快、本地”的形态。

三者对比，Tesseract 的核心优势不是准确率，而是嵌入成本。准确率上 PaddleOCR 在中文场景通常领先一截，Windows.Media.Ocr 在清晰英文文档上也不错；但 Tesseract 是唯一能让 C# 程序员在十分钟内跑通“选图 → 出字”的路线。这就是为什么大量 winform 项目案例里的 OCR 需求还是选择它：很多上位机工具要的只是把条码下方那串数字、单据里的编号、界面截图上的提示文字读出来，准确率 90% 和 99% 的差距，远小于“是否能在客户现场离线跑起来”的影响。

我在给现场做 C# 上位机读屏这类小工具时，判断标准很简单：文字是印刷体、背景不过分脏、字数少，优先 Tesseract；如果是票据混合排版、手机拍摄的倾斜照片、或者需要识别中文手写，直接劝退，换 PaddleOCR 更靠谱。你自己评估时，把“部署环境能不能装 Python、客户机器有没有外网、识别一张图能等几秒钟”这三个问题先写在纸上，答案基本就出来了。

一个快速参照表，按我的经验给分（纯主观，不构成 benchmark）：

这个表不值得你当作权威结论，但它反映了我在多个小项目里的体感：只有当你明确知道“这个场景 PaddleOCR 的优势能转化成实际收益”时，才值得为它搭服务；否则先跑 Tesseract。

另外多说一句：如果你不是 WinForms 而是 WPF 或 .NET MAUI，这个选型结论同样成立。Tesseract 的 C# 封装只依赖 System.Drawing 和平台无关的图像处理，换 UI 框架时只需要替换文件选择和结果显示部分，引擎初始化与识别代码可以直接搬。很多人问“winform、wpf、.net maui 该怎么选 OCR 方案”，我的回答都是同一句：先按演示代码跑通 Tesseract，需要更强效果时再升级方案，没必要一开始就上重武器。

2.2 Tesseract 的识别流程：二值化、版面分析、LSTM 识别

Tesseract 不是魔法，它内部是一条固定流水线。了解这条线，后面调参才有方向，不然拿到乱码只能瞎试。大致流程是：输入图像先做灰度化和二值化，把彩色图变成黑白像素图；然后做版面分析，尝试把页面划分成文本块、行、单词；接着做字符切分，把每个单词切成候选字符；最后把字符图像交给模型匹配。自 4.x 起，引擎核心换成了基于 LSTM 的神经网络模型，识别能力比 3.x 时代强了不少，但对输入图像的整洁度要求并没有降低。

这条流水线解释了三个常见的反直觉现象。第一，因为要先做二值化，所以背景复杂、光照不均的图，Tesseract 会把阴影当成前景，识别率直接下降，外部预处理往往比调引擎参数更有效。第二，因为版面分析会对整页做结构假设，识别一张只有一行数字的截图时，默认的自动分页模式会浪费大量时间做无意义的切分，设置 PageSegMode 为单行通常能立刻改善。第三，LSTM 模型对字符大小和形状敏感，过小的字和过大导致轮廓发虚的字效果都不好，所以缩放要控制在一个合理区间，我一般以宽边 2000 到 3000 像素为上限。

还要理解“语言包”是什么。Tesseract 的模型不是写死在 exe 里的，而是存放在 .traineddata 文件中。tessdata 目录里放哪些语言包，决定了引擎能认哪些文字。中英混排时可以用“chi_sim+eng”的方式同时加载两个语言包，引擎会在识别时对两者做综合推断。这个机制是 Tesseract 易用也易错的地方：语言包目录路径写不对、文件名写错，初始化阶段就会直接失败，而且报错信息往往不那么直白，第三章我们会单独处理这个坑。引擎模式上，EngineMode.Default 是推荐选择，它会优先用 LSTM 引擎，遇到问题时回退到 legacy 引擎；LstmOnly 更纯粹但兼容性略差，LegacyOnly 则保留旧引擎行为，只在特殊排查时用。

2.3 什么时候不应该用 Tesseract

这里把丑话放在前面。九十度的旋转、透视畸变的随手拍、模糊到人眼都费劲的截图、彩色花字、中文手写体——这五类场景 Tesseract 基本都会翻车，不是调参能救的，调参只是把“完全不可用”变成“偶尔不可用”。尤其是中文，chi_sim 语言包对标准印刷体的识别还不错，遇到字体稍微花哨或者图片带水印底纹，错误率会显著上升。

还有一种常见误用是拿它去读仪表盘上的数字。很多 winform 工业场景里，仪表数字是七段数码管或带反光的表盘，Tesseract 的字符模型对这种字形假设是普通印刷体，识别结果极不稳定。真要读仪表，优先考虑形态学识别或专门的小模型，别往 OCR 这条路上硬靠。判断标准其实很简单：你把图交给一个不认识这个项目的普通人，他能一眼读出来吗？如果能，Tesseract 有机会；如果他也得仔细辨认，那问题不在引擎，在于你的输入成像质量太差。这种情况下，正确的做法是回到图像采集端——提高分辨率、固定拍摄角度、增加光照，而不是在 OCR 参数里找后悔药。我在一个读设备铭牌的项目里就是这么干的：把摄像头从手持改成固定支架拍摄，识别率从惨不忍睹直接跳到可接受，改动成本比调任何参数都低。

3. 搭一个最小可运行的 WinForms OCR 工程：从 NuGet 包到第一张图出文字

3.1 创建工程并安装 NuGet 包：新旧版本 API 完全不同

老帖子里搜到的 Tesseract C# 代码基本都是 3.x 时代的绑定，构造函数、命名空间、方法名都和现在不一样，直接抄会编译不过。我这里按当前 NuGet 主流的“Tesseract”包写法来，它封装的是 4.x/5.x 引擎。创建工程和安装包：

dotnet new winforms -n OcrDemo cd OcrDemo dotnet add package Tesseract

如果用的是 Visual Studio 创建的项目，在“管理 NuGet 程序包”里搜 Tesseract，认准那个命名空间为 Tesseract、依赖 Leptonica 的包即可。装完后可以用一个简单输出验证封装是否完整：

using Tesseract; string tessDataPath = Path.Combine(AppContext.BaseDirectory, "tessdata"); Console.WriteLine(TesseractEngine.Version);

注意这里有个版本陷阱：早年间有个老绑定包，API 初始化参数和现在完全不一样，很多博客的代码基于它。如果你照着博客抄发现 Pix 类型不存在，多半是装错了包。删除后重新装新版即可，不要纠结改代码兼容老包，时间不值得花在这个上面。

3.2 准备 tessdata 语言包：路径和复制策略

引擎需要一个 tessdata 目录。目录内至少要有一个语言包，常见的是英文 eng.traineddata；要识别中文就再放 chi_sim.traineddata。这两个文件都要单独下载，不会随 NuGet 包一起带。下载后建立如下目录结构，并把 tessdata 的“复制到输出目录”属性设为“如果较新则复制”：

OcrDemo/ └── tessdata/ ├── eng.traineddata └── chi_sim.traineddata

如果你用命令行，可以在 csproj 里加这一段：

<ItemGroup> <None Include="tessdata\**\*" CopyToOutputDirectory="PreserveNewest" /> </ItemGroup>

这段配置确保 F5 调试时 tessdata 会被复制到 bin\Debug 之类的工作目录下。不这么做的话，代码里写相对路径 tessdata 经常会解析失败，因为工作目录未必是项目根目录。用 AppContext.BaseDirectory 拼绝对路径，再把语言包放进输出目录，是最省心的组合，能避开一类常见的路径问题。

提示：所有会被真实用户机器使用的 WinForms 程序，我都不建议依赖相对路径来定位 tessdata。要么按上面方式复制到输出目录，要么在安装阶段把 tessdata 放到程序的固定安装目录，然后用 Path.Combine(AppContext.BaseDirectory, "tessdata") 去拼。

3.3 初始化引擎并写第一段识别代码

现在写核心代码。先在窗体上放一个按钮、一个 PictureBox、一个多行 TextBox，事件处理如下：

using Tesseract; private async void btnRecognize_Click(object sender, EventArgs e) { using var ofd = new OpenFileDialog(); ofd.Filter = "图片文件|*.png;*.jpg;*.jpeg;*.bmp"; if (ofd.ShowDialog() != DialogResult.OK) return; // 识别放后台线程，避免 UI 冻结数秒 var result = await Task.Run(() => { string tessDataPath = Path.Combine(AppContext.BaseDirectory, "tessdata"); string imagePath = ofd.FileName; // 引擎实例每次识别重建，避免跨线程共享状态 using var engine = new TesseractEngine(tessDataPath, "chi_sim+eng", EngineMode.Default); using var pix = Pix.LoadFromFile(imagePath); using var page = engine.Process(pix); return new { Text = page.GetText(), Confidence = page.GetMeanConfidence() }; }); pictureBox1.Image = new Bitmap(ofd.FileName); textBox1.Text = result.Text; labelStatus.Text = $"置信度：{result.Confidence:P1}"; }

这段代码作用很直白：点击按钮后弹出文件选择框，把选中图片路径传给 Pix.LoadFromFile，读取成 Leptonica 内部图像格式 Pix，再交给 engine.Process 识别。Process 返回一个 Page 对象，里面有识别文字和置信度，最后把结果显示到控件上。

这里有三个参数需要你根据场景调整：

• 语言包字符串 "chi_sim+eng"：表示同时加载简体中文和英文。如果只识别英文数字，改成 "eng" 可以降低一次加载成本；只识别中文改成 "chi_sim" 即可。加载额外语言包会增加每次初始化的耗时，演示程序无所谓，高频场景要留意。
• EngineMode.Default：引擎自动选择 LSTM 优先级，排障时才会改用 LstmOnly 或 LegacyOnly。
• ofd.Filter：限制可选文件类型，避免把非图片路径传进来导致 Pix.LoadFromFile 抛异常。

你可能注意到我直接用文件路径，而不是把 Bitmap 转成 Pix 再传。原因之一是简单，原因之二是绕开一个常见坑：PixConverter.ToPix(bitmap) 在某些 WinForms 高 DPI 设置下拿到的 Pix 的 DPI 信息和实际不符，而直接 LoadFromFile 会从文件头读取 DPI 元数据。第四章会展开讲 DPI 对识别率的影响。如果你手里的图片本来就在 Bitmap 对象里（比如来自摄像头抓帧），那就用 PixConverter.ToPix(bitmap)，但传之前最好显式给 Bitmap 设置一个合理的 DPI。

3.4 一个容易被忽略的细节：图片路径里的中文

当图片路径或文件名包含中文时，Pix.LoadFromFile 在部分封装版本里会报“找不到文件”或直接返回空页，这不是你代码的问题，而是 Leptonica 原生层对非 ASCII 路径支持不稳定。解决方法是先把图片复制到一个纯英文临时路径，或改用 Bitmap + PixConverter.ToPix 的路线。我在业务工具里一般做一步保底：

string safePath = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString("N") + ".png"); File.Copy(ofd.FileName, safePath, true); using var pix = Pix.LoadFromFile(safePath);

多花一次文件复制，换来确定性，对工具型程序来说值得。这个现象不是必然出现，但一旦出现很难排查，所以我把它当成固定写法。第三章这套组合拳打完，你已经能“把图变成字”了。接下来要解决的是：字出来了，但识别得不对怎么办。

4. PageSegMode、白名单与图像预处理：把识别率从 60% 拉到 90%

4.1 首选预处理：灰度、缩放、降噪

Tesseract 对“干净的图像”依赖程度很高，跑演示代码能出字，但真实截图往往带背景色、阴影、缩放失真。我的标准预处理顺序是：彩色图转灰度 → 按宽边缩放到 2000 像素左右 → 再做一次简单降噪。灰度转换用 System.Drawing 的 ColorMatrix 一次性完成，性能比逐像素操作好一截：

using System.Drawing.Imaging; public static Bitmap ToGrayScale(Bitmap src) { var result = new Bitmap(src.Width, src.Height); var matrix = new ColorMatrix(new[] { new float[] { 0.299f, 0.587f, 0.114f, 0, 0 }, new float[] { 0.299f, 0.587f, 0.114f, 0, 0 }, new float[] { 0.299f, 0.587f, 0.114f, 0, 0 }, new float[] { 0, 0, 0, 1, 0 }, new float[] { 0, 0, 0, 0, 1 } }); using var attrs = new ImageAttributes(); attrs.SetColorMatrix(matrix); using var g = Graphics.FromImage(result); g.DrawImage(src, new Rectangle(0, 0, src.Width, src.Height), 0, 0, src.Width, src.Height, GraphicsUnit.Pixel, attrs); return result; } public static Bitmap ScaleToMaxWidth(Bitmap src, int maxWidth = 2400) { if (src.Width <= maxWidth) return src; int height = (int)(src.Height * (double)maxWidth / src.Width); return new Bitmap(src, maxWidth, height); }

灰度矩阵的三个通道取同样的亮度系数，作用是丢掉颜色信息，让后续二值化不再受色相干扰；中间三行都一样，所以最终图像就是标准灰度图。ScaleToMaxWidth 控制宽边，因为 LSTM 对字符尺寸有一个舒适区间，过大的图反而会被内部二次缩放搞乱。然后识别前把 Bitmap 转成 Pix 再交给引擎：

using var processedBitmap = ScaleToMaxWidth(ToGrayScale(new Bitmap(ofd.FileName))); using var pix = PixConverter.ToPix(processedBitmap); using var page = engine.Process(pix);

这里有一个取舍：转灰度是“花钱”换稳定，在彩色底纹截图上收益明显，在纯白黑扫描件上收益为零。你的图越干净，预处理越轻；图越脏，预处理越重，不要为了预处理而预处理。

4.2 PageSegMode：识别结果形态的总开关

识别一张图，首先要回答“这张图里是什么结构”。默认的 PageSegMode.Auto 适合整页文档，但不适合一行数字、一个代码块、一句按钮文字。模式选错了，Tesseract 会花大量时间去猜测页面结构，然后输出一堆带换行和空格的无意义片段。engine.Process 可以显式传 PageSegMode：

using var page = engine.Process(pix, PageSegMode.SingleLine);

平时我基本只用四种模式：

选模式的判断方法是：先看图片里文字呈什么形态。只有一行，用 SingleLine；一段文字，用 SingleBlock；一整页，用 Auto；不知道但文字零散，用 SparseText。SingleLine 对一行数字或字母的识别提升非常明显，很多“识别乱码”的案例，实际上只是模式没选对。

4.3 DPI 是识别率的分水岭：一张图可能只有 96 DPI

Tesseract 分割字符时，会用图像 DPI 信息估算字符实际物理尺寸。WinForms 里从屏幕截图保存下来的 PNG，DPI 元数据往往只有 96 或 72，而 Tesseract 期望的输入是 300 DPI 左右的文档级图像。DPI 不对时，同一个字符在不同位置的切分结果会漂移，表现出来就是“有些字对、有些字错，同一张图每次结果还可能不同”。

解决方式有两个。一是预处理时给 Bitmap 盖上正确的 DPI：

processedBitmap.SetResolution(300, 300);

二是如果不想改图，可以给引擎设置 user_defined_dpi：

engine.SetVariable("user_defined_dpi", "300");

注意这是字符串参数，要加引号。这个参数的作用是告诉引擎“忽略图像自带 DPI，按 300 处理”。我建议两者都用：图像本身设置 300，引擎兜底再设一次。实测下来，很多只差几个字符识别错误的情况，把 DPI 理顺之后就不治而愈了。

4.4 白名单、黑名单与纯数字场景

如果业务场景明确知道“只认数字或字母”，就一定要用白名单把无关字符挡出去。Tesseract 内部有几百个字符类别，不限制时它会把 l、1、I 互相猜，把括号、竖线也当成候选。设置白名单后，搜索空间收紧，对置信度也有正向影响：

engine.SetVariable("tessedit_char_whitelist", "0123456789.-");

设置之后，识别一行“编号：A-001”会只输出数字、小数点、连字符。这里有个需要知道的边界：tessedit_char_whitelist 在 EngineMode.Default 下效果有限，因为它主要约束 legacy 引擎；在 LstmOnly 模式下，白名单未必生效。我验证过多次，结论是：如果白名单设了但输出里仍有杂字符，改用 EngineMode.Default，或多加一层过滤——用正则把非法字符剥掉：

string clean = Regex.Replace(rawText, "[^0-9.-]", "");

这个正则过滤看起来土，但它确定有效，适合作为演示代码里的保底手段。

5. 避坑：我踩过的五个 Tesseract 集成坑（现象 → 原因 → 解决）

5.1 引擎初始化就崩：找不到 tessdata 或语言包名不匹配

现象：new TesseractEngine(...) 抛异常，消息类似“Failed to init”或“Tesseract has no language for language-code”。原因几乎只有两类：tessdata 目录路径不对，或者语言包文件名与语言代码不一致。"chi_sim+eng" 对应的是 chi_sim.traineddata 和 eng.traineddata，少一个文件初始化就失败。

解决：先确认 tessdata 目录确实在 AppContext.BaseDirectory 下，且文件完整。写一句检查代码是最稳的：

string dataPath = Path.Combine(AppContext.BaseDirectory, "tessdata"); if (!File.Exists(Path.Combine(dataPath, "chi_sim.traineddata"))) throw new FileNotFoundException("语言包缺失", "chi_sim.traineddata");

顺带提醒：下载语言包时如果文件不完整（浏览器断点续传、压缩包解压异常），初始化同样会失败，但报错位置可能在更深处。判断方法很简单——看文件大小，正常的 chi_sim.traineddata 是几十 MB 级别，只有几 KB 的基本是坏的。

5.2 识别结果为空或乱码：先排除语言包、再检查图像

现象：图片肉眼清晰，返回文本却是空白，或是一堆和原文无关的字符。原因概率依次是：语言包没包含对应语种、图像有彩色背景导致二值化失败、PageSegMode 与排版不匹配、DPI 严重偏低。

解决：按顺序排查，不要跳步。第一步，把语言改成 "eng"，只识别英文，试一张纯英文图，排除语言包问题；第二步，把图转灰度并设置 300 DPI，复测；第三步，换 SingleLine 或 SparseText 模式。按这个顺序，大多数情况在第二步就解决了。一个容易忽略的判断技巧：如果返回的字符串长度接近预期但内容不对，通常是引擎切分或 DPI 问题；如果长度完全对不上甚至为空，大概率是语言包或二值化问题。

5.3 混着输出 [ ] { } | 等噪声字符

现象：识别结果主体正确，但夹杂大量符号。原因：引擎从图像里找出接近等宽、连字符的候选并把它们归为字符；未限制字符集时这是常态，尤其当图片里有表格线、边框阴影时，引擎会把这些边角料也当成文本候选。

解决：设白名单加正则过滤，这两步在第四章已经写过。但要说句得罪人的话：如果杂字符来自表格线或文字阴影，只靠白名单压不住，得先回预处理把图做干净。黑白分明的图，杂字符出现率会断崖式下降。这是一个先有鸡还是先有蛋的问题：先预处理再白名单，顺序不能反。

5.4 图片放大三倍，识别率反而下降

现象：小图识别差，放大到 300% 后再识别，错误更多。原因：放大的图像轮廓被插值算法抹圆，字符边缘出现锯齿和模糊，LSTM 的特征提取反而被干扰；而且超大图会触发引擎内部二次缩放，你看到的“放大”不一定被引擎按放大后的尺寸处理。

解决：不要盲目放大。优先把 DPI 设成 300，或设置 user_defined_dpi，让引擎按文档级尺寸理解小图。确实需要放大时，用 HighQualityBicubic 插值，或者干脆把缩小到 2400 宽以内交给引擎自己处理。判断时可以先看原图的 DPI 元数据：如果它只有 72，但你设置的 user_defined_dpi 是 300，引擎会自行换算尺寸，这时再手动放大就是双重缩放，效果反而更差。

5.5 识别时界面卡死数秒：Process 是同步重负载调用

现象：点击识别按钮后窗体无响应，数秒后才恢复。原因：engine.Process 在 UI 线程同步执行，遇到大图或双语言包时耗时可到数秒；如果是连续抓帧，界面会直接冻结。

解决：所有重负载放进 Task.Run，识别完通过 await 回到 UI 线程更新控件。第三章的代码已经是这个写法。如果你接的是摄像头连续帧，还要注意引擎实例不要跨线程共享，每一帧新建引擎的开销其实比想象中小，在桌面 CPU 上通常能接受；而共享引擎跨线程会引发更隐蔽的原生层崩溃，有些表现和老帖子里“c#调用c++出现access violation c0000005”的现象很像，多数是线程或原生库版本不一致造成的。遇到这种崩溃，先检查是不是多个线程在同时用一个 TesseractEngine，这是最常被忽视的元凶。

6. 把演示代码推进一步：批量识别、结果落盘和置信度自检

演示代码跑通只是开始，真正用到业务里通常要处理一批图，而不是一张一张点按钮。常见做法是把识别逻辑抽成一个批量任务，遍历文件夹里的图片，结果写进 CSV 或 JSON，再用置信度把低质量的识别结果筛出来人工复核。批量识别的核心代码：

var files = Directory.GetFiles(folder, "*.png"); var result = new ConcurrentBag<OcrRecord>(); Parallel.ForEach(files, file => { // 每个线程单独创建引擎，不要共享同一个实例 using var engine = new TesseractEngine(dataPath, "chi_sim+eng", EngineMode.Default); engine.SetVariable("user_defined_dpi", "300"); using var pix = Pix.LoadFromFile(file); using var page = engine.Process(pix); result.Add(new OcrRecord( file, page.GetText().Trim(), page.GetMeanConfidence())); }); var low = result.Where(r => r.Confidence < 0.6).ToList();

这段代码里最值得注意的就是“每个线程单独 new 一个引擎”。Parallel.ForEach 默认会开多个线程跑，TesseractEngine 实例不是线程安全的，共享同一个实例去并发识别，轻则结果错乱，重则原生层崩溃。代价是每次识别都要重新加载语言包，几十毫秒的开销，换线程安全是值得的。

置信度阈值 0.6 不是拍脑袋定的，建议你抽样二十张图，看哪些字的置信度集中在哪个区间，再决定阈值设多少。我的习惯是把低置信度的结果单独导出一份“待人工复核”清单，同时把原图路径和识别文字放在同一行，这样复检的人不用翻文件夹找图。这个习惯救过我很多次：批量识别几百张图时，没人能保证每张都干净，与其事后返工，不如一开始就承认 OCR 会有拿不准的时候，把不确定的挑出来让人扫一眼。希望帮到你。

本文还有配套的精品资源，点击获取