用Python搭建跨平台图片OCR工具：从选型到实战

用Python搭建一个能在Windows和Linux上跑的图片OCR工具，这个想法从萌生到落地，我前前后后花了将近两周。起因是一批历史纸质合同的数字化：几百份扫描件堆在文件夹里，每个都要把里面的关键字段录入系统，人工一条条敲，效率低到让人怀疑人生。对比了几个在线OCR平台之后，我意识到两个问题：一是免费额度根本撑不住这个体量，二是合同内容涉及不少业务敏感信息，往第三方平台上传总觉得心里不踏实。于是我开始琢磨自己搭一套：用Python写一个图片OCR工具，跑通Windows和Linux两个系统，既能解决眼前的合同归档，以后其他项目需要文字识别时也能直接复用。

这篇文章就围绕这个目标展开——从OCR引擎怎么选，到Windows和Linux环境各自怎么搭，再到核心代码怎么实现、精度怎么优化，最后把我在实际使用中踩过的坑一并列出来。如果你也正打算在本地搭一套图片文字识别工具，不管你是Python新手还是有一定基础的开发者，这篇文章的思路和代码应该都能直接用上。

1. 为什么需要自建OCR工具：从一次纸质合同归档说起

1.1 项目背景：几百页扫描件倒逼出来的需求

事情的开端其实很朴素。公司整理旧档案，翻出来几大箱子纸质合同，年限横跨七八年，全是业务上不能丢的记录。老板拍板要电子化，于是行政小姑娘抱着扫描仪扫了整整三天，最后扔给我一个文件夹，里面是三百多张JPG，说"你是搞技术的，想想办法"。

我当时第一个念头是找现成的OCR工具。随便搜一下就能找到一堆在线识别平台，注册、上传、识别、复制结果，流程看起来挺顺。结果实测下来问题一大堆。免费用户有每日张数限制，三百张合同分三天都传不完；就算分批次传，识别的结果还要一条条核对复制，格式乱七八糟，更别提有的平台对图片大小还有限制，扫描件分辨率一高就传不上去。

后来认真算了笔账：按我们合同量，买一个像样的OCR套餐，一年下来够招大半个实习生了。而且合同这东西，客户名称、身份证号、金额条款都是敏感信息，经手第三方平台始终是个隐患。我就在想，为什么不能直接用Python在本地搭一套呢？

1.2 自建方案与在线OCR服务的边界

先说结论：自建OCR不等于万事大吉，它和在线服务各有各的适用场景。

在线OCR的最大优势是省事。你上传一张图，几秒钟拿到结果，不需要关心引擎、模型、环境依赖。对于偶尔识别一两张、对隐私不敏感的个人用户，这绝对是最快路径。我自己现在某些临时需求也还会用在线工具，比如识别一张外卖小票、拍一段书本摘录。

但一旦遇到批量、高频、涉及敏感数据、或者需要把识别能力嵌入到自有系统的场景，自建方案的优势就出来了。模型和代码都在本地跑，数据不出内网，批量处理没有张数限制，唯一的花费是电费和服务器资源。而且Python生态有一个特别好的地方：OCR不是孤立的能力，你可以把识别结果直接接进后续的数据清洗、结构化输出、甚至自动化流程里，在线平台是很难做到这种深度的。

当然，自建也有门槛。首先是软硬件环境要自己搞定，Windows和Linux的差异就够喝一壶的；其次是识别精度要自己调，不会像在线大厂那样有专门团队帮你优化。但这恰恰是这篇文章想解决的问题——把门槛降低，把坑填平，让你能快速跑通一套可用的工具。

2. OCR引擎选型对比：Tesseract、PaddleOCR与RapidOCR的取舍

OCR工具的核心是引擎，引擎选对了，后面80%的麻烦都不会发生。我在这个项目里把主流的开源方案都过了一遍，这里把真实感受写出来，方便你根据自己的场景判断。

2.1 Tesseract：老牌开源，但中文场景没那么美好

Tesseract应该是大家最早接触的OCR引擎了，最初由惠普实验室开发，后来交给Google维护。它支持的语言超过100种，安装简单，在英文和印刷体识别上确实有两把刷子。如果你识别的全是英文文档，Tesseract完全够用，配合pytesseract这个Python封装库，十几行代码就能跑通。

