企业官网建设流程全解析

简介：面向需要在本地离线场景下集成文字识别能力的开发者，这份压缩包基于百度PaddleOCR搭建了完整可运行的识别环境，支持Python与VC++两种调用方式，尤其适合数据敏感或网络不稳定的PC应用。包内共35个文件、约67.15MB，主要包含可执行程序与动态链接库、识别模型及参数文件，以及VC++测试工程源码、OpenCV和深度学习计算库等运行依赖，既能直接命令行运行识别，也方便二次编译集成到自有项目。资源已有22859人学习下载，适合快速上手离线OCR。通过示例控制台和可视化输出，使用者可直观体验图片文字提取效果，并可参考源码将识别能力嵌入软件，实现完全离线的通用文字识别，兼顾数据安全与响应速度，是本地OCR落地的一套实用参考。

1. 本地离线也需要 OCR？PaddleOCR 为什么是通用场景的首选

很多开发者的第一反应是“OCR 不就是调云 API”，可真到生产环境就发现，内网机房没有外网、客户数据不能出域、单张图里既有印刷体又有手写体还要求高准确率，云 API 根本不敢放进主流程。百度开源的 PaddleOCR 正好解决这三件事——它完全本地离线识别，模型权重下载一次之后就不再碰网络；PP-OCR 系列覆盖中英文识别、表格、版面分析等常见场景，通用识别度极高；而且从 pip 安装到训练自己数据、再到服务化部署，整套工具链都是开源的。这篇笔记按实际落地的顺序写：先跑通最小环境，再调参数把精度提上来，讲清踩过的坑，最后落到训练和生产部署。

2. 把 PaddleOCR 装进本地环境：从零跑通第一张图的完整命令

2.1 安装前的三个决策：Python 版本、CPU/GPU、安装源

PaddleOCR 不是独立二进制程序，而是基于 PaddlePaddle 深度学习框架的 Python 工具库。安装分两层：底层是 paddlepaddle 推理引擎，上层是 paddleocr 封装好的 OCR 工具库，顺序反了会出怪问题，先把底层装对。

决策一：Python 版本选 3.8～3.12，我一般用 3.10。太老的 3.7 对新版 PaddlePaddle 支持已收窄，太新的 3.13 又容易出现算子兼容问题。先建独立虚拟环境，避免和已有项目的 numpy、opencv 打架：

# 创建 Python 3.10 虚拟环境并激活 conda create -n ocr python=3.10 -y conda activate ocr

决策二：确认有没有 GPU。有 N 卡且有 CUDA 环境就装 GPU 版，识别速度能快一个量级；没有就让 CPU 扛，也不用绝望，后面有 CPU 提速的参数组合。GPU 版安装必须指定与驱动匹配的 CUDA 版本，装错最常见的报错是运行时报错找不到 libcudart 动态库。我的建议是先用 CPU 版把整个流程跑通，再换 GPU 版，排错成本低很多：

# CPU 版安装（最稳，先装这个跑通流程） pip install paddlepaddle # GPU 版安装（具体版本以本机 nvidia-smi 支持上限为准） pip install paddlepaddle-gpu

决策三：安装源。目标是本地离线识别，安装阶段最好一次就把依赖拉全。百度官方 PyPI 镜像在国内速度快，同步也及时：

pip install paddlepaddle-gpu -i https://mirror.baidu.com/pypi/simple pip install paddleocr -i https://mirror.baidu.com/pypi/simple

装完先验证底层引擎能不能跑，这一步能筛掉一大半“装完一运行就崩”的问题：

python -c "import paddle; paddle.utils.run_check()"

如果输出运行检查通过，说明引擎层面没问题。这一步报错先别往 OCR 上查，优先看 CUDA 版本和驱动是否匹配、numpy 是否被意外升级。等引擎正常了，再继续装上层工具库和排查 OCR 调用，问题域就清晰了。

2.2 首次跑通最小推理脚本：识别一张图要写多少行代码

引擎装好后写个最小脚本验证流程。这里有个重要前置知识：PaddleOCR 第一次执行PaddleOCR()构造时，会自动检测本地有没有模型权重，没有就联网下载。所以“本地离线识别”指的是推理阶段可以断网，但首次准备模型文件时必须有网，或者手动把模型文件拷进本地目录。一个最简调用长这样：

# 最小推理示例：识别一张本地图片 from paddleocr import PaddleOCR ocr = PaddleOCR( use_angle_cls=True, # 启用方向分类器，处理旋转文本 lang="ch", # 使用中文模型，同时决定了下载哪套权重 show_log=False # 关掉推理日志，只看结果 ) result = ocr.ocr("data/sample.jpg", cls=True) # 输出格式：[[框坐标, (文本, 置信度)], ...] for line in result[0]: print(line[1][0], round(float(line[1][1]), 4))

这段脚本的逻辑是：构造 OCR 对象时指定中文模型并开启方向分类器，接着做“文本检测 + 方向分类 + 文本识别”的端到端推理。result的每一行对应图片里的一个文本区域，line[0]是四角坐标，line[1]是(识别文本, 置信度)。

在这个阶段只需要确认三件事：模型文件是否下载成功、图片是否正常读取、输出是否可读。如果结果乱码或大量空白，先别怀疑模型，大概率是配置问题。第一，图片路径不要用中文；第二，构造参数use_angle_cls=True和调用参数cls=True要保持一致；第三，手机随手拍的竖版文本如果没开方向分类器，识别率会明显下降。把这些确认清楚，再谈精度和性能。

一个更实用的验证方式是把结果画出来，直观看到检测框和文本是否对得上：

# 可视化检测与识别结果 from paddleocr import PaddleOCR import cv2 import numpy as np ocr = PaddleOCR(use_angle_cls=True, lang="ch", show_log=False) result = ocr.ocr("data/sample.jpg", cls=True) img = cv2.imread("data/sample.jpg") for line in result[0]: box = [[int(x), int(y)] for x, y in line[0]] # 四个角点 text, score = line[1] cv2.polylines(img, [np.array(box)], True, (0, 255, 0), 2) cv2.putText(img, f"{text} {score:.2f}", (box[0][0], max(box[0][1] - 10, 0)), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 0, 255), 2) cv2.imwrite("output/result.jpg", img)

polylines把检测框画到图上，putText把识别文本和置信度写到框上方。打开output/result.jpg，看框是否贴合文字、有没有漏检错检，这一步比盯指标更直观。确认没问题，最小链路就算通了。

2.3 新旧接口的写法差异：ocr.ocr 和 predict 到底用哪个

这是网上教程最容易坑人的地方。PaddleOCR 从 2.x 升级到 3.x 时，推荐的推理接口从ocr.ocr()换成了ocr.predict()，返回对象结构也不一样。老教程抄来的代码装上新版本，一运行就报错，不少人卡在这一关。

先查自己装的版本：

pip show paddleocr | grep Version

2.x 版本继续用ocr.ocr()，3.x 版本推荐改用predict()：

# 新版 PaddleOCR 推荐写法（3.x） from paddleocr import PaddleOCR ocr = PaddleOCR( use_doc_orientation_classify=False, # 整图方向分类，一般场景关掉省时间 use_doc_unwarping=False, # 文档矫正，曲面拍摄才需要 use_textline_orientation=True, # 行级方向分类，竖排场景保持开启 lang="ch" ) result = ocr.predict("data/sample.jpg") # 新接口返回预测对象集合，直接取文本和置信度 for res in result: for item in res["rec_texts"]: print(item)

参数说明：use_doc_orientation_classify控制整张图的方向分类，普通横排文档直接关掉能省一段推理时间；use_doc_unwarping是文档展开矫正，只有拍变形、曲面书本才需要；use_textline_orientation负责行级方向判断，竖排文字、倒置文字场景必须开着。新接口里predict()返回 dict，键rec_texts直接给出识别文本列表，比老接口解析嵌套列表更省事。老项目如果已经在用 2.x 接口，不升级代码也行，但新项目建议直接用新接口，少踩一层坑。

3. 通用识别度极高的关键：模型选型与推理参数调优

3.1 模型选型：从 PP-OCRv4 到 v6 tiny，通用场景怎么选

PaddleOCR 的“通用识别度极高”靠的不是单个模型，而是“检测 + 方向分类 + 识别”三段式流水线。模型命名里 PP-OCR 后面的版本号越大，通常精度越高；带 tiny 后缀的是速度和体积折中版；server 版精度高但体积和耗时都上去了。选择逻辑主要看部署条件和目标场景：

实际项目中我倾向保守策略：能用当前稳定版 mobile 就先用，不要一上来追最新。等业务验证了精度瓶颈确实存在，再评估是否升级。标题里说“v6 tiny 速度”，这个方向确实适合 CPU 场景——tiny 模型在端到端耗时上比标准 mobile 版通常有明显优势，代价是在复杂背景、密集小字上的识别率略低。如果你的图片来源比较干净，比如截图、扫描件，tiny 完全够用。

模型权重文件不跟着 pip 包走，而是运行时按配置下载到用户目录，默认是~/.paddleocr/。生产环境建议用det_model_dir、rec_model_dir、cls_model_dir三个参数显式指定本地路径，第一次联网把权重拉下来后，整个~/.paddleocr目录拷到离线机器，代码里指好路径，就彻底断开了运行时的网络依赖，这是本地离线识别的标准姿势。

3.2 检测与识别参数：det_db_thresh、rec_score_thresh 到底影响什么

很多人在 PaddleOCR 里只调lang和方向分类开关，识别率低了就怪模型不行。实际上几个推理参数对结果的影响比换模型更大，而且免费。

det_db_thresh是文本检测后处理的二值化阈值，默认 0.3。它决定一个像素被判为“前景文本”的概率门槛。调低它，更多模糊、浅色文字会被保留，漏检变少；代价是背景纹理、水印可能被当成文本送进识别器，产生一堆乱码。调高则相反。我的经验值：印刷体清晰文档用默认 0.3 就很好；手机实拍、屏幕截图、室内光照不均的图，调到 0.2 会让漏检率明显下降。

det_db_box_thresh是检测框维度的过滤阈值，默认 0.5，低于该分数的框被丢弃。如果检测出来的框总是不完整、半截文字，可以适当调低到 0.4；如果框一大堆但很多是错框，就调高。配合det_db_thresh一起动，通常能找到平衡点。

rec_score_thresh是识别结果置信度阈值，默认 0.5，低于它就过滤。结果里混入大量水印、logo、背景噪声的乱识别，调高到 0.6～0.7 能滤掉一批低置信度输出；反过来发现真实文字被误过滤，就调低。

看一个实际配置组合：

# 面向“手机实拍文档”场景的推荐参数 ocr = PaddleOCR( det_db_thresh=0.2, # 略降检测阈值，减少漏检 det_db_box_thresh=0.4, # 放宽检测框过滤 rec_score_thresh=0.6, # 过滤水印、噪声造成的低置信度输出 use_angle_cls=True, # 处理拍照产生的旋转 lang="ch", show_log=False )

这组参数适合“实拍、光照不均、可能有水印”的通用场景。det_db_thresh降低让模糊边界文字更容易被检测出来，rec_score_thresh提高把背景噪声的乱识别挡在外面，一低一高配合，经常比换大模型更见效。

3.3 图像预处理三板斧：缩放、灰度、二值化在什么时候有用

把图喂给 PaddleOCR 之前，很多问题能用几行预处理提前解决，比事后调参更省事。

缩放。PaddleOCR 对过小的图检测会漏字，对过大的图检测会慢。我一般把长边 resize 到 960～1280 像素再送入识别。手机拍的 4000 像素宽照片直接喂进去，耗时成倍增加，识别率也没见提升。这个操作对 CPU 场景尤其关键，是性价比最高的一步。

灰度化。印刷体黑白截图直接彩色识别没问题；但蓝底白字、红底黑字这类高对比度彩色底纹，先灰度化并拉大对比度能显著提高检测稳定性。原因很简单：检测模型训练数据以自然拍照为主，纯色底纹会干扰它的二值化判断。

二值化。适用于“底纹复杂、字是纯黑或纯白”的票据和扫描件。用 OpenCV 的自适应二值化把背景噪声直接抹掉：

# 预处理：灰度化 + 自适应二值化，适用于底纹复杂的票据 import cv2 img = cv2.imread("ticket.jpg") gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) binary = cv2.adaptiveThreshold( gray, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, # 高斯加权邻域 cv2.THRESH_BINARY, 31, # 邻域块大小，必须是奇数 15 # 常数 C，越大背景越干净 ) cv2.imwrite("ticket_binary.jpg", binary)

逻辑说明：先把图转灰度，再用自适应阈值把每个局部区域独立二值化。块大小 31 表示每个像素参考周围 31x31 范围内的亮度分布，常数 15 在这个基础上再压低 15 个灰度级，背景噪声通常就这样被抹掉。二值化不是万能的，它会连浅色文字一起抹掉，所以只建议在票据、证件扫描件这类背景复杂但文字对比度统一的场景使用。

旋转校正。如果图片倾斜角度超过 30 度但不到 90 度，方向分类器也容易懵。先用 Hough 变换或手动旋转把主体文本摆正，再送入识别。这属于“脏活前置”，在进模型之前解决比依赖模型硬扛可靠。

预处理不是越强越好，核心原则是“贴近模型的训练数据分布”。模型在自然拍摄图上训练，你把图预处理成四不像，反而拉低识别率。

4. PaddleOCR 翻车现场避坑指南：模型下载、乱码与性能瓶颈

4.1 现象：离线机器首次运行卡在“Downloading model”

现象：把程序部署到内网机器，第一次执行PaddleOCR(lang="ch")，日志停在下载权重文件上，然后超时、重试、再超时。

原因：PaddleOCR 默认首次推理前按参数下载检测、方向分类、识别三套模型。内网机器访问不了外网下载地址，卡在拉取阶段。这其实是部署方式问题——只装了 pip 包，没把模型权重这层考虑进去。

解决：在一台联网机器上装好 paddleocr，随便跑一次让模型落入默认缓存目录，然后把整个~/.paddleocr目录打包带到离线机器，放到相同用户目录。更稳的方式是代码里显式指定模型目录，用det_model_dir、rec_model_dir、cls_model_dir三个参数分别指向对应权重所在路径。这样不依赖默认目录是否存在，部署脚本里写清楚模型路径即依赖，才算真正的本地离线识别。

提示：检查离线环境是否就绪，先看目标机器上~/.paddleocr里有没有det、rec、cls三个子目录，有则说明权重已落位。

4.2 现象：Windows 下中文路径导致进程崩溃或读不到图

现象：Windows 上运行，图片放在C:\项目资料\测试\1.jpg这类中文路径下，运行时 OpenCV 或 PaddleOCR 内部报错，有的报 UnicodeDecodeError，有的直接进程崩溃。

原因：PaddleOCR 内部图像读取和预处理对非 ASCII 路径处理不完善。这是个老坑，它不在接口层报错，而在引擎深处炸，排查起来很消耗时间。

解决：项目根目录、图片路径、输出路径全部用英文小写字母和数字，不出现中文、空格、特殊字符。业务系统路径已经带中文的，在程序里先把图片转存到英文临时目录，再交给 PaddleOCR。有人用cv2.imdecode(np.fromfile(...))绕开读取问题，但检测内部仍有其他路径操作，最省心的办法就是转存到全英文路径。

4.3 现象：CPU 推理一张 4000 像素大图要 8～12 秒

现象：同样的代码在 CPU 机器上慢到没法用，单张图端到端识别要好几秒甚至超过十秒。

原因：三个因素叠加。第一，图太大，检测阶段在 4000 像素宽的图上做尺度遍历，计算量成倍增加；第二，加载了“识别 + 方向分类”两套模型，每个检测框都要过方向分类；第三，标准 mobile 模型在 CPU 上本来就不快。

解决：按优先级尝试。先把长边缩到 960 像素，耗时能砍掉一半以上；然后如果图片文字基本不旋转，关闭方向分类器，又能省一截；最后还不够，换 tiny 系模型，配合低分辨率输入，CPU 上能跑到可用水平。我自己的经验值是，一张 720p 截图走“缩放 + 关闭方向分类 + tiny 识别”这套组合，在普通办公 CPU 上能压到 1 秒附近。对速度敏感的场景，PaddleOCR 的 tiny 系值得重点关注——体积小、速度快，通用场景的识别度损失在可控范围。

4.4 现象：识别结果全空，或者输出一堆乱码

现象：图片里明明是清晰中文，结果result是空列表，偶尔输出一行乱码。

原因：空结果通常是检测阶段一个框都没找出来，常见于浅色小字、高亮背景或分辨率过低；乱码则是方向分类没启用时，竖排或倒置文本被强行横向识别。另一个隐蔽点：老接口ocr.ocr()里必须传cls=True才会执行方向分类，构造参数use_angle_cls=True并不会覆盖调用时的参数，两者的组合关系容易记混。

解决：先开show_log=True看检测阶段输出了几个框。一个框都没有，去调det_db_thresh或做预处理；框很多但识别为空，检查识别置信度阈值是否调得过高。乱码方向检查use_angle_cls和cls是否配套开启。最后实在找不出原因，用预处理流程统一跑一遍对比，很多时候是输入图质量问题，而不是模型能力不够。

4.5 现象：GPU 环境报显存不足，或推理时直接 OOM

现象：GPU 机器上跑超大图或大 batch 时，进程报 CUDA out of memory，有时只是单张图也崩。

原因：PaddleOCR 默认在 GPU 上申请大量显存，图太大时检测阶段的多尺度推理会把显存撑爆。还有一个常见因素是开了多个PaddleOCR()实例，每个实例都各自加载一套模型，显存翻倍。

解决：第一，先缩放输入图，长边控制在 1280 以内，显存压力立刻变小；第二，整个程序里只创建一个PaddleOCR()实例，后续请求复用它，避免重复加载和显存浪费；第三，如果显存还是紧张，把eval_batch_size和推理配置里的 batch 调成 1，逐张推理。4G 显存的卡也能跑通用场景，关键是控制输入尺寸不放飞。

5. 用自己的数据做领域识别：PaddleOCR 训练与微调全流程

5.1 数据标注：用 PPOCRLabel 制作检测与识别数据集

当通用模型在领域数据上识别率不够，比如生僻地名、化学符号、特定字体，就需要给模型喂自己的数据。PaddleOCR 官方推荐的路径是 PPOCRLabel 标注工具，它同时产出检测和识别两种格式的数据。

标注流程：准备几百到几千张领域图片，用 PPOCRLabel 打开，框出每个文本区域并转写正确文字。保存后，同一个标注文件里既有检测框坐标，又有识别文本。这一步工作量最大，但它决定了后面是“微调提升”还是“白练一场”。我见过有人拿 100 张图微调出不错效果，也见过 5000 张图没调好，区别就在于前者标注质量高、框边界贴合、转写无错字，后者框松松垮垮，模型学了一堆背景边缘。

数据目录建议按官方推荐结构组织：

train_data/ ├── det/ │ ├── images/ # 检测训练原图 │ └── Label.txt # 标注格式：图片路径 + 文本框坐标 + 文本内容 └── rec/ ├── images/ # 识别训练裁剪图 └── rec_gt.txt # 标注格式：图片路径 + 制表符 + 转写文本

检测标注的Label.txt每行长这样：images/001.jpg [{"points": [[10, 20], [210, 20], [210, 60], [10, 60]], "transcription": "企业名称", "difficult": false}]。识别标注rec_gt.txt更简单：001.jpg 企业名称，中间是制表符。

数据量方面，检测任务少则两三百张，识别任务建议每个类别至少几十个样本。类别不均衡是常见坑：你打算识别的生僻字在数据里只出现 5 次，模型基本学不会，需要定向补充。标注完后用官方脚本把数据按 8:2 分训练集和验证集，验证集千万不能和训练集来自同一批模板，否则评估指标虚高。

5.2 微调识别模型：训练命令、参数与显存建议

数据备好后，从 PaddleOCR 官方仓库拉训练代码和配置。训练配置走 YAML，里面定义了模型结构、数据路径、学习率等。以微调识别模型为例，常见做法是：

# 克隆 PaddleOCR 仓库，训练脚本在 tools/ 下 git clone https://github.com/PaddlePaddle/PaddleOCR.git cd PaddleOCR # 安装训练依赖 pip install -r requirements.txt # 下载官方预训练权重放到 pretrain/ 目录 # 微调识别模型 python tools/train.py \ -c configs/rec/PP-OCRv4/ch_PP-OCRv4_rec.yml \ -o Global.pretrained_model=./pretrain/PP-OCRv4_rec_train \ Global.epoch_num=100 \ Global.train_batch_size=32 \ Global.eval_batch_size=64 \ Global.use_gpu=True \ Global.save_model_dir=./output/rec_finetune \ Train.dataset.data_dir=./train_data/ \ Train.dataset.label_file_list=./train_data/rec_gt.txt \ Eval.dataset.data_dir=./train_data/ \ Eval.dataset.label_file_list=./train_data/rec_eval.txt

命令逻辑：-c指定基础配置 YAML，-o覆盖其中关键项。Global.pretrained_model是预训练权重前缀，PaddleOCR 从它加载参数而不是从零训练，这是领域微调的核心——小数据也能快速收敛。epoch_num微调 50～150 都常见，先跑 50 轮看损失曲线再决定加不加。train_batch_size=32大约需要 8～12G 显存，不够就降到 16 或 8，学习率也按比例下降。大批量需要更小的学习率才能稳住收敛，这是经验法则。

训练日志主要盯loss和acc。当 acc 在验证集上开始震荡或不再下降，就该停了。训练产物是模型权重，PaddleOCR 需要先导出成推理模型再用于部署：

# 导出推理模型 python tools/export_model.py \ -c configs/rec/PP-OCRv4/ch_PP-OCRv4_rec.yml \ -o Global.pretrained_model=./output/rec_finetune/best_model \ Global.save_inference_dir=./inference/rec_finetune

导出后得到inference.pdmodel和inference.pdiparams两个文件，分别对应模型结构和参数。把这两个文件替换到本地识别模型目录里，推理代码里的rec_model_dir指过去即可。替换前先备份原模型目录，这是你的后悔药。

5.3 评估与导出：指标之外还要看失败样本

很多人验证阶段只盯平均准确率，走出训练目录在真实数据上一跑就漏成筛子。我的习惯是固定留 200～300 张真实拍摄图做“验收集”，这些图不参与训练也不参与验证，专门用来跑训练出的模型，把误识别、漏检的图翻出来人工逐张过。

评估用官方工具：

# 识别模型评估 python tools/eval.py \ -c configs/rec/PP-OCRv4/ch_PP-OCRv4_rec.yml \ -o Global.pretrained_model=./output/rec_finetune/best_model \ Global.eval_batch_size=64 \ Eval.dataset.data_dir=./train_data/ \ Eval.dataset.label_file_list=./train_data/rec_eval.txt

best_model是训练过程中在验证集上表现最好的权重，不是最后一轮。eval 脚本输出 acc 和 norm_edit_distance 等指标。但指标过了不代表能上线——我踩过印象很深的坑：acc 到 0.98，上线第一天被“带划线的手写数字”打回原形，因为这些样本训练数据里根本没有。训练数据没覆盖的失败模式，指标再高也救不了，必须单独收集补充。评估阶段每张图的定性结果比一个平均分可靠得多，失败样本才决定能不能上线。

6. 把 PaddleOCR 从脚本变成服务：部署形态与验证技巧

6.1 三种部署形态：进程内调用、独立服务、PaddleX 一站式

最早我把 PaddleOCR 直接嵌在业务进程里，图片一张张调ocr.ocr()。简单是简单，但业务代码一抛异常，OCR 引擎就要重新初始化，模型加载一次好几秒。后来改成独立服务省心很多：进程常驻，模型只加载一次，外部通过 HTTP 传图片路径返回结果。小型项目用 FastAPI 包一层就够，几十行代码撑起一个 OCR 服务。涉及多模型、批量任务、服务化编排时，PaddleX 这套官方工具链会省力不少，它把检测、识别、版面分析、表格识别等 pipeline 统一管理，适合做复杂文档智能处理。

6.2 我的验证习惯：用真实场景图集做回归测试

不管哪种部署形态，上线前一定要建立一个固定图片集做回归测试。我在项目里维护一个test_cases/目录，放各场景样图：清晰印刷体、手机实拍、模糊扫描件、含表格、含竖排、含手写。每次改参数、换模型、升级版本，整批跑一遍，把“识别结果相比上次是否变差”作为硬性验收标准。

这个习惯帮我排查过一个隐蔽问题：升级 PaddleOCR 版本后整体 acc 没变，但某个客户场景的特定字体识别率明显退化。如果没做回归测试，这种退化会被平均指标完美掩盖。跑完测试后，我会把每张图的耗时、识别文本、置信度存成 JSON 快照，留给后续版本对比。一个项目做久了，这份快照就是团队的后悔药，模型升级翻车时能立刻回滚对比，而不是靠记忆猜哪个参数变了。

OCR 落地这件事，跑通只是起点，真正的功夫在参数、数据和验证这些细活上。PaddleOCR 本地离线识别的好处恰恰是每一步都可以自己掌控，不用把数据送出内网，也能反复试错。我的经验总结成一句话：先固定输入质量，再调模型参数，最后用验收集锁住效果，这条路对新手和熟手都适用。希望帮到你。

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