MooTool Next Electron 中文 OCR 方案评估实战：PP-OCRv6、Apple Vision 与 Tesseract.js 的选型依据与落地路径

• 桌面应用
• 开发工具

本文是 MooTool Next Electron 版「图片与截图文字识别」功能上线前的中文 OCR 方案评估实录。文中数据全部来自本项目在 2026-10-12 完成的对照评测（语料为 8 张固定合成截图，共 400 个汉字、684 个非空白字符），结论经过源码、评测脚本与测试用例的交叉印证。读完本文，你将掌握三套主流离线中文 OCR 技术路线（PP-OCRv6 small/tiny、Apple Vision、Tesseract.js）在同一语料下的真实准确率、热识别耗时与体积账本，理解「截图配置 vs 默认短边 736 配置」对延迟的显著影响，以及「模型体积 ≠ 安装包增量」的工程计算原则，并知晓 MooTool 最终采用的「macOS 走 Vision + Windows/Linux 走可插拔 PP-OCRv6 small」实施边界与可复现的完整命令流程。

评估背景与结论速览

在正式开发 图片与截图文字识别 功能之前，MooTool 团队需要回答一个具体的工程问题：Electron 跨平台桌面应用里，简体中文为主、兼有繁体与英文的截图文字识别，应该选哪套离线 OCR 方案？评估阶段明确约束为「不增加产品 OCR 功能、生产依赖或模型文件」，所有模型与实验运行时均安装在临时目录。

评估的最终结论可以浓缩为一句话：

macOS 优先考虑系统 Apple Vision；需要统一跨平台中文模型时优先 PP-OCRv6 small。tiny 可用于简体轻量模式，但不宜默认承担繁体识别。Tesseract.js 接入最简单，适合作为可选兼容后端，需明确选择简体或繁体。

本机实测环境与语料设计

所有对比数字都建立在同一台测试机、同一套固定语料和同一套评分口径之上，以保证方案之间可以横向比较。

测试环境

固定语料

语料来自 samples.json 描述的 8 张合成截图，均由 generate.cjs 通过 Electron canvas 与系统字体（PingFang SC / Songti SC）绘制：

• 浅色 20px、深色 16px、小字 12px；
• 12px 的 2x Retina（2000×480）；
• 繁体 20px、中英技术文本 18px、低对比模糊文本、宋体 22px。

每张图的行文均围绕本项目工具场景自编（例如「订单编号 001234，金额 ¥128.50，日期 2026-10-12」），没有使用任何用户真实截图。语料合计400 个汉字、684 个非空白字符。

评分口径与流程

• 汉字 CER：汉字序列的编辑距离除以参考汉字数；
• 全字符 CER：去除空白后的编辑距离占比，仍区分简繁、大小写、标点和货币符号；
• 数值越低越好，识别输出来自首轮；
• 耗时取后续三轮（每轮八图）的中位数；
• 各引擎依次运行，避免相互争用 CPU。

该口径由 summarize.py 实现：它读取各引擎 JSON 中的runs，对每个样本取pass == 0的输出计算逐图 CER，并以pass > 0的耗时取中位数，最终汇总为 summary.json。

三套方案的核心成绩单

下表是评测的最终成绩，全部数值可直接在 summary.json 中复查。

「0 / 400」不代表真实截图就能达到 100% 准确率。这是文档反复强调的边界：样本量小、均为横排印刷文本，未覆盖真实拍照、手写、竖排、透视、多栏、表格阅读顺序、罕见字及高压缩截图。另外，表格中的 RapidOCR 延迟来自参考 Python 流程，不是已完成的 Electron OCR 性能。

简繁差异与错误示例剖析

把总分拆到逐图看，会发现很多被平均值掩盖的关键细节：

• small 并非零误差：在八张图里没有汉字错误，但仍有两处非汉字差异（参见 rapid-small-screen.json 中繁体图与中英混合图的输出），说明数字、标点等也需要预览校对。
• tiny 的错误全部来自繁体图：该图汉字 CER 高达13.46%。例如「檔案名稱」中的「稱」被识别为「释」，部分繁体被改写成简体；其余七张图的汉字 CER 为 0%。tiny 因而只适合简体轻量路线，不能由总平均值掩盖繁体问题。
• Vision 的典型失误：漏掉「視窗設定」里的「窗」，将「邮箱」识别为「邮租」，技术文本中的v1被读成V1（原始输出见 vision.json）。
• Tesseract 三语同时启用时，部分简体被读成繁体，例如「识别」「图片压缩」「格式转换」；七张简体/混合图的汉字 CER 为6.90%，繁体图为 0%。
• Tesseract 只启用简体+英文后，七张简体/混合图的汉字 CER 降到1.72%，但繁体图反而升到55.77%。这直接证明了文档的结论：产品若采用 Tesseract，需要明确的简体/繁体选项，不能用「同时加载更多语言」代替语言选择。
• 12px 小字的关键实验：Tesseract 简体模式 CER 为 5.66%，相同文字保留 2x 像素后降为 0%；其他方案在这两张图里没有汉字错误。结论是截图应保留原始像素，不要先缩成 CSS 尺寸——这也成为后续 PP 后端「文字识别裁剪取原图」设计原则的直接依据。

Vision 首次识别延迟的特别提醒

Vision 原始输出在开发验证时用同一语料复测，汉字和全字符 CER 未变。新编译的程序首次识别曾触发约 70 秒的系统推理缓存编译，而已有缓存的进程首次识别约 0.2 秒。因此不能用热耗时估计首次使用等待时间，产品必须保留取消能力并为系统初始化留出更长超时（后续 image-ocr.md 中的 120 秒上限与此直接呼应）。

截图配置与内存开销

RapidOCR 原配置按短边 736 缩放（limit_type: min），窄截图会被大幅放大。评估引入「长边最多 1536」的截图配置（limit_type: max），同样使用四个 CPU 内部线程、一个跨算子线程，不使用 GPU 和方向分类器。参数细节可在 rapid.py 中看到：

params = { 'Det.limit_side_len': 1536, 'Det.limit_type': 'max', }

两种配置的成绩对比：

几点工程解读：

• 两种配置的汉字结果相同，但热识别耗时最多可差约2.5 倍（small 从 331ms 降到 132ms）。
• 峰值 RSS（见 rapid-small-screen.json 中的peakRssBytes）包含 Python、NumPy、OpenCV、模型和中间张量，不能当作 Electron 内存预算，Node 完整流程仍需独立验证。
• 1536 的上限对宽图/整屏图可能损失小字，需要追加测试，不能直接视为通用最优参数。
• 从评测中总结出的设计准则：文字识别裁剪应取原图，检测图可以独立缩放——这正是 ppOcrPipeline.ts 中detectorSize长边 1536、32 倍数对齐，而cropBox从原图做透视裁剪的实现依据。

离线体积账本：模型 ≠ 安装包

模型大小按下载后文件的实际字节数统计（单位 MiB = 1024²），既不是论文参数量，也不是安装包压缩大小。PP-OCR 的四个文件已验证 RapidAI 发布的 SHA-256，固定于 v3.10.0，校验值与字节数见 sizes.json 的ppOcrModels，下载脚本 download-models.py 会逐文件比对哈希并拒绝不匹配。

模型文件体积

运行时与打包裁剪

• ONNX Node（Mac arm64）：npm 平台子目录原为 85.30 MiB，内含两个内容相同的 dylib。保留绑定和其实际链接的libonnxruntime.1.dylib后为42.78 MiB；删除重复文件后，Electron 原生加载与一次识别模型推理已通过（见 electron-probe.json 与精简后的 electron-probe-minimal.json）。tiny + 此运行时约 48.81 MiB，small 约 72.50 MiB，尚未计入前后处理、公共 JS 依赖及签名开销，且这不是安装包增量测量。
• Tesseract.js：完整 core 包 43.17 MiB，API 包 1.35 MiB。Node 路径保留.js+.wasm、移除浏览器内联 core 后 core 为18.58 MiB（本机通过一张图的裁剪包验证，见 tesseract-pruned-probe.json）。三语 gzip 模型 + core/API 约25.96 MiB，首次缓存解压数据另需约 9.57 MiB；裁剪包尚未做各平台安装包验收。
• Vision：应用无需额外分发 OCR 模型，依赖系统框架与系统语言能力。「应用新增模型为零」不等于系统模型自身为零。
• 评估的 Python 环境仅用于评估，不建议把 Python/NumPy/OpenCV 参考环境直接捆进 Electron，其体积和依赖都不能按模型文件估算。

离线与断网验证

• PP-OCR small 使用同一模型覆盖简体、繁体、英文、日文等，tiny 不包含日语（这是官方模型范围，不是本轮逐语种验收结论）。
• 在sandbox-exec禁止进程网络出口时，small 与 Tesseract 各完成了一张图识别（见 offline-probe.json、tesseract-offline-probe.json），模型与语言文件全部走本地路径；默认自动下载行为必须在产品接入时显式关闭。Tesseract 未配置langPath会触发语言文件下载。
• 评估脚本中 RapidOCR 还通过覆写requests/socket强制离线，任何网络请求都会直接抛错（见 rapid.py）。

跨平台可用性与接入成本

两个重要的工程事实：

1. Intel Mac 的 ONNX 缺口是实锤：ONNX 官方支持表虽仍列 Mac x64，但本轮检查1.30.0 的实际 npm 文件没有该目录。因此不能只看支持表就承诺 Intel Mac 可用，可考虑 Vision、自编译原生 runtime 或单独验证 WASM 路线，不应直接假定解决。
2. Electron 探针只验证了「装得上」：Electron 探针仅加载 ONNX 原生绑定并运行一张空白张量（1×3×48×320float32 输入，输出形状[1, 40, 6906]），没有验证完整 JavaScript OCR pipeline。RapidOCR 的 Python 项目可作为算法参考，但 RapidOCRWeb 是 Python HTTP 服务，不是可直接引入的纯浏览器 OCR SDK。

建议的实施边界（五条硬约束）

评估文档给出了后续开发必须遵守的五条边界，它们在 image-ocr.md 与 ppocr-backend.md 中全部落地为实际行为：

1. 建立 OCR 后端接口，先接已有截图选区与图片库，返回文字、行位置、引擎名称和错误；显示可编辑预览，再由用户复制。对应源码为 ocr.ts 定义的OcrResult（含lines[].text/confidence/box）与OcrBackend接口。
2. macOS 可先用 Vision，避免新增模型下载和运行时体积；后续明确验证 Intel Mac helper、系统版本和中英/简繁支持。对应实现 ocrBackend.ts 中的VisionOcrBackend，其状态检测包含platform !== 'darwin'、macMajor < 13与 helper 可执行性三重判断。
3. Windows/Linux 中文方案优先 small，tiny 作为简体轻量选项；先完成一张真实截图的 Node 前后处理原型再决定统一启用 PP-OCR，不要把 Python 结果直接视作 Electron 接入完成。对应实现 ppOcrBackend.ts 的PpOcrBackend，其status()仅对win32-x64/arm64、linux-x64/arm64、darwin-arm64返回可用，且语言固定为['auto']——因为该多语言模型无法保证只输出简体。
4. 固定运行时和模型版本，按目标架构收集二进制、保留许可证及校验值；本地资源加载、工作进程隔离、闲置释放模型和不默认下载均作为接入要求。使用 ONNX 时显式关闭遥测，追加进程网络出口检查。落地为 ocrResources.ts：资源 manifest 要求schema === 1、runtimeVersion === '1.30.0'、modelVersion === 'RapidOCR-v3.10.0'，每个文件的 SHA-256 与字节数在加载前重新校验，两个模型的固定哈希硬编码在modelHashes中。
5. 接入前扩充真实语料：不同 DPI 的 Windows/Linux 截图、多栏、表格、竖排、拍照和罕见字；分别统计汉字、数字、标点及阅读顺序。Windows/Linux/Intel Mac 的包启动和断网识别是独立验收项。

当前决定：采用Vision + 可插拔 PP-OCRv6 small的方向，保留 tiny 的简体轻量模式，暂不把 Tesseract 三语自动模式设为默认。若目标是三平台输出完全一致，则选择统一 small 后端，但必须先解决 Intel Mac 的 runtime 路线。

评估落地的后续验证

• Electron 全流程实测：本机 macOS arm64、Electron 43.2.0 / Node 24.18.0 使用同一 8 张固定图，通过产品 IPC、私有快照和真实独立进程完成两轮识别，首轮汉字 0/400 错误、全字符 2/684 错误（0.29%），与此前 Python small 参考结果一致；16 次识别耗时中位数 501.5 ms，包含校验、进程/运行时/模型加载、识别、清理和退出，原始输出见 electron-mac-arm64.json。这与评测结论「小样本合成语料不代表任意真实截图」的边界保持了一致。
• 断网与内存探针：offline-mac-arm64.json 在 macOSsandbox-exec禁网环境下以独立 Node 传输适配器执行生产 worker 的真实资源校验与推理；memory-sample-mac-arm64.json 记录 2000×480 Retina 图打包进程 20ms 采样工作集峰值约 309.64 MiB（非精确峰值或上界）。
• 自动化测试体系：ocrService.test.ts 覆盖请求边界、私有快照与0600权限、全局并发、取消归属与临时目录清理；ocrBackend.test.ts 覆盖子进程超时/取消/输出上限与平台不可用；ppOcrBackend.test.ts 覆盖 PP 子进程的等待退出、取消/超时终止、响应上限与平台白名单。端到端层面，image-ocr.spec.ts 走真实后端完成「识别→编辑→复制→保存」全链路。
• 验收状态：首批 Vision 验收通过 394 项单元测试、12 项桌面回归及临时 macOS arm64 包内 5 项 OCR 测试；Windows/Linux 目标资源已分别准备检查，但目录包不能代替目标系统启动、截图权限、DLL/so 装载及断网识别验收，当前没有 Windows/Linux 实机结果，打包工作流新增 test-packaged-ocr.mjs 用于在目标 runner 上执行 OCR 桌面测试。

复现实验与产物清单

固定 PNG、参考文字、所有原始输出、统计与体积清单位于 ocr-evaluation/ 目录；脚本与依赖版本说明见 评估脚本 README。完整复现流程（从next/目录执行，模型与依赖全部装到临时目录，不污染仓库）：

# 1. 准备临时环境与固定版本依赖 python3 -m venv /tmp/mootool-ocr-eval/venv /tmp/mootool-ocr-eval/venv/bin/python -m pip install rapidocr==3.10.0 onnxruntime==1.31.0 npm install --prefix /tmp/mootool-ocr-eval/node tesseract.js@7.0.0 \ @tesseract.js-data/chi_sim@1.0.0 @tesseract.js-data/chi_tra@1.0.0 @tesseract.js-data/eng@1.0.0 python3 scripts/ocr-evaluation/download-models.py doc/ocr-evaluation/sizes.json /tmp/mootool-ocr-eval/models # 2. RapidOCR 两种模型 × 两种配置 /tmp/mootool-ocr-eval/venv/bin/python scripts/ocr-evaluation/rapid.py doc/ocr-evaluation /tmp/mootool-ocr-eval/models tiny screen /tmp/mootool-ocr-eval/venv/bin/python scripts/ocr-evaluation/rapid.py doc/ocr-evaluation /tmp/mootool-ocr-eval/models small screen # 3. Tesseract 三语与简体两种语言组合 node scripts/ocr-evaluation/tesseract.cjs /tmp/mootool-ocr-eval/node doc/ocr-evaluation node scripts/ocr-evaluation/tesseract.cjs /tmp/mootool-ocr-eval/node doc/ocr-evaluation chi_sim+eng # 4. Apple Vision（需 macOS + Swift 编译器） swiftc scripts/ocr-evaluation/vision.swift -o /tmp/mootool-ocr-eval/vision /tmp/mootool-ocr-eval/vision doc/ocr-evaluation # 5. 汇总统计 python3 scripts/ocr-evaluation/summarize.py doc/ocr-evaluation

复现注意事项（来自 README）：

• 比较耗时时应依次运行各引擎，每个引擎用全新进程先跑一遍热身，再跑三轮热识别；
• 重复实验应使用固定 PNG，重新生成字体截图会改变语料（npm run build && node scripts/ocr-evaluation/generate.cjs只适合在原始 macOS 字体环境上重建基准，栅格化可能随字体、OS 与 Electron 版本变化，生成物与既有语料不可互换）；
• 包体积字节数与裁剪探针仅针对已下载产物，不是 Electron 安装包尺寸测量，生产打包必须在每个目标 OS/架构上重新测试。

评估阶段没有修改产品行为或生产依赖；PP-OCR 完整 Electron 流程、最新体积与验收状态见 后端说明，首批开发见 图片与截图文字识别。

• 桌面应用
• 开发工具