简介这是一份面向Java后端开发者与初学者的Spring Boot集成OCR功能实战示例聚焦如何在Spring Boot应用中接入光学字符识别能力解决图片文字提取、票据与文档自动化处理等场景需求。项目围绕Tesseract OCR与云服务OCR两条主流路线展开涵盖依赖引入、服务配置、图片上传接口编写、识别结果解析与后处理等关键环节并涉及异步处理、缓存与图片安全校验等优化思路。资源包共7个文件包含3个java源码、1个xml配置、1个properties配置文件以及cmd、mvnw等构建脚本整体约9KB结构精简便于快速导入IDE运行调试。目前已有408人学习下载适合希望了解RESTful接口调用、文件上传处理与OCR集成的开发者参考可据此搭建可运行的最小示例并在此基础上扩展为更完整的业务模块。1. SpringBoot 集成 OCR 功能 demo从上传一张票据到结构化字段落库很多团队第一次做 OCR 集成都栽在同一个地方本地跑通了Tesseract命令行一放进 SpringBoot 就发现识别率断崖式下跌或者干脆卡在图片预处理这一步。这个 demo 要解决的不是能不能识别出字而是上传一张合同或票据图片后端稳定返回结构化字段并且这套流程能直接搬进生产。它适合两类人一是需要在 SpringBoot 项目里快速加一个 OCR 接口的后端二是想搞清楚本地离线 OCR 和云端 OCR 到底怎么选、参数怎么调、坑在哪的工程师。整条链路我按图片进来 → 预处理 → 识别 → 字段抽取 → 返回来拆每一步都给可复现的代码和参数最后收在几个能直接抄的调优技巧上。2. OCR 引擎选型本地 Tesseract 还是云端 API2.1 两条路线的真实差异选型这件事先别急着看识别率数字先看你的约束条件。本地离线 OCR 的核心优势是数据不出内网、没有调用配额、单次成本趋近于零代价是你要自己扛图片质量、自己装语言包、自己处理并发。云端 OCR 的优势是开箱即用、对模糊和倾斜图片的鲁棒性通常更好、票据类模板识别有现成能力代价是按量计费、有网络依赖、敏感数据要过合规。我一般用三个问题做决策图片里有没有敏感信息日均调用量级是多少识别对象是通用文字还是固定模板票据如果图片涉及合同、身份信息优先本地如果日均几千次以上且对准确率要求高云端更划算如果是固定模板的发票、运单云端往往有专门的模板接口比通用识别准得多。维度本地 Tesseract云端 OCR API数据流向完全内网出网到服务商单次成本接近零按调用量计费部署复杂度需装引擎和语言包只需 SDK 和密钥模糊图片鲁棒性一般依赖预处理通常更好固定模板票据需自己训练或调参多有专用接口并发扩展自己控制线程池服务商侧弹性这个 demo 我两条路都留了接口用策略模式切换这样前期用本地快速验证后期要上量再换云端不用改业务代码。2.2 用策略模式把引擎抽象出来先定义统一接口让上层业务不关心底层是哪个引擎public interface OcrService { // 传入图片字节数组返回识别出的纯文本 OcrResult recognize(byte[] imageBytes, OcrOptions options); }OcrResult里放ListTextLine每行带文本和置信度OcrOptions里放语言、是否启用方向检测、超时时间这些参数。这样做的价值在于业务层只依赖OcrService换引擎时只改一个 Bean 的注入不动 Controller 和字段抽取逻辑。参数说明上language用chi_simeng表示中英混排这是票据场景最常见的组合timeout建议设 5 到 10 秒Tesseract 在低质量图片上偶尔会跑很久没有超时会把线程池拖死。这里有个血泪经验不要用默认的eng去识别中文票据结果会是一堆乱码而且不会报错只会静默返回垃圾。3. 本地 Tesseract 集成依赖、语言包与最小可跑接口3.1 引入依赖和安装引擎Tesseract 是 C 引擎Java 侧用的是 JNA 封装的tess4j。注意tess4j只是调用层系统里必须真的装了 Tesseract 引擎和对应语言包否则启动就报找不到本地库。dependency groupIdnet.sourceforge.tess4j/groupId artifactIdtess4j/artifactId version5.11.0/version /dependencyLinux 上装引擎和中文包# Debian/Ubuntu 系 apt-get install -y tesseract-ocr tesseract-ocr-chi-sim # 验证语言包是否就位 tesseract --list-langs--list-langs的输出里必须能看到chi_sim看不到就是语言包没装对这时候代码里写chi_sim会直接抛异常。Windows 上装完记得把安装目录加进PATH或者用TessAPI.setDatapath()显式指定tessdata目录。3.2 最小可跑的识别接口Service public class TesseractOcrService implements OcrService { Override public OcrResult recognize(byte[] imageBytes, OcrOptions options) { try (InputStream in new ByteArrayInputStream(imageBytes)) { BufferedImage image ImageIO.read(in); if (image null) { throw new IllegalArgumentException(图片解码失败可能不是有效图片格式); } ITesseract instance new Tesseract(); // 指向 tessdata 目录容器化部署时这个路径最容易出错 instance.setDatapath(options.getDatapath()); instance.setLanguage(options.getLanguage()); // 如 chi_simeng // PSM 6 表示按统一文本块识别票据场景比默认值稳 instance.setPageSegMode(6); String text instance.doOCR(image); return OcrResult.of(text); } catch (Exception e) { throw new OcrException(OCR 识别失败, e); } } }逻辑说明先把字节流解码成BufferedImage解码失败要立刻抛错不要让它带着 null 往下走。setDatapath指向tessdata的父目录容器里常见错误是路径写成了tessdata本身。setPageSegMode(6)是关键参数默认的 PSM 3 会自动做版面分析对票据这种多栏排版反而容易切错PSM 6 假设整张图是一块统一文本实测在票据上更稳。参数说明language用连接多语言顺序影响优先级datapath在本地开发时可以用绝对路径生产环境建议通过配置中心注入避免硬编码。4. 图片预处理识别率翻倍的真正原因4.1 为什么原图直接喂进去效果差Tesseract 对二值化、对比度、倾斜非常敏感。手机拍的票据往往有阴影、透视变形、背景噪点直接识别出来的字符会粘连或断裂。预处理不是可选项是决定识别率的主因。常见做法是灰度化 → 自适应二值化 → 去噪 → 纠偏四步走完再进引擎。灰度化把三通道压成单通道减少计算量自适应二值化比全局阈值更适合光照不均的图片去噪去掉孤立像素点纠偏把倾斜的文本行拉正。这四步里二值化对结果影响最大倾斜次之。4.2 用 OpenCV 做预处理public BufferedImage preprocess(BufferedImage src) { Mat mat ImageUtils.toMat(src); Mat gray new Mat(); Imgproc.cvtColor(mat, gray, Imgproc.COLOR_BGR2GRAY); // 自适应阈值blockSize 必须是奇数C 是常数偏移 Mat binary new Mat(); Imgproc.adaptiveThreshold(gray, binary, 255, Imgproc.ADAPTIVE_THRESH_GAUSSIAN_C, Imgproc.THRESH_BINARY, 31, 10); // 中值滤波去椒盐噪点核大小 3 足够 Mat denoised new Mat(); Imgproc.medianBlur(binary, denoised, 3); return ImageUtils.toBufferedImage(denoised); }逻辑说明adaptiveThreshold的blockSize决定局部邻域大小31 适合 A4 大小的票据太小会把文字笔画当背景切掉太大会退化成全局阈值。C是阈值偏移值越大二值化越狠10 是个稳妥起点。medianBlur的核必须是大于 1 的奇数3 对多数票据够用噪点特别多可以上 5但会轻微糊掉细笔画。参数说明如果图片本身很干净比如扫描件可以跳过中值滤波避免过度处理。倾斜纠偏可以用Imgproc.minAreaRect找文本区域的最小外接矩形再算旋转角这里不展开但记住倾斜超过 5 度识别率就会明显掉。提示预处理后的图片建议落盘一份到临时目录出问题时能对比原图和预处理图这是排查识别率问题最快的办法。5. 字段抽取与接口封装从纯文本到结构化返回5.1 用正则抽取固定字段OCR 出来是一整段文本业务要的是金额、日期、单位名称这些字段。固定模板票据用正则最直接别一上来就上 NLP 模型过度设计。public class FieldExtractor { private static final Pattern AMOUNT Pattern.compile( (?:金额|合计|价税合计)[:¥\\s]*([0-9](?:\\.[0-9]{1,2})?)); private static final Pattern DATE Pattern.compile( (\\d{4})[-年/](\\d{1,2})[-月/](\\d{1,2})); public MapString, String extract(String text) { MapString, String fields new HashMap(); Matcher am AMOUNT.matcher(text); if (am.find()) { fields.put(amount, am.group(1)); } Matcher dm DATE.matcher(text); if (dm.find()) { fields.put(date, String.format(%s-%02d-%02d, dm.group(1), Integer.parseInt(dm.group(2)), Integer.parseInt(dm.group(3)))); } return fields; } }逻辑说明正则里[:¥\\s]*是为了兼容 OCR 可能把冒号识别成全角、半角或者金额前多出货币符号和空格。日期统一格式化成yyyy-MM-dd方便后续入库。find()只取第一个匹配如果票据里有多个金额比如单价和合计需要根据关键词位置做优先级或者用while收集全部再筛选。参数说明正则里的\\d{1,2}允许月份日期是一位数避免 OCR 把05识别成5时匹配失败。金额限制两位小数符合财务规范。5.2 Controller 与文件上传RestController RequestMapping(/api/ocr) public class OcrController { private final OcrService ocrService; private final FieldExtractor extractor; PostMapping(/recognize) public ResponseEntityMapString, Object recognize( RequestParam(file) MultipartFile file) throws IOException { // 限制大小防止大图拖垮线程池 if (file.getSize() 10 * 1024 * 1024) { return ResponseEntity.badRequest().body(Map.of(error, 图片超过 10MB)); } byte[] bytes file.getBytes(); OcrResult result ocrService.recognize(bytes, OcrOptions.defaults()); MapString, Object resp new HashMap(); resp.put(text, result.getText()); resp.put(fields, extractor.extract(result.getText())); return ResponseEntity.ok(resp); } }逻辑说明上传接口先做大小校验10MB 是经验值超过这个尺寸的图片要么压缩要么拒绝否则 Tesseract 单次识别可能超过 30 秒。返回体同时给原始文本和抽取字段方便前端调试和人工核对。参数说明MultipartFile的大小限制还要在application.yml里配spring.servlet.multipart.max-file-size否则请求在进 Controller 之前就被拦了。6. 避坑与排查五个真实翻车现场现象一本地跑通Docker 里报UnsatisfiedLinkError。原因是tess4j依赖的本地库在精简镜像里缺失。解决基础镜像用带完整依赖的发行版或者显式安装libtesseract和libleptonica别用 alpine 精简镜像硬扛。现象二中文识别全是乱码。原因是语言包没装或datapath指错。解决先跑tesseract --list-langs确认chi_sim存在再检查代码里的datapath是否指向tessdata的父目录容器里用绝对路径。现象三并发一上来接口就超时。原因是 Tesseract 实例不是线程安全的且单次识别是 CPU 密集。解决每次识别 new 一个Tesseract实例用独立线程池隔离 OCR 任务池大小设成 CPU 核数别用默认的 Tomcat 线程直接跑。现象四金额字段偶尔抽不到。原因是 OCR 把小数点识别成了逗号或空格。解决正则里把分隔符放宽或者在预处理阶段放大图片小字号的小数点最容易丢。现象五图片稍微倾斜就识别率暴跌。原因是没做纠偏。解决加倾斜检测超过 3 度就旋转校正或者引导用户重新拍摄别指望引擎自己扛。7. 进阶技巧用置信度过滤和区域裁剪把准确率再提一档到这一步接口能跑了但真实票据的识别率往往还差一口气。我一般用两个技巧收尾。第一个是置信度过滤tess4j的ResultIterator能拿到每个词的置信度低于阈值的词直接标记为可疑返回给前端高亮让人工复核。这比盲目相信全部结果靠谱得多。// 遍历识别结果收集低置信度词 ListString lowConfidence new ArrayList(); ResultIterator it instance.getResultIterator(); it.begin(); do { float conf it.getConfidence(PageIteratorLevel.RIL_WORD); if (conf 70) { // 70 是经验阈值 lowConfidence.add(it.getUTF8Text(PageIteratorLevel.RIL_WORD)); } } while (it.next(PageIteratorLevel.RIL_WORD));阈值 70 不是绝对的票据清晰可以降到 60模糊场景可以提到 80。第二个技巧是区域裁剪固定模板票据的字段位置基本固定先用模板匹配定位到金额区域只把那一小块喂给引擎识别率比整图识别高一大截速度也快。裁剪坐标可以做成配置换模板时改配置不改代码。我自己的习惯是任何 OCR 接口上线前先拿 50 张真实图片跑一遍统计字段级准确率低于 90% 就不上生产先回去调预处理和裁剪。这个数字比任何参数调优都实在。希望帮到你。本文还有配套的精品资源点击获取 SpringBoot集成OCR实战：从票据上传到结构化字段落库
简介这是一份面向Java后端开发者与初学者的Spring Boot集成OCR功能实战示例聚焦如何在Spring Boot应用中接入光学字符识别能力解决图片文字提取、票据与文档自动化处理等场景需求。项目围绕Tesseract OCR与云服务OCR两条主流路线展开涵盖依赖引入、服务配置、图片上传接口编写、识别结果解析与后处理等关键环节并涉及异步处理、缓存与图片安全校验等优化思路。资源包共7个文件包含3个java源码、1个xml配置、1个properties配置文件以及cmd、mvnw等构建脚本整体约9KB结构精简便于快速导入IDE运行调试。目前已有408人学习下载适合希望了解RESTful接口调用、文件上传处理与OCR集成的开发者参考可据此搭建可运行的最小示例并在此基础上扩展为更完整的业务模块。1. SpringBoot 集成 OCR 功能 demo从上传一张票据到结构化字段落库很多团队第一次做 OCR 集成都栽在同一个地方本地跑通了Tesseract命令行一放进 SpringBoot 就发现识别率断崖式下跌或者干脆卡在图片预处理这一步。这个 demo 要解决的不是能不能识别出字而是上传一张合同或票据图片后端稳定返回结构化字段并且这套流程能直接搬进生产。它适合两类人一是需要在 SpringBoot 项目里快速加一个 OCR 接口的后端二是想搞清楚本地离线 OCR 和云端 OCR 到底怎么选、参数怎么调、坑在哪的工程师。整条链路我按图片进来 → 预处理 → 识别 → 字段抽取 → 返回来拆每一步都给可复现的代码和参数最后收在几个能直接抄的调优技巧上。2. OCR 引擎选型本地 Tesseract 还是云端 API2.1 两条路线的真实差异选型这件事先别急着看识别率数字先看你的约束条件。本地离线 OCR 的核心优势是数据不出内网、没有调用配额、单次成本趋近于零代价是你要自己扛图片质量、自己装语言包、自己处理并发。云端 OCR 的优势是开箱即用、对模糊和倾斜图片的鲁棒性通常更好、票据类模板识别有现成能力代价是按量计费、有网络依赖、敏感数据要过合规。我一般用三个问题做决策图片里有没有敏感信息日均调用量级是多少识别对象是通用文字还是固定模板票据如果图片涉及合同、身份信息优先本地如果日均几千次以上且对准确率要求高云端更划算如果是固定模板的发票、运单云端往往有专门的模板接口比通用识别准得多。维度本地 Tesseract云端 OCR API数据流向完全内网出网到服务商单次成本接近零按调用量计费部署复杂度需装引擎和语言包只需 SDK 和密钥模糊图片鲁棒性一般依赖预处理通常更好固定模板票据需自己训练或调参多有专用接口并发扩展自己控制线程池服务商侧弹性这个 demo 我两条路都留了接口用策略模式切换这样前期用本地快速验证后期要上量再换云端不用改业务代码。2.2 用策略模式把引擎抽象出来先定义统一接口让上层业务不关心底层是哪个引擎public interface OcrService { // 传入图片字节数组返回识别出的纯文本 OcrResult recognize(byte[] imageBytes, OcrOptions options); }OcrResult里放ListTextLine每行带文本和置信度OcrOptions里放语言、是否启用方向检测、超时时间这些参数。这样做的价值在于业务层只依赖OcrService换引擎时只改一个 Bean 的注入不动 Controller 和字段抽取逻辑。参数说明上language用chi_simeng表示中英混排这是票据场景最常见的组合timeout建议设 5 到 10 秒Tesseract 在低质量图片上偶尔会跑很久没有超时会把线程池拖死。这里有个血泪经验不要用默认的eng去识别中文票据结果会是一堆乱码而且不会报错只会静默返回垃圾。3. 本地 Tesseract 集成依赖、语言包与最小可跑接口3.1 引入依赖和安装引擎Tesseract 是 C 引擎Java 侧用的是 JNA 封装的tess4j。注意tess4j只是调用层系统里必须真的装了 Tesseract 引擎和对应语言包否则启动就报找不到本地库。dependency groupIdnet.sourceforge.tess4j/groupId artifactIdtess4j/artifactId version5.11.0/version /dependencyLinux 上装引擎和中文包# Debian/Ubuntu 系 apt-get install -y tesseract-ocr tesseract-ocr-chi-sim # 验证语言包是否就位 tesseract --list-langs--list-langs的输出里必须能看到chi_sim看不到就是语言包没装对这时候代码里写chi_sim会直接抛异常。Windows 上装完记得把安装目录加进PATH或者用TessAPI.setDatapath()显式指定tessdata目录。3.2 最小可跑的识别接口Service public class TesseractOcrService implements OcrService { Override public OcrResult recognize(byte[] imageBytes, OcrOptions options) { try (InputStream in new ByteArrayInputStream(imageBytes)) { BufferedImage image ImageIO.read(in); if (image null) { throw new IllegalArgumentException(图片解码失败可能不是有效图片格式); } ITesseract instance new Tesseract(); // 指向 tessdata 目录容器化部署时这个路径最容易出错 instance.setDatapath(options.getDatapath()); instance.setLanguage(options.getLanguage()); // 如 chi_simeng // PSM 6 表示按统一文本块识别票据场景比默认值稳 instance.setPageSegMode(6); String text instance.doOCR(image); return OcrResult.of(text); } catch (Exception e) { throw new OcrException(OCR 识别失败, e); } } }逻辑说明先把字节流解码成BufferedImage解码失败要立刻抛错不要让它带着 null 往下走。setDatapath指向tessdata的父目录容器里常见错误是路径写成了tessdata本身。setPageSegMode(6)是关键参数默认的 PSM 3 会自动做版面分析对票据这种多栏排版反而容易切错PSM 6 假设整张图是一块统一文本实测在票据上更稳。参数说明language用连接多语言顺序影响优先级datapath在本地开发时可以用绝对路径生产环境建议通过配置中心注入避免硬编码。4. 图片预处理识别率翻倍的真正原因4.1 为什么原图直接喂进去效果差Tesseract 对二值化、对比度、倾斜非常敏感。手机拍的票据往往有阴影、透视变形、背景噪点直接识别出来的字符会粘连或断裂。预处理不是可选项是决定识别率的主因。常见做法是灰度化 → 自适应二值化 → 去噪 → 纠偏四步走完再进引擎。灰度化把三通道压成单通道减少计算量自适应二值化比全局阈值更适合光照不均的图片去噪去掉孤立像素点纠偏把倾斜的文本行拉正。这四步里二值化对结果影响最大倾斜次之。4.2 用 OpenCV 做预处理public BufferedImage preprocess(BufferedImage src) { Mat mat ImageUtils.toMat(src); Mat gray new Mat(); Imgproc.cvtColor(mat, gray, Imgproc.COLOR_BGR2GRAY); // 自适应阈值blockSize 必须是奇数C 是常数偏移 Mat binary new Mat(); Imgproc.adaptiveThreshold(gray, binary, 255, Imgproc.ADAPTIVE_THRESH_GAUSSIAN_C, Imgproc.THRESH_BINARY, 31, 10); // 中值滤波去椒盐噪点核大小 3 足够 Mat denoised new Mat(); Imgproc.medianBlur(binary, denoised, 3); return ImageUtils.toBufferedImage(denoised); }逻辑说明adaptiveThreshold的blockSize决定局部邻域大小31 适合 A4 大小的票据太小会把文字笔画当背景切掉太大会退化成全局阈值。C是阈值偏移值越大二值化越狠10 是个稳妥起点。medianBlur的核必须是大于 1 的奇数3 对多数票据够用噪点特别多可以上 5但会轻微糊掉细笔画。参数说明如果图片本身很干净比如扫描件可以跳过中值滤波避免过度处理。倾斜纠偏可以用Imgproc.minAreaRect找文本区域的最小外接矩形再算旋转角这里不展开但记住倾斜超过 5 度识别率就会明显掉。提示预处理后的图片建议落盘一份到临时目录出问题时能对比原图和预处理图这是排查识别率问题最快的办法。5. 字段抽取与接口封装从纯文本到结构化返回5.1 用正则抽取固定字段OCR 出来是一整段文本业务要的是金额、日期、单位名称这些字段。固定模板票据用正则最直接别一上来就上 NLP 模型过度设计。public class FieldExtractor { private static final Pattern AMOUNT Pattern.compile( (?:金额|合计|价税合计)[:¥\\s]*([0-9](?:\\.[0-9]{1,2})?)); private static final Pattern DATE Pattern.compile( (\\d{4})[-年/](\\d{1,2})[-月/](\\d{1,2})); public MapString, String extract(String text) { MapString, String fields new HashMap(); Matcher am AMOUNT.matcher(text); if (am.find()) { fields.put(amount, am.group(1)); } Matcher dm DATE.matcher(text); if (dm.find()) { fields.put(date, String.format(%s-%02d-%02d, dm.group(1), Integer.parseInt(dm.group(2)), Integer.parseInt(dm.group(3)))); } return fields; } }逻辑说明正则里[:¥\\s]*是为了兼容 OCR 可能把冒号识别成全角、半角或者金额前多出货币符号和空格。日期统一格式化成yyyy-MM-dd方便后续入库。find()只取第一个匹配如果票据里有多个金额比如单价和合计需要根据关键词位置做优先级或者用while收集全部再筛选。参数说明正则里的\\d{1,2}允许月份日期是一位数避免 OCR 把05识别成5时匹配失败。金额限制两位小数符合财务规范。5.2 Controller 与文件上传RestController RequestMapping(/api/ocr) public class OcrController { private final OcrService ocrService; private final FieldExtractor extractor; PostMapping(/recognize) public ResponseEntityMapString, Object recognize( RequestParam(file) MultipartFile file) throws IOException { // 限制大小防止大图拖垮线程池 if (file.getSize() 10 * 1024 * 1024) { return ResponseEntity.badRequest().body(Map.of(error, 图片超过 10MB)); } byte[] bytes file.getBytes(); OcrResult result ocrService.recognize(bytes, OcrOptions.defaults()); MapString, Object resp new HashMap(); resp.put(text, result.getText()); resp.put(fields, extractor.extract(result.getText())); return ResponseEntity.ok(resp); } }逻辑说明上传接口先做大小校验10MB 是经验值超过这个尺寸的图片要么压缩要么拒绝否则 Tesseract 单次识别可能超过 30 秒。返回体同时给原始文本和抽取字段方便前端调试和人工核对。参数说明MultipartFile的大小限制还要在application.yml里配spring.servlet.multipart.max-file-size否则请求在进 Controller 之前就被拦了。6. 避坑与排查五个真实翻车现场现象一本地跑通Docker 里报UnsatisfiedLinkError。原因是tess4j依赖的本地库在精简镜像里缺失。解决基础镜像用带完整依赖的发行版或者显式安装libtesseract和libleptonica别用 alpine 精简镜像硬扛。现象二中文识别全是乱码。原因是语言包没装或datapath指错。解决先跑tesseract --list-langs确认chi_sim存在再检查代码里的datapath是否指向tessdata的父目录容器里用绝对路径。现象三并发一上来接口就超时。原因是 Tesseract 实例不是线程安全的且单次识别是 CPU 密集。解决每次识别 new 一个Tesseract实例用独立线程池隔离 OCR 任务池大小设成 CPU 核数别用默认的 Tomcat 线程直接跑。现象四金额字段偶尔抽不到。原因是 OCR 把小数点识别成了逗号或空格。解决正则里把分隔符放宽或者在预处理阶段放大图片小字号的小数点最容易丢。现象五图片稍微倾斜就识别率暴跌。原因是没做纠偏。解决加倾斜检测超过 3 度就旋转校正或者引导用户重新拍摄别指望引擎自己扛。7. 进阶技巧用置信度过滤和区域裁剪把准确率再提一档到这一步接口能跑了但真实票据的识别率往往还差一口气。我一般用两个技巧收尾。第一个是置信度过滤tess4j的ResultIterator能拿到每个词的置信度低于阈值的词直接标记为可疑返回给前端高亮让人工复核。这比盲目相信全部结果靠谱得多。// 遍历识别结果收集低置信度词 ListString lowConfidence new ArrayList(); ResultIterator it instance.getResultIterator(); it.begin(); do { float conf it.getConfidence(PageIteratorLevel.RIL_WORD); if (conf 70) { // 70 是经验阈值 lowConfidence.add(it.getUTF8Text(PageIteratorLevel.RIL_WORD)); } } while (it.next(PageIteratorLevel.RIL_WORD));阈值 70 不是绝对的票据清晰可以降到 60模糊场景可以提到 80。第二个技巧是区域裁剪固定模板票据的字段位置基本固定先用模板匹配定位到金额区域只把那一小块喂给引擎识别率比整图识别高一大截速度也快。裁剪坐标可以做成配置换模板时改配置不改代码。我自己的习惯是任何 OCR 接口上线前先拿 50 张真实图片跑一遍统计字段级准确率低于 90% 就不上生产先回去调预处理和裁剪。这个数字比任何参数调优都实在。希望帮到你。本文还有配套的精品资源点击获取