但中文场景就有点尴尬了。Tesseract的中文识别需要单独下载语言包（chi_sim），而且它对中文长文本、表格、复杂排版的识别效果，说实话比较一般。我拿一份扫描质量不错的合同测试，页面上有标题、正文、表格、手写签名混合在一起，Tesseract的输出经常出现断行错误、标点吞字、繁体简体混认的问题。它更像一个"通用型选手"，什么都能认，但什么都不算精通。

另外还有个坑：Windows上使用Tesseract，除了pip安装pytesseract，还得额外下载Tesseract的Windows安装包并配置环境变量。Linux下倒是简单，一个apt install就能搞定。如果你只是想要一个轻量级的英文OCR，Tesseract可以；但中文为主、精度要求高的场景，我建议往后看。

2.2 PaddleOCR：中文识别精度最高的开源方案

PaddleOCR是百度飞桨生态里的OCR套件，这是我最终的选择。它的技术架构是典型的"检测+识别"两段式：先通过文本检测模型把图片里的文字区域框出来，再对每个区域做文字识别，中间还有一个方向分类器，用来处理颠倒或者旋转90度的文字。这种Pipeline设计让它对复杂排版的适应性非常强。

实测表现确实能打。同样是那份中文合同扫描件，PaddleOCR识别的准确率明显比Tesseract高一个档次，尤其对中文长句、数字编号、表格线框附近的文字，误识率低很多。它支持的语言也够用，中文简繁、英文、数字都能覆盖。我后来还专门测了手机拍的随手照、歪着的招牌、暗光环境下的票据，它的检测模块都能把文字区域找出来。

代价是依赖比较重。PaddleOCR依赖PaddlePaddle深度学习框架，安装包动辄几百MB，首次运行还会下载几个模型文件。如果你机器上已经跑了CUDA，可以装GPU版让识别速度起飞；没有GPU的话纯CPU跑也完全能接受，后面我会给出一组实测数据。

2.3 RapidOCR：轻量部署的中间路线

RapidOCR是近几年社区里很火的一个方案，它把PaddleOCR训练好的模型转换成ONNX格式，然后用ONNX Runtime推理。好处非常明显：不依赖PaddlePaddle全家桶，安装包小很多，部署起来干净利落，尤其在Docker容器里或者配置较低的机器上，RapidOCR是更舒服的选择。

识别精度方面，因为用的是PaddleOCR的模型权重转出来的，精度基本和PaddleOCR持平，只是推理链路不同，速度上甚至可能略有优势。它的API设计也很友好，一条rapidocr命令就能完成识别。

那为什么我最终没选RapidOCR？主要是我这个项目后续有比较大的模型调优和二次开发需求，直接在PaddleOCR生态里操作更顺手。如果只是要一个轻量、可集成、不想引入太多依赖的OCR引擎，RapidOCR绝对值得优先考虑。选型这件事没有绝对的对错，只有适不适合。

2.4 最终选型逻辑

我把三个引擎整理成一张表，方便你对照决策：

我的选择逻辑其实就三条：合同以中文为主、精度要求高、后续可能要改模型或接自定义逻辑，所以PaddleOCR是最匹配的。而你如果只是要给一个内部小工具加个"图片转文字"的按钮，RapidOCR可能会让你更快落地。

3. 双平台环境搭建：Windows和Linux上最容易翻车的三件事

选好引擎只是第一步，真正让我花掉不少时间的，是Windows和Linux两套环境各自的配置问题。很多坑是单平台开发时遇不到的，只有像我这样在同一套代码里来回切换两个系统，才会被反复教育。

3.1 系统级依赖：别只盯着pip install

PaddleOCR的主依赖可以通过pip安装，但它背后的图像处理库OpenCV，在Linux服务器上经常给你颜色看。我最开始在一台CentOS机器上部署，pip install paddleocr装完，一跑就报libGL.so.1: cannot open shared object file。原因是OpenCV的图形界面模块需要libGL，而纯命令行服务器默认没装。解决办法是装opencv-python-headless替代完整的OpenCV包，或者apt install libgl1。

Windows上这类问题少一些，因为pip装的轮子通常把动态库都打包好了。但Windows有Windows的毛病：Python版本和CPU架构不匹配会导致某些依赖装不上，比如Python 3.13刚出来的时候，PaddleOCR的部分依赖还没提供对应版本，装到一半就报错。稳妥做法是直接装Python 3.10，经历过多个版本踩坑之后，我个人的体会是：做深度学习相关项目，Python版本宁旧勿新。PaddleOCR目前在3.8到3.12之间都能正常使用，3.10是各方面兼容性最好的。

还有一个系统级依赖问题主要在Linux上：如果你用Tesseract做备用方案，需要apt install tesseract-ocr tesseract-ocr-chi-sim，Windows则要去下载安装包再手动加PATH。PaddleOCR没有这个烦恼，模型文件都是Python包自己管理，这也是我偏爱它的原因之一。

3.2 Python虚拟环境：两套命令，一个思路

不管Windows还是Linux，我都强烈建议用虚拟环境隔离项目依赖。不同项目对库版本要求不一样，全装到系统Python里，迟早会互相打架。

Windows下的创建和激活命令是：

bash复制python -m venv venv
venv\Scripts\activate

Linux下的激活方式稍有不同：

bash复制python3 -m venv venv
source venv/bin/activate

这里有个实际经验：刚用Windows的开发者经常忘记要加\Scripts\activate，直接在bash里敲source venv/bin/activate，然后一脸懵地发现命令不存在。其实Windows PowerShell里激活虚拟环境的命令是venv\Scripts\Activate.ps1，CMD里才是venv\Scripts\activate.bat。这个细节网上资料参差不齐，我特意提一句。

激活之后，两边统一用pip install安装依赖，整个流程就安静了：

bash复制pip install paddlepaddle paddleocr

国内网络环境下如果pip下载速度不理想，可以考虑配置PyPI镜像源，这个属于常规操作，能省不少时间。

3.3 模型文件路径与下载问题

PaddleOCR的模型并不是装完库就有的，而是首次运行时自动从模型库下载。在我公司的内网环境里，第一次跑程序卡在下载界面卡了快十分钟，一度以为死机了。后来发现是网络访问外部资源不稳定导致的。

这个问题有两个处理方向。最省事的是提前在有网络的机器上跑一次程序，让它把模型下载好，然后把缓存目录整个拷贝到目标机器。PaddleOCR的模型默认下载到用户目录下，Windows是C:\Users\用户名\.paddleocr\，Linux是~/.paddleocr/。

另一个方向是在代码里显式指定模型路径。如果你的项目需要把模型文件和代码一起分发，或者目标环境完全没有外网，可以用det_model_dir、rec_model_dir这些参数指向本地模型目录：

python复制from paddleocr import PaddleOCR

ocr = PaddleOCR(
    det_model_dir='./models/det',
    rec_model_dir='./models/rec',
    cls_model_dir='./models/cls',
    use_angle_cls=True,
    lang='ch'
)

这个坑我印象特别深。第一次在内网部署时，我把所有依赖都打好了包，以为万事大吉，结果客户现场一跑，卡在模型下载那一步，人脸都绿了。后来把所有模型文件显式放进项目目录里，彻底杜绝了对网络的隐式依赖，才算是真正解决了问题。

4. 核心代码实现：从单张图片识别到批量流水线落地

环境搭好、模型就位，接下来就是动真格写代码。这一节我从最简单的单张识别开始，逐步加码到预处理和批量处理，每一段代码都是我在真实项目里跑过的完整版本。

4.1 单张图片识别的基础版

PaddleOCR的API设计已经足够简单，最基础的调用只需要几行代码：

python复制from paddleocr import PaddleOCR

ocr = PaddleOCR(use_angle_cls=True, lang='ch', show_log=False)
result = ocr.ocr('contract_001.jpg', cls=True)

for block in result[0]:
    text = block[1][0]
    confidence = block[1][1]
    print(f'{confidence:.4f}  {text}')

这里有两个参数需要解释一下。use_angle_cls=True表示启用方向分类器，对识别倒置或旋转的文本区域非常有用，尤其扫描件经常有某一块方向不对的情况；show_log=False用来关掉PaddleOCR运行时的日志输出，不然每次识别都会刷出一大堆调试信息，影响阅读和日志记录。

输出结果result[0]是一个列表，每一项包含两个部分：block[0]是文字区域的四个角点坐标，block[1]是识别文本和置信度。对合同归档来说，坐标信息特别有用的一个点在于——你可以根据文字的坐标位置，把"合同编号""甲方""乙方"这些字段从固定区域提取出来，而不是整页识别完再人工找。这就是OCR从"工具"变成"自动化流程"的关键一步。

4.2 图片预处理：决定精度的隐藏变量

这一步是我在整个项目里最有心得的部分。很多人以为OCR识别率全靠引擎，其实预处理的作用被严重低估了。一张清晰、端正、对比度合适的图片，和一张偏斜、昏暗、有噪点的原图，识别结果可能天差地别。

我们的合同扫描件是各种设备扫出来的，有的偏暗，有的对比度不足，个别还有一定角度的倾斜。直接丢给PaddleOCR，虽然也能识别，但会有不少字被误判。我加了一个预处理环节，主要做三件事：灰度化、自动增强、倾斜校正。

python复制import cv2
import numpy as np

def preprocess_image(image_path, output_path=None):
    # 直接读图无法处理中文路径，这里先绕开，后面会细说
    img = cv2.imdecode(np.fromfile(image_path, dtype=np.uint8), cv2.IMREAD_COLOR)
    gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)

    # 自适应阈值二值化，比固定阈值更能适应明暗不均的扫描件
    binary = cv2.adaptiveThreshold(
        gray, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 15, 10
    )

    # 降噪，去掉扫描产生的孤立噪点
    denoised = cv2.medianBlur(binary, 3)

    # 检测文本主体轮廓，估算倾斜角度
    coords = cv2.findNonZero(denoised)
    angle = cv2.minAreaRect(coords)[-1]
    if angle < -45:
        angle = -(90 + angle)
    else:
        angle = -angle

    # 如果倾斜超过阈值，做旋转校正
    if abs(angle) > 0.5:
        h, w = denoised.shape[:2]
        center = (w // 2, h // 2)
        matrix = cv2.getRotationMatrix2D(center, angle, 1.0)
        denoised = cv2.warpAffine(denoised, matrix, (w, h),
                                  flags=cv2.INTER_CUBIC,
                                  borderMode=cv2.BORDER_REPLICATE)

    if output_path:
        cv2.imencode('.jpg', denoised)[1].tofile(output_path)

    return denoised

这段代码里几个关键点：一是用adaptiveThreshold而不是普通threshold，因为扫描件不同区域的亮度往往不一致，固定阈值很容易把暗部文字的笔画直接抹掉；二是倾斜校正用minAreaRect求出非零像素区域的最小外接矩形来估算角度，这个思路比Hough变换简单直接，对合同这种以正文为主要内容的图片效果很好；三是最后用imencode加tofile写图，这是为了解决中文路径下OpenCV的imwrite会失效的问题，后面我会单独讲。

处理完之后，把预处理图和原图分别丢进OCR对比，识别准确率提升了大概5到8个百分点，最直观的变化是之前经常把"0"看成"O"、把"一"和"-"弄混的情况明显减少了。

4.3 批量识别与结果输出

单张跑通之后，批量处理就是水到渠成的事。我用pathlib处理路径，保证Windows和Linux下行为一致，扫描输出目录下所有图片，识别结果保存成和原图同名的文本文件。

python复制from pathlib import Path
import json

def batch_ocr(input_dir, output_dir, ocr=None):
    input_path = Path(input_dir)
    output_path = Path(output_dir)
    output_path.mkdir(parents=True, exist_ok=True)

    # 复用同一个OCR实例，避免每张图片都重新加载模型
    if ocr is None:
        ocr = PaddleOCR(use_angle_cls=True, lang='ch', show_log=False)

    image_suffixes = {'.png', '.jpg', '.jpeg', '.bmp', '.tiff', '.webp'}
    results_summary = []

    for img_file in sorted(input_path.iterdir()):
        if img_file.suffix.lower() not in image_suffixes:
            continue

        processed = preprocess_image(str(img_file))
        temp_path = output_path / f'_temp_{img_file.name}'
        cv2.imencode('.jpg', processed)[1].tofile(str(temp_path))
        result = ocr.ocr(str(temp_path), cls=True)

        lines = []
        for block in result[0] if result and result[0] else []:
            text = block[1][0].strip()
            if text:
                lines.append(text)

        txt_path = output_path / f'{img_file.stem}.txt'
        txt_path.write_text('\n'.join(lines), encoding='utf-8')

        results_summary.append({
            'file': img_file.name,
            'txt': str(txt_path),
            'lines': len(lines),
            'preview': lines[:3]
        })

        temp_path.unlink(missing_ok=True)
        print(f'[完成] {img_file.name} 识别出 {len(lines)} 行')

    # 汇总信息存成JSON，方便后续对接其他程序
    summary_path = output_path / '_summary.json'
    summary_path.write_text(
        json.dumps(results_summary, ensure_ascii=False, indent=2),
        encoding='utf-8'
    )
    return results_summary

这段代码有两个容易被忽视的细节。第一：sorted(input_path.iterdir())虽然看起来不起眼，但确保了识别顺序稳定。合同扫描件通常按页码命名，如果顺序乱了，后续归档时还得重新对号入座。第二：我特意把处理结果写到临时文件再让PaddleOCR去读，而不是直接传入numpy数组，是因为PaddleOCR的ocr()接口对图片路径的处理最稳定，省去不少类型转换的麻烦。

整个流程跑下来，三百多张合同的识别加保存，在没有GPU的服务器上大约花了一个多小时，输出三百多个文本文件加一份JSON汇总。这个结果已经可以直接交给后续的数据处理环节了。

5. 同一套代码，两个系统的差异：路径、编码与性能实测

如果说前面的环境搭建是热身，那真正让人长记性的是同一套代码在两个系统上跑出不一样行为的那些瞬间。这一节我把我踩过的路径、编码，以及性能差异问题一次性说明白。

5.1 路径分隔符与中文字符路径的坑

路径分隔符是Windows和Linux最表面的差异：Windows用反斜杠\，Linux用正斜杠/。好在Python的pathlib.Path统一处理了两边，所以只要你不是手拼字符串，这个问题基本不用太担心。

真正让人头疼的是Windows上OpenCV读取中文路径图片的问题。cv2.imread('外部客户-合同扫描件\甲方001.jpg')在Windows上会返回None，不报错，但图片就是读不出来。这是因为OpenCV底层用的是C++的文件读取，对UTF-8编码的中文路径支持得很差。

绕开办法就是我前面代码里用到的组合：cv2.imdecode(np.fromfile(path, dtype=np.uint8), cv2.IMREAD_COLOR)。np.fromfile用Python的文件接口把二进制数据读进来，imdecode再解码成图像，完美避开OpenCV自己的文件打开逻辑。同理，写文件时用cv2.imencode加tofile。这两个组合在Windows和Linux上都能正常工作，建议直接用。

Linux下没有中文路径问题，但有另一个反向的坑：如果文件路径里有中文，而系统locale不是UTF-8，Path的输出可能会打印成乱码。这个在绝大多数现代Linux发行版上已经不常见，但如果你管理的服务器是早期版本，建议在代码里统一约定：所有输入输出路径都使用英文命名，减少不必要的麻烦。

5.2 编码问题与Windows终端乱码

Windows的终端默认编码是GBK，而Python 3的字符串是Unicode，两者碰撞的直接结果就是：print('识别完成')在Windows命令提示符里输出乱码。

这个问题不致命，因为文件写入用的是UTF-8，结果本身不受影响。但对一个要长期维护的工具来说，命令行的日志乱码会让使用者怀疑程序出了问题。我用的解决办法是在程序入口处加一行：

python复制import sys

# Python已支持运行时重新配置标准输出编码
sys.stdout.reconfigure(encoding='utf-8')

这行代码在Windows 10以上系统配合新终端（Windows Terminal）使用效果很好。如果你用的是老式控制台，还是乱码的话，也可以在命令行里执行set PYTHONIOENCODING=utf-8之后再运行脚本。Linux上则极少遇到这个问题，print输出UTF-8文本毫无压力。

5.3 双平台性能实测

既然是双平台工具，性能对比是绕不开的话题。我在Windows和Linux上各跑了一次同样的批量OCR任务，样本是100张1280x720的合同扫描图片，用CPU推理，PaddleOCR的use_angle_cls=True。

两个平台单张识别耗时差了大概30%，Linux略快。原因大概率是Linux下的线程调度和内存分配效率更高，加上Windows Defender会对文件读写做实时扫描，对大量临时文件操作有额外开销。如果你要在一个高并发或大批量的生产环境跑OCR，优先选择Linux作为部署平台，能省下不少时间。

不过这个差距并没有大到影响使用体验。日常批量处理几百张图，单张差0.3秒，总时长差个几分钟，对归档这类非实时任务来说完全可接受。Windows更适合做开发和调试，毕竟图形界面、截图工具、可视化预览都方便；Linux更适合做正式批跑和定时任务。

6. 精度优化与实战避坑：几条亲历教训

6.1 常见的识别失败场景

工具跑通之后，并不是万事大吉。我拿手机随手拍了各种图片做测试，总结出几类最容易识别失败的场景：

• 低分辨率图：手机拍的小字票据，文字笔画糊成一团，检测模型找不到完整的文字区域。对策是先放大图片，再做锐化（sharpen），把字迹轮廓找回来。
• 严重倾斜的图：超过15度倾斜的整页图片，预处理里的自动校正已经救不回来，识别率断崖式下跌。对策是尽量扫正，或者把大图切成多个小区域分别识别。
• 复杂表格：合同里的表格区域，文字挨着线框，检测框经常把表格线也框进来，导致识别结果夹杂横线或多字段混在一起。对策是开启PaddleOCR的表格识别模型（table模式），或者先用预处理把线条过滤掉。

6.2 精度优化的几招实战经验

先说一个最直接的：别把原图直接丢给引擎，先做一次放大。用cv2.resize把图片宽度至少放大到2000像素以上，对手机拍摄的小图尤其有效。模型在训练时见过不同分辨率的图片，但分辨率太低时，字符特征本身就不够了，放大能帮检测模型找到文字区域。

第二招是合理使用方向分类器。之前我把use_angle_cls=True当成默认配置，后来发现对规整的扫描件来说，这一步反而偶尔把正常的图片判成旋转，微调了角度后增加了误差。现在的做法是：批量处理扫描件时把use_angle_cls关掉，处理手机随手拍时打开。这个开关不是越大越好，要看输入图片的实际情况。

第三招是按区域裁剪识别而不是整页一股脑识别。合同首页信息密度高，我根据坐标把页面分成标题区、正文区、签字区三个区域分别识别。每个区域文字特征更集中，PaddleOCR识别精度反而更好。这个方法充分利用了前面提到的坐标输出，属于典型的"工程手段优化模型效果"。

第四招是置信度阈值过滤。PaddleOCR每个识别结果都会返回置信度，我设置了一个0.6的经验阈值，低于这个值的文本行丢弃或打标记让人工复核。这样有效防止了"模型自信地输出错误结果"的情况，归档的数据质量整体提升了不少。

6.3 工程化建议

最后说几个让工具真正能长期用的建议：

不要把OCR实例放在循环里反复创建。 PaddleOCR初始化时要加载三个模型，每次创建大约耗时几秒。我在批量处理代码里把ocr实例作为参数传入函数，整个流程只初始化一次，一百张图能省下好几分钟。

日志要保留，输出要结构化。 识别结果除了txt文件，建议同时输出一份JSON，包含文件路径、每行文本、置信度、坐标。对后续的检索、校对、异常追踪都大有帮助。我现在这套工具生成的结果已经能直接被一个小型检索脚本读取，输入关键词就能找到对应合同页码。

考虑加一个CLI入参。 把工具封装成命令行接口，用argparse接收输入目录、输出目录、识别语言等参数。这样不管Windows还是Linux，都可以用一条命令完成任务，还可以配合系统的定时任务实现夜间自动归档。

bash复制python ocr_tool.py --input ./scans --output ./results --lang ch

定期清理临时文件。 我批量处理过程中生成的临时图片如果不删，几百张图要多占好几GB空间。代码里每处理完一张图就删除临时文件，这个习惯很值得养成。

我自己在实际使用中最满意的一点是：这套工具不挑系统，不依赖网络，识别精度足够日常办公和业务归档使用。后来我还往里面加了手机拍照自动旋转校正、关键字段正则提取的功能，已经从一个"应急脚本"变成了团队内部默认的文档数字化入口。如果你也想从零搭一套，我的建议是可以顺手做一次图片预处理再去跑识别，很多坑你就不会踩到了。