简介：面向需要离线完成图片文字识别的开发者，这份打包好的exe工具开箱即用：使用者只需输入图片路径，程序便自动调用OCR模型完成识别，并将结果保存为txt文件。资源基于百度开源的PaddleOCR框架，将预训练模型、依赖库与核心脚本整体封装，适合大批量文档文字提取、本地数据预处理，以及无法安装Python环境的生产服务器部署。压缩包共2000个文件，整体大小约279MB。文件类型以Python源码及其编译后的pyc/pyd文件为主，同时包含DLL动态链接库、msg资源文件、tcl脚本、txt配置说明、png图标等，目录结构清晰，便于二次开发、功能校验与定制裁剪。已有3786人学习或下载，具备较高参考价值。通过这个工具，用户可摆脱环境搭建和依赖冲突的困扰，直接获得稳定可用的OCR能力；包内附带的源码、配置与示例数据，也为后续自定义识别逻辑、替换模型或扩展批量识别接口提供了完整基础。
1. 为什么把 PaddleOCR 打成 exe：内网交付与模型离线落地
做了个票据识别的 PaddleOCR 脚本，在开发机上跑得飞快，拿到客户现场就翻车：对方电脑没有 Python 环境、业务网离线、IT 不给装任何东西。这时候把 PaddleOCR 打成离线 exe 就成了唯一能交付的形态——双击即用、模型内嵌、不依赖网络。PaddleOCR 的推理模型本身不大（检测、分类、识别三个模型加起来 20MB 上下），真正把体积累上去的是 paddlepaddle 运行库和 OpenCV，一个 CPU 版离线工具打包出来普遍在 150-300MB。这篇记录从「联网开发」到「离线打包交付」的全过程，重点是模型路径设计、PyInstaller 的 spec 配置、报毒和体积这几个躲不掉的环节。适合要把 OCR 能力部署到内网、工控机或非技术用户机器上的开发者，也适合第一次打包就被各种 dll 和路径问题劝退的新手。
2. 离线模型先落地：三件套结构、本地目录设计与断网验证
2.1 PaddleOCR 的模型三件套
PaddleOCR 的中文识别链路是三个模型串行接力：检测模型（Det）先把图片里所有文本行用矩形框标出来，方向分类器（Cls）判断每个框是否需要 180 度旋转，最后识别模型（Rec）把框内的图像转成字符串。三者的模型文件都不大，PP-OCRv4 中文场景下，检测模型约 4.5MB、方向分类模型约 1MB、识别模型约 10MB，合计 15MB 上下。exe 打包后的体积大头从来不在模型，而在于运行时的计算库和图像库。
离线工具在装依赖时就要定一条规矩：装 CPU 版，不装 GPU 版。GPU 版 paddlepaddle 会带入 CUDA、cuDNN 动态库，打包后直奔 500MB，在现场没有 N 卡的工控机上一样跑不起来。CPU 版靠 MKLDNN 加速，单张票据识别耗时能压到 1 秒内，对 OCR 这种轻推理任务足够用。
2.2 模型预下载与离线目录设计
PaddleOCR 在不指定任何模型目录时，第一次运行会联网下载默认模型，落盘到当前用户目录下的~/.paddleocr/whl缓存里。目录结构大致是：
C:\Users\dev\.paddleocr\whl\ ├── det\ch_PP-OCRv4_det_infer\ ├── rec\ch_PP-OCRv4_rec_infer\ └── cls\ch_ppocr_mobile_v2.0_cls_infer\把这三个版本化目录整份复制到工程目录，去掉中间的版本层级，得到一套干净的离线资源：
PaddleOCR_Offline/ ├── main.py ├── models/ │ ├── det/ # 检测模型 │ ├── rec/ # 识别模型 │ └── cls/ # 方向分类模型 └── fonts/ # 可选，PDF 转图时会用到字体每个模型目录下至少要确认两个关键文件存在：inference.pdmodel（网络结构）和inference.pdiparams（权重）。缺其中一个，PaddleOCR 会认为模型不完整，转而尝试联网重新下载，这是离线工具最典型的隐性联网点。用 PowerShell 做一次完整检查比较稳妥：
Get-ChildItem -Recurse models | Select-Object FullName, Length操作上，我一般先在联网的开发机跑通一次完整识别，再去~/.paddleocr/whl复制缓存。如果之前装过其他版本，缓存里可能有多个带版本号的目录，复制时认准初始化时使用的版本，别混搭——检测模型用 v3、识别模型用 v4 这类组合通常报 shape 不匹配，排错成本很高。
2.3 初始化代码：模型路径写死，不给联网机会
离线工具的核心差异就在 PaddleOCR 初始化这一步：所有模型目录显式传入，代码里不出现任何「自动下载」的兜底路径。
import logging from paddleocr import PaddleOCR logging.getLogger("ppocr").setLevel(logging.ERROR) logging.getLogger("paddle").setLevel(logging.ERROR) ocr = PaddleOCR( det_model_dir="models/det", rec_model_dir="models/rec", cls_model_dir="models/cls", lang="ch", use_angle_cls=True, use_gpu=False, show_log=False, enable_mkldnn=True )参数说明：det_model_dir、rec_model_dir、cls_model_dir三行把关联网下载的口子全部堵死；use_angle_cls决定是否启用方向分类，票据扫描件建议开启，纯截图场景可以关掉省一点耗时；enable_mkldnn=True是 CPU 上启用 Intel MKL 加速的开关，第一次加载模型会慢几秒，后续推理明显变快。show_log=False只挡 PaddleOCR 的上层日志，paddle 底层的 WARNING 还需要前面两行 logger 级别配合。
这里必须提醒一个版本断层：上面是 PaddleOCR 2.7.x 的参数写法。3.x 开始 API 大改，参数名换成text_detection_model_dir、text_recognition_model_dir、text_orientation_model_dir，返回结果也从嵌套 list 变成Result对象列表，取文本要改走res.texts。拿 2.x 的代码硬跑 3.x，初始化阶段就会报参数错误。写代码前先确认pip show paddleocr的版本，不要盲目抄网上 2.x 的代码。3.x 的离线初始化长这样：
ocr = PaddleOCR( text_detection_model_dir="models/det", text_recognition_model_dir="models/rec", text_orientation_model_dir="models/cls", lang="ch", use_textline_orientation=True, ) result = ocr.predict("test.png") for res in result: print(res.texts, res.rec_scores)两个版本的初始化思路完全一致，都是把模型目录写死、关闭 GPU、压低日志输出。选择版本的关键在于你手头代码抄的是哪个 API，以及周边依赖是否已经锁定。一旦用到 3.x 的新模型，2.x 的初始化代码就彻底不能用了。
2.4 断网验证：打包前先暴露离线问题
模型目录配对后，立刻做一次严格的离线验证：断网（拔网线或断 WiFi），命令行执行python main.py --test.png。预期行为是没有任何 Download 提示、模型加载完成直接出结果。如果看到下载字样或进程卡住不动，说明某个模型目录没有被识别成完整模型，PaddleOCR 正在尝试联网兜底。
这一步值得专门安排十分钟。它把「模型路径错误」这类问题拦截在 Python 源码阶段，而不是等到 exe 阶段再排查——到时候日志被console=False吞掉，要靠 Process Monitor 去猜，成本高得多。顺带在断网状态下跑一遍use_angle_cls=True和False各一张图，把方向分类器对结果的影响摸清楚，后面裁剪模型时心里有底。
3. PyInstaller 打包配置：spec 文件、依赖收集与三类翻车点
3.1 版本组合：Python 3.10 是打包机最稳的选择
打包机推荐 Python 3.9 或 3.10，配 CPU 版 paddlepaddle 和 PyInstaller。在 3.11、3.12 上 paddlepaddle 的官方 wheel 覆盖不完整，经常现场编译失败，直接卡在pip install阶段，连打包的影子都见不到。用 3.10 则一路顺畅：
pip install paddlepaddle==2.6.1 -i https://mirror.baidu.com/pypi/simple pip install paddleocr==2.7.3 pip install pyinstaller==6.3.0版本说明：paddlepaddle 2.6.x 与 paddleocr 2.7.x 是经过大量线上验证的组合；PyInstaller 6.x 对 opencv 这类自带 dll 的大依赖处理得比 5.x 稳，打包报错率明显低。需要提醒的是镜像源：paddlepaddle 官方源在国内经常拉取超时，用百度源能把几分钟的下载压到十几秒，这条命令里的-i参数可以直接保留。装完之后用pip list | findstr paddle确认三个关键包都在，再开始下一步。
3.2 一个能打包的最小入口程序
打包前提是有一个入口脚本。下面这个 tkinter 版主程序足够小，但五脏俱全：隐藏 paddle 日志、离线初始化、选择图片、展示结果、导出 txt。tkinter 是标准库，打包时不会引入额外体积。
import os import sys import logging import time from tkinter import Tk, Button, Text, filedialog from paddleocr import PaddleOCR logging.getLogger("ppocr").setLevel(logging.ERROR) logging.getLogger("paddle").setLevel(logging.ERROR) BASE_DIR = getattr(sys, "_MEIPASS", os.path.abspath(".")) def resource_path(relative_path): return os.path.join(BASE_DIR, relative_path) ocr = PaddleOCR( det_model_dir=resource_path("models/det"), rec_model_dir=resource_path("models/rec"), cls_model_dir=resource_path("models/cls"), lang="ch", use_angle_cls=True, use_gpu=False, show_log=False, enable_mkldnn=True ) def pick_image(): path = filedialog.askopenfilename( filetypes=[("Images", "*.png *.jpg *.jpeg *.bmp")] ) if not path: return result = ocr.ocr(path, cls=True) lines = [] for item in (result[0] or []): text, conf = item[1] lines.append(f"{text}\t({conf:.2f})") output.delete("1.0", "end") output.insert("end", "\n".join(lines)) with open("result.txt", "w", encoding="utf-8") as fp: fp.write("\n".join(lines)) app = Tk() app.title("OCR 离线识别") Button(app, text="选择图片并识别", command=pick_image).pack(pady=10) output = Text(app, height=20, width=60) output.pack(padx=10, pady=10) app.mainloop()这段代码里最值得关注的是resource_path()函数：它用sys._MEIPASS兼容 PyInstaller 的两种运行模式。开发期_MEIPASS不存在，退化为当前目录；打包后指向临时解压目录或 dist 资源目录。后面所有模型路径都经过它，打包前后不用改一行代码。result[0] or []这个写法是为了兼容 PaddleOCR 返回空结果时的 None，OCR 一个纯白图片时不会因为空指针闪退。
3.3 第一次打包：用 onedir 而不是 onefile
第一次打包永远用目录模式。onedir 产出一个文件夹，exe 和依赖 dll 平铺，缺哪个文件一眼就能看出来；onefile 产出一个孤立 exe，启动时先把 200 多 MB 内容解压到临时目录再加载，冷启动慢、报错黑匣子、杀软还容易误报。开发期选 onedir，相当于给自己留了后悔药。
pyinstaller --onedir --clean --name OCR_Offline ^ --add-data "models;models" ^ --add-data "fonts;fonts" ^ --hidden-import paddleocr ^ --hidden-import paddle ^ --hidden-import skimage ^ --hidden-import imghdr ^ --exclude-module matplotlib ^ --exclude-module IPython ^ main.py参数说明：--add-data "models;models"把离线模型目录带进产物，Windows 下源路径和目标路径用分号分隔；--hidden-import逐个补齐 PyInstaller 静态分析不可能发现的动态导入模块，PaddleOCR 内部对skimage、imghdr的引用都在运行时才发生，漏掉任何一个都会等到打包后运行才爆炸；--exclude-module把matplotlib、IPython、jupyter这类只活在开发期的库排出去，能省几十 MB。
打包成功后检查dist\OCR_Offline目录：
OCR_Offline.exe 主程序，双击即用 models\ 离线模型，对应 --add-data paddle\ paddlepaddle 运行时库 libiomp5md.dll Intel MKL 运行时，缺失时手动补 _internal\ PyInstaller 收集的 Python 依赖包，不可删这个目录里如果看不到models或者paddle，说明对应--add-data或 hiddenimports 没生效，调整完配置重新打包再往下走。两种模式的差别可以直接对比：
| 维度 | onedir | onefile |
|---|---|---|
| 启动速度 | 1-2 秒 | 冷启动 8-15 秒 |
| 排错难度 | 低，目录直观 | 高，黑匣子 |
| 杀软误报概率 | 较低 | 较高 |
| 交付形态 | 目录压缩包 | 单个 exe |
| 适合场景 | 内网交付、持续维护 | 演示、快速分发 |
3.4 spec 文件：把资源与依赖固化下来
命令行适合第一次试跑，真正的交付配置要落到 spec 文件。PyInstaller 生成 spec 后会用它覆盖命令行参数，所以后续打包只维护这一个文件：
# -*- mode: python ; coding: utf-8 -*- a = Analysis( ["main.py"], pathex=[], binaries=[], datas=[ ("models", "models"), ("fonts", "fonts"), ], hiddenimports=[ "paddleocr", "paddle", "skimage", "imghdr", "cv2", ], excludes=[ "matplotlib", "IPython", "jupyter", "pandas", "scipy", ], noarchive=False, ) pyz = PYZ(a.pure) exe = EXE( pyz, a.scripts, a.binaries, a.datas, name="OCR_Offline", debug=False, strip=False, upx=False, console=False, )datas里的元组("models", "models")含义是「把工程 models 目录原样拷到产物 models 目录」，字体目录同理。noarchive=False是 PyInstaller 默认行为，把字节码打包成 PYZ 归档，加快启动；改成 True 会平铺成文件，方便反查但没必要。upx=False不是笔误，UPX 压缩省下的体积会以杀软误报加倍还回来，后面第 5 章细说。console=False隐藏控制台窗口，交付体验干净，但第一次调试建议改成True——否则程序启动就崩，报错只在屏幕上闪一下。
从此之后打包只跑一行命令：
pyinstaller OCR_Offline.spec --clean --log-level WARN3.5 资源路径归一化与 onedir 目录自查
在 onedir 模式下，exe 同级目录就是资源所在，理论上直接相对路径也能工作。但程序可能被快捷方式双击启动，此时工作目录是快捷方式所在目录而不是 exe 目录，相对路径立刻失效。规范做法是启动时主动把当前目录切到 exe 旁，再配合resource_path()：
os.chdir(os.path.dirname(os.path.abspath(sys.argv[0])))这两行放在 main.py 开头，之后所有相对路径都基于 exe 所在目录解析。打包过程中如果发现dist里模型目录不存在，优先检查datas是否写对、路径分隔符在 Windows 下是否用了反斜杠——PyInstaller 对正反斜杠的容错并不友好，统一用正斜杠最省心。
如果确实要换 onefile，记住两点：一是sys._MEIPASS会指向系统临时目录下的_MEIxxxx文件夹，每次启动重建、退出清理；二是杀软实时监控会额外扫描这个大文件夹，冷启动会被拖慢到十几秒。能接受这两个代价再切，否则 onedir 目录压缩包是更理智的交付形态。
4. 避坑排查：exe 运行报错的五个高频现象
4.1 现象：双击 exe 闪退，没有任何弹窗
原因：console=False把程序所有输出吞掉，启动即崩也看不到堆栈；另一种可能是在 PyInstaller 的静态分析里漏掉了某个动态导入的模块，导入阶段抛异常。
处理：把 spec 里console改成True重新打包，或在 cmd 里直接运行dist\OCR_Offline\OCR_Offline.exe，让异常堆栈留在终端。看到报错模块之后再决定是补hiddenimports还是调整依赖版本。如果 cmd 里也没有任何输出，去 Windows 事件查看器翻「应用程序」日志，找.NET Runtime或Application Error来源的记录，崩溃模块名称会直接写在里面。调试通过后改回False，这一步的返工成本只有一次重新打包。
4.2 现象：缺少vcruntime140.dll或libiomp5md.dll
原因：PyInstaller 只负责收集 Python 环境里的依赖，VC++ 运行库是否存在于目标机器完全取决于对方 Windows 的环境。干净系统缺vcruntime140.dll是常态；libiomp5md.dll是 Intel MKL 的运行时文件，属于 CPU 版 paddlepaddle 的高频遗漏依赖。
处理：在打包机上先装一遍 VC++ 2015-2022 x64 运行库再打包，PyInstaller 会把 vcruntime、msvcp 收集进产物；libiomp5md.dll如果没进 dist，直接从 Python 环境的paddle\libs目录复制到 exe 同级。这个方法看着粗暴，但在现场救急时是最高效的兜底。提前预防的办法是在干净的虚拟机里跑一次完整流程，把「缺 dll」这类环境问题全部暴露在交付之前。
4.3 现象：提示No such file or directory: 'models/det/inference.pdmodel'
原因：模型路径用了纯相对路径，而 exe 的工作目录不是 dist 目录。客户从桌面快捷方式启动时，工作目录是桌面，models当然不存在。
处理：所有资源路径走resource_path()归一化，启动时补os.chdir()切到 exe 所在目录。排查时可以先在代码里打印os.getcwd()和sys.argv[0]的实际值，不要凭猜测改代码。这个坑在 onedir 和 onefile 下表现不一样：onedir 是找不到身边的 models 目录，onefile 是临时解压目录里根本没有 models（因为datas配漏了），两种场景的修复方式也不同，先分清再动手。
4.4 现象：打包好的 exe 被 360 或 Defender 直接杀掉
原因：PyInstaller 产物带有明显的「Python 打包壳」特征，UPX 压缩后这个特征更重，无签名的 exe 在杀软眼里和可疑程序长得一模一样。
处理：先关掉 UPX（upx=False）重新打包，大量误报会消失；还报毒就放弃 onefile、改用 onedir 目录形态；再不行换 Nuitka 编译方案。加壳、混淆这类操作只会让启发式查杀更敏感，不要在这条路上投入时间。给客户交付时，提前说明「无签名 exe 首次运行可能被杀软拦截」，让客户点一次「允许」，比事后解释省心得多。
4.5 现象：exe 体积 500MB，启动还要十几秒
原因：打包机上装了 GPU 版 paddlepaddle，CUDA、cuDNN 动态库被全量收集；或者matplotlib、scipy这类开发期依赖没排除。
处理：换 CPU 版 paddlepaddle 重装，这是最大的体积开关；excludes里补上不用的库；模型再换成 PP-OCRv4 而不是新版大模型。排查时先用 PowerShell 统计 dist 下各子目录大小，确认体积集中在哪个模块：
Get-ChildItem dist -Directory | ForEach-Object { "{0:N1}MB {1}" -f ((Get-ChildItem $_ -Recurse | Measure-Object Length -Sum).Sum / 1MB), $_.Name }看到具体是paddle还是opencv占了主要空间，再针对性处理。体积和识别速度通常是两个方向，先确认目标机器的 CPU 是否够用，再决定往体积还是往速度调。
5. 离线 exe 瘦身与报毒处理：从 300MB 到 150MB 的实践
5.1 先拆体积构成
一个典型的 PaddleOCR onedir 产物，体积构成大致是：paddlepaddle 计算库 120-180MB，opencv 组件约 60MB，Python 运行时和其余依赖 60-80MB，模型文件 15MB。想瘦身，先分清哪些是固定成本、哪些是可选成本。
最大的一刀是确认装了 CPU 版而不是 GPU 版。GPU 版光是 CUDA 相关动态库就能贡献 200MB 以上，而离线工具根本用不到 GPU，这笔体积纯粹是白交。第二步看 opencv：如果工具只做图片识别不做图像预览，可以把opencv-python换成opencv-python-headless后重新打包，能再少 20MB 左右。注意换包后cv2.imshow()这类 GUI 函数不可用，OCR 流程里一般用不到，影响有限。
开发期依赖也要清：matplotlib、scipy、IPython、jupyter、pandas只要代码里没显式引用，全部放进excludes。这些库在 PyInstaller 的静态分析里可能被间接引用，不主动排除就会跟着进包。每排除一个，就重新打包跑一遍完整流程，确认 OCR、结果导出、GUI 三个主链路没被误伤。
5.2 UPX：省下来的体积，用报毒风险换
PyInstaller 在命令里带个--upx-dir就默认启用 UPX 压缩，看起来能压 30% 体积，但真实情况是 UPX 壳的进入点特征恰好是杀软启发式扫描的重点关注对象。我在内网交付时实测过同一份产物：upx=True时 360 秒杀，关掉 UPX 后同一台机器同一份代码打包的 exe 安静如常。
所以结论很直接：离线交付宁可体积多 30MB，也不要拿 UPX 赌杀软。如果确实想压缩，优先考虑排除大而无用文件，而不是上壳。补充一个细节：UPX 对 dll 的压缩有时还会破坏 Qt 或 opencv 内部的资源段，导致运行时找不到图标或插件，这类玄学问题比误报还难排查，不如从一开始就关掉。
5.3 Nuitka 备选：编译成原生代码，误报率低一个量级
PyInstaller 反复报毒、又不想给客户增加白名单操作时，值得花一小时试 Nuitka。它把 Python 源码翻译成 C 再编译成原生 exe，没有 PyInstaller 那种「解释器 + 压缩包」的结构特征，杀软误报率显著下降。常见打包命令：
python -m nuitka --standalone --mingw64 ^ --plugin-enable=tk-inter ^ --include-package=paddle --include-package=paddleocr ^ --include-data-dir=models=models ^ --output-dir=build main.py两个提前要知道的现实：Nuitka 编译 paddle 这种重库非常慢，普通笔记本顺利的话要 40 分钟到一小时，第一次跑别关电源；另外它要求打包机装 MinGW64 编译链，装好后一条命令走完。产物同样是目录模式，交付时整目录压缩发走。如果你的交付对象对报毒零容忍，Nuitka 值得提前评估，不要在交付当天才第一次尝试。
5.4 模型裁剪：关掉不需要的组件
PaddleOCR 3.x 起模型分 single 和 sharding 两种形态，single 是一个完整权重文件，sharding 拆成多个分片。打包整洁度上 single 优于 sharding，文件数少、目录干净；初始化速度上 sharding 略快。对离线 exe 而言，两者体积差异只有几 MB，怎么选看代码里model_dir指向哪个目录。
更实用的裁剪是直接去掉方向分类器：大部分正常拍摄的票据、截图不需要 180 度旋转，初始化时use_angle_cls=False，同时不把models/cls目录放进打包，省掉约 1MB 模型和几毫秒的推理时间。这是性价比最高的一刀，优先用它。裁剪后记得回到第 2 章的断网验证流程，跑一遍正常样本和旋转样本各一张，确认关闭方向分类器没有引入误识别。
6. 交付前验证：断网裸机上走完最后三步
6.1 关网、拷包、跑图
拿到新交付环境，我的固定流程是三步：VMware 建一台全新 Win10 虚拟机，不装 Python、不装 VC 运行库，把 dist 目录压缩包拷进去，禁用虚拟网卡，然后双击 exe 连续识别三张不同类型的图（票据、截图、扫描件）。这一步能同时验证 dll 是否齐全、模型是否内嵌、界面是否正常。连续三张是为了覆盖三种图像特征，单张通过不能说明问题。
交付给客户的压缩包里，除了OCR_Offline目录，至少要附上一份使用说明，里面写清楚：双击OCR_Offline.exe启动、首次运行被杀软拦截时选择「允许」、图片拖进窗口或点击按钮选择。别默认客户知道怎么操作，这一步省掉的解释成本会在现场十倍还回来。
6.2 抓隐性联网与缓存读取
有些 exe 表面跑出结果，背地里却还在尝试访问模型源。验证时打开一次 Process Monitor，过滤规则设置成：进程名为OCR_Offline.exe，操作里勾选 Network 相关项，路径过滤Path contains .paddleocr。如果全程没有任何网络连接，也没有读写用户目录下的.paddleocr缓存，才敢说这个 exe 是真正离线的。别跳过这一步，现场断网时超时重试的隐性等待是最难排查的翻车点。
6.3 批量测速：用数据决定取舍
性能问题建议在干净机器上量化。主程序里预留一个--bench分支，遍历 bench 目录下 50 张测试图，单进程跑完输出总耗时与单张均值：
if "--bench" in sys.argv: import glob files = glob.glob("bench/*.png") t0 = time.time() for fp in files: ocr.ocr(fp, cls=True) avg = (time.time() - t0) / len(files) print(f"total={time.time()-t0:.2f}s avg={avg:.3f}s")对 CPU 机器，PP-OCRv4 + MKLDNN 的单张耗时正常落在 0.6-1.5 秒。不管外面传的 tiny 版模型多快，都要以自己的目标机器实测为准，打包前拿这个数字决定模型版本、要不要保留方向分类器、要不要开 MKLDNN。如果平均值超过两秒，优先检查 CPU 是否被降频、杀软是否在实时扫描、以及 MKLDNN 是否真的生效——这三个因素对耗时的影响比模型版本更明显。
从那以后我每次交付前，都强制自己在断网裸机上完整走一遍这三步，哪怕只是改了个日志级别。模型路径和网络依赖这种东西，开发机永远不会暴露问题，只有把环境打回原形才能验证「离线」两个字是真的。希望帮到你。
本文还有配套的精品资源，点击获取
