PP-OCR 是我这几年用得最顺手的 OCR 引擎精度高、模型体积也相对克制但平时基本都是跑在 Python 服务里。我上周干了一件有点折腾的事把 PP-OCR 装进浏览器最后只用一个 HTML 文件壳子就能在页面里完成从图片到文字的全流程识别不依赖任何后端服务。这篇文章就把完整思路、踩坑记录和可直接抄作业的代码结构写出来。这个东西具体能做什么你在本地浏览器里打开页面点选一张截图画面里的中文、英文、数字就会被检测出来并输出带坐标的文本块。整个过程发生在你电脑的内存里没有一张图片被上传到服务器。对做前端工具、内部系统、离线归档或者单纯不想维护 OCR 服务的同学来说这是一个非常实用的路线。1. 为什么非要在浏览器里跑 OCR1.1 后端 OCR 服务不是万能的以前做文字识别最经典的做法是拿 Python 起一个 Flask/FastAPI 服务调 PaddleOCR 或者 Tesseract前端把图片传过去再拿结果。这套方案在稳定性和吞吐量上没有问题但有几个让人头疼的场景内网隔离环境里OCR 服务部署麻烦Python 环境、模型文件、GPU 驱动、依赖库随便哪个不兼容都要折腾半天。有隐私要求的业务比如病历、合同、身份证件用户不愿意把图片传到服务器你作为开发者也不想去碰这些敏感数据。临时工具类的需求比如一个写给自己用的截图转文字小页面为它单独维护一个后端进程太浪费。多人协作的桌面工具如果能做到一个 HTML 打开就能用分发成本几乎为零。我在实际项目中就遇到过上面所有情况。后来开始认真研究浏览器端推理发现这条路不仅走得通而且效果比想象中好得多。1.2 浏览器端 OCR 的三种可行路线先给结论浏览器里跑 OCR 不是天方夜谭目前有三条主流路线按成熟度排列如下方案核心引擎部署难度精度体积适用场景Tesseract.jsTesseract OCRC 编译为 WASM低中文一般中文包约 15~25MB简单场景、英文识别Paddle.js 官方方案PP-OCR 模型 Paddle.js 运行时中高模型约 10~15MB量化后百度系项目、快速集成ONNX Runtime WebPP-OCR 转 ONNX 模型中高高模型约 20~40MB追求可控性和通用性Tesseract.js 优点是集成最简单但中文识别精度和 PP-OCR 有明显差距尤其碰到带角度、带复杂背景的截图时漏检率和误检率都比较高。Paddle.js 是百度的官方方案和 PP-OCR 是同一个生态精度有保障但它对项目结构有一定约束我想把它完全塞进一个纯 HTML 文件里不太灵活。我最终选的是 ONNX Runtime Web 这条路线。原因很简单模型是我自己转的运行时是通用的 ONNX 格式以后也可以直接换其他模型不会被某个框架锁死。至于模型精度PP-OCR 转 ONNX 之后识别效果几乎没有损失只要转换参数调对和 Python 端跑出来的结果基本一致。1.3 单 HTML 文件的可行性分析你可能会想一个 HTML 文件要跑完整 OCR模型文件往哪里放这里需要先厘清一个概念真正的“单文件”有两种理解。一种是把模型以 Base64 形式内嵌进 HTML这样确实只有一个 .html 文件但体积会膨胀三分之一左右而且页面启动时要先解码几十 MB 的字符串体验很差。另一种是把 HTML、JS、WASM 运行时、模型文件都放在一个文件夹里用相对路径相互引用。这种情况下 HTML 本身是单入口虽然严格说不算单一文件但分发时打一个压缩包用户解压后双击就能用体验接近单文件。我实际做的是第二种方案。如果你真的需要严格单文件可以写一个小的打包脚本把模型转成 Base64 塞进 HTML代码层面只是多一步解码后面我会提这个思路。平时开发调试时建议用文件夹模式不然每次改一行代码都要重新解码一次几十 MB 的二进制真的很浪费时间。2. 技术选型PP-OCR 模型结构与 ONNX 转换2.1 PP-OCR 为什么是三个模型在协作PP-OCR 不是一个大而全的神经网络它是典型的“检测 方向分类 识别”三段式流水线。理解这一点非常关键因为后面每一步推理和后处理都是围绕这三个模型展开的检测模型Det输入一整张图片输出若干个文本框的坐标。它负责找到“哪里有字”。方向分类模型Cls把检测出来的每个文本框小图单独送进去判断文字是不是旋转了 180 度或者倒置。它负责修正“文字方向对不对”。识别模型Rec把修正后的文本框小图转成字符串。它负责回答“文字是什么”。为什么要拆成三个而不是端到端一步到位因为这样每个模型的结构都更简单训练数据可以分别优化而且工程上可以灵活替换。比如你只识别印刷体检测和识别模型可以固定方向分类模型可以直接去掉推理时间立刻减少一截。我之前用 PP-OCRv4 做转换实验这套管线在中文场景下非常成熟。如果你对版本不敏感用 v3 或者更早的版本也问题不大但建议直接用 v4识别准确率和检测框稳定性都有提升。2.2 从 Paddle 模型到 ONNX 的转换细节PaddleOCR 官方仓库提供的是 Paddle 格式的 inference model浏览器端认的是 ONNX 格式所以第一步必然是模型转换。这里要用到 paddle2onnx 这个工具。转换之前先下载官方预训练模型以 PP-OCRv4 中文模型为例需要三个ch_PP-OCRv4_det_inferch_ppocr_mobile_v2.0_cls_infer或新版方向分类模型ch_PP-OCRv4_rec_infer下载完是三个文件夹每个文件夹里有 inference.pdmodel 和 inference.pdiparams 两个文件。转换命令类似这样paddle2onnx \ --model_dir ./ch_PP-OCRv4_det_infer \ --model_filename inference.pdmodel \ --params_filename inference.pdiparams \ --save_file ./ch_PP-OCRv4_det.onnx \ --opset_version 12 \ --input_shape_dict {x:[-1,3,-1,-1]}这里有两个参数特别值得说。第一个是--opset_version我实测下来用 12 或者 13 兼容性最好ONNX Runtime Web 对这两个版本的支持非常完整。如果版本太高有些算子可能在 WASM 后端还没有完整实现跑起来会报“Unsupported Operator”之类的错误。第二个是--input_shape_dict这里写成动态 shape即-1表示任意尺寸。检测模型输入的图片尺寸是可变的识别模型一般固定为[1, 3, 48, 320]方向分类固定为[1, 3, 48, 192]。转换完成后可以用 onnxruntime 的 Python 包先跑一次推理确认模型没有转坏再进入浏览器端集成。这一步强烈建议不要跳过我在转换阶段踩过不少坑后面统一说。2.3 模型量化从 40MB 到 10MB原始模型转换成 ONNX 后检测模型约 20MB识别模型约 20MB方向分类很小加起来接近 40MB。浏览器里跑虽然能接受但首次加载会比较慢。这时候 int8 量化就是一个很好的优化手段。采用 onnxruntime 自带的量化工具可以把模型体积压到原来的四分之一左右。识别速度会有明显提升精度损失在可接受范围内。量化命令大概长这样from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic( ch_PP-OCRv4_rec.onnx, ch_PP-OCRv4_rec_int8.onnx, weight_typeQuantType.QUInt8 )量化之后的模型跑在 WASM 后端上速度提升大概有 20% 到 40%具体取决于 CPU 和图片内容。需要注意量化只针对权重推理时核心计算还是走浮点所以精度损失不太大但也不要指望完全无感。如果识别结果出现个别文字读错可以先试试不量化的版本看是不是量化导致的。注意方向分类模型尽量不要量化。它本身非常小量化带来的体积收益几乎可以忽略反而可能因为低比特权重影响方向判断一旦方向判错后续识别结果就会完全错乱。3. 浏览器端实现从加载模型到文字输出3.1 工程结构普通模式与单文件模式先看文件夹模式。我的典型目录结构是ocr-in-browser/ ├── index.html ├── js/ │ ├── ort.min.js # ONNX Runtime Web │ └── main.js ├── models/ │ ├── det_int8.onnx │ ├── cls_int8.onnx │ └── rec_int8.onnx └── dict/ └── ppocr_keys_v1.txt # 中文字符表-index.html 负责页面布局和文件选择main.js 负责整个识别流程。如果你要做严格单文件模式做法是把 ort.min.js 和三个 onnx 模型都转成 Base64 字符串放进一个 HTML运行时先解码再创建 ArrayBuffer喂给 ONNX Runtime 的InferenceSession.create。这个方法理论可行但初学时建议先用文件夹模式把流程跑通再考虑打包。3.2 初始化 ONNX Runtime 与加载模型ONNX Runtime Web 有两种后端执行方式WebGL 和 WASM。我实际测试下来在小模型和 CPU 推理场景下 WASM 后端更稳定WebGL 在某些浏览器上精度反而会出现问题而且 WASM 支持多线程后速度并不慢。初始化 Session 的核心代码const ort window.ort; // 注意这里如果用本地相对路径保证 ort-wasm.wasm 文件可被访问 const detSession await ort.InferenceSession.create( ./models/det_int8.onnx, { executionProviders: [wasm], graphOptimizationLevel: all } ); const clsSession await ort.InferenceSession.create( ./models/cls_int8.onnx, { executionProviders: [wasm], graphOptimizationLevel: all } ); const recSession await ort.InferenceSession.create( ./models/rec_int8.onnx, { executionProviders: [wasm], graphOptimizationLevel: all } );这里有一个非常容易踩的坑如果通过 CDN 加载 ort.min.jsWASM 文件默认从同源 URL 获取如果通过本地文件路径打开 HTMLfile:// 协议浏览器会拦截 WASM 加载页面直接报错。所以你本地调试时必须起一个静态服务器比如python -m http.server 8080然后用 localhost 访问。如果你非要双击 index.html 打开就得把 WASM 文件以 ArrayBuffer 的方式内嵌或者用 create 配置里的wasmPaths参数指定绝对路径。3.3 图像预处理让图片变成模型认识的张量模型不是直接吃图片的。在把图片送入检测模型之前需要经过几道标准处理读取图片、转 RGB、按比例缩放、归一化、转成 NCHW 格式的 Float32 张量。PP-OCR 预处理细节我之前在 Python 端已经跑熟了浏览器端也是同一套逻辑。检测模型的训练尺寸是不固定的常见做法是限制最长边不超过 960同时保证尺寸是 32 的倍数。比如一张 1920x1080 的截图先把最长边 1920 缩到 960另一个边等比缩放成 540再向下取整到 32 的倍数是 512所以最终输入尺寸是 960x512。核心代码async function preprocessForDet(img) { const maxSide 960; const scale Math.min(1, maxSide / Math.max(img.width, img.height)); const targetW Math.round(img.width * scale / 32) * 32; const targetH Math.round(img.height * scale / 32) * 32; const canvas document.createElement(canvas); canvas.width targetW; canvas.height targetH; const ctx canvas.getContext(2d); ctx.drawImage(img, 0, 0, targetW, targetH); const imageData ctx.getImageData(0, 0, targetW, targetH); // RGB 转 CHW归一化到 [-1, 1] const { data, width, height } imageData; const channelSize width * height; const tensorData new Float32Array(3 * channelSize); for (let i 0; i channelSize; i) { const r data[i * 4] / 255; const g data[i * 4 1] / 255; const b data[i * 4 2] / 255; tensorData[i] (r - 0.5) / 0.5; tensorData[channelSize i] (g - 0.5) / 0.5; tensorData[2 * channelSize i] (b - 0.5) / 0.5; } return new ort.Tensor(float32, tensorData, [1, 3, height, width]); }这段代码里我把图片先画到 canvas 上再拿像素数据因为 canvas 是浏览器里做图像缩放和像素读取最通用的方式。要注意ctx.drawImage的缩放会丢一些细节但对于检测阶段够用了识别阶段会再单独把检测到的区域裁出来放大处理。方向分类和识别模型的预处理相似区别在于输入尺寸固定方向分类是 3x48x192识别是 3x48x320而且识别模型通常还要做一定的归一化和字符归一化这些细节在 PaddleOCR 官方文档的“模型推理”部分都有说明直接照抄即可。3.4 检测框生成从概率图到文本框坐标检测模型的输出不是直接的一批坐标而是一个概率图probability map需要对它做后处理才能得到文本框。PP-OCR 用的是 DBNet 结构后处理的核心是先对概率图做二值化再用连通域找轮廓最后通过 unclip 算法把轮廓外扩成文本框。浏览器端的后处理代码可以和 Python 端几乎一样只是把 numpy 操作改成纯 JavaScript或者用一个小型矩阵库。我的简化实现思路是拿到检测模型的输出张量shape 是[1, 1, H, W]通过 sigmoid 函数把值映射到 0 到 1。设定一个阈值常见值是 0.3大于阈值的像素视为文字区域。对二值图做膨胀操作把断开的文字笔画连起来。用扫描线算法找到所有连通域每个连通域就是一个候选文本框的掩码。使用 unclip 算法将掩码区域扩展一定比例得到最终的四边形坐标。实现连通域和 unclip 是这次开发里最复杂的一部分。如果你不想重复造轮子可以直接搜“JavaScript connected components with union-find”这类成熟代码再结合 PP-OCR 的 Python 后处理源码翻译一遍。我的经验是这一步直接决定检测框的准确性值得多花时间调试。3.5 方向分类与文字识别最后的字符输出拿到检测框坐标后把原图中对应区域裁剪出来这个子图先送进方向分类模型。如果分类结果显示文字是倒置的就对子图做一次 180 度旋转再送进识别模型。识别模型输出的是一个概率矩阵需要做 CTC 解码简单说就是每帧取概率最大的字符索引然后去掉相邻重复和空白字符最后对照中文字符表得到字符串。字符表是 PP-OCR 官方提供的ppocr_keys_v1.txt内容包含常见中文字符、英文字母、数字和标点总共六千多个字符。这个文件需要单独加载识别时逐帧查表function ctcDecode(outputTensor, charList) { const data outputTensor.data; const [batch, seqLen, numClasses] outputTensor.dims; let lastClass -1; let result ; for (let t 0; t seqLen; t) { let maxIdx 0; let maxVal -Infinity; for (let c 0; c numClasses; c) { const val data[t * numClasses c]; if (val maxVal) { maxVal val; maxIdx c; } } if (maxIdx ! 0 maxIdx ! lastClass) { result charList[maxIdx - 1]; } lastClass maxIdx; } return result; }这里有个常见的坑CTC 解码里的lastClass去重逻辑需要小心处理如果两个相同字符之间隔了一个空白符那它们不应该被合并。我写的这段代码是为了保持简洁真实生产环境建议还是完整实现 blank 标签的判断逻辑否则“你好”可能被识别成“你你你 好”或者“你好你”等奇怪结果。3.6 完整流程串起来整个推理流程可以画成一条线用户选图 → 图片解码 → 检测预处理 → 检测推理 → 后处理得到框坐标 → 循环每个框裁剪 → 方向分类 → 旋转 → 识别预处理 → 识别推理 → CTC 解码→ 把结果和坐标标注在页面上。用伪代码表示就是const image await loadImage(file); const boxes await detectTextBoxes(image, detSession); for (const box of boxes) { const crop cropImage(image, box); const angle await classifyDirection(crop, clsSession); const normalized angle 180 ? rotate180(crop) : crop; const text await recognizeText(normalized, recSession); results.push({ box, text }); } drawBoxesAndText(results);这个流程和我之前用 Python 写 PaddleOCR 的逻辑几乎一模一样只是语言从 Python 换成了 JavaScript底层从 Paddle Inference 换成了 ONNX Runtime Web。这也就意味着只要你对 PP-OCR 的分阶段流程有概念移植到浏览器并没有想象中那么难。4. 性能优化与内存管理4.1 打开多线程WASM 的共享内存配置ONNX Runtime Web 的 WASM 后端支持多线程推理默认是关闭的主要原因是多线程需要 SharedArrayBuffer而浏览器出于安全考虑要求页面必须通过 COOP/COEP 响应头开启跨源隔离。如果你只是在本地实验可以不加这些头单线程跑起来再说。如果你想要真正的多线程提速需要在服务器配置里加上Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp开启了跨源隔离之后创建 Session 时传入numThreads参数await ort.InferenceSession.create(./models/det.onnx, { executionProviders: [wasm], graphOptimizationLevel: all, numThreads: 4 });我实测下来四线程比单线程检测阶段能快两倍左右识别阶段提升相对有限因为识别模型的单张输入尺寸很小线程调度的开销占比更高。这里不要盲目追求线程数2 到 4 线程是性价比最高的区间太多线程反而会带来上下文切换开销。4.2 图像缩放策略先小图检测再大图识别检测模型输入限制最长边 960如果原图是 4K 分辨率直接缩到 960 再检测小字区域可能会被压缩得看不清检测框会漏掉。解决思路是检测阶段用一个中等缩放比例识别阶段再把检测到的区域裁出来原分辨率识别。实际操作中我用的是两级策略检测阶段限制最长边 1280比默认 960 略大检测更准保证文字区域不至于太小。识别阶段裁出来的子图不额外缩小直接送识别模型必要时保持原分辨率。如果图片太大比如超过 4000px先缩到最长边 2000 再检测避免内存爆炸。这个策略本质上是在“检测召回率”和“内存占用”之间做平衡。PP-OCR 检测模型本身就是为多尺度设计的稍微放大输入尺寸对精度有帮助但代价是推理时间线性增长。4.3 内存复用与对象复用浏览器端运行 OCR 最大的隐患是内存频繁分配。比如每张图片都新建一个巨大的 Float32Array识别几百个文本框时又不断创建 Tensor浏览器 GC 一旦跟不上页面就会卡顿甚至崩溃。几个有效的优化手法预分配 Tensor 缓冲区检测模型输入尺寸每次虽然不同但可以复用 ArrayBuffer 的池子避免频繁 new。用session.release()释放不再使用的 Session比如切换模型版本时不要留着旧 Session。识别阶段循环裁剪图片时尽量用同一个 canvas 对象反复绘制而不是每次 new 一个 canvas。大批量识别时把过程放到 Web Worker 里避免主线程被推理任务阻塞导致页面白屏。Web Worker 这一点提一下实现思路把 ort.min.js 和 main.js 放到 worker 里加载主线程只负责传图片数据、接收结果。因为 ONNX Runtime 的 WASM 多线程和 Worker 结合得好还能进一步减少 UI 卡顿。我第一版是直接在主线程跑的识别期间用户完全无法操作页面切到 Worker 之后体验明显提升。4.4 模型缓存第二次打开不再下载浏览器每次刷新页面都要重新加载几十 MB 的模型用户体验很差。ONNX Runtime Web 本身不提供模型缓存能力但我们可以借助浏览器的 Cache API 或者 IndexedDB 手动缓存模型文件。我是用 Cache API 做的const cache await caches.open(ocr-models-v1); const cachedResponse await cache.match(./models/det_int8.onnx); if (cachedResponse) { const buffer await cachedResponse.arrayBuffer(); session await ort.InferenceSession.create(buffer, options); } else { const response await fetch(./models/det_int8.onnx); cache.put(./models/det_int8.onnx, response.clone()); session await ort.InferenceSession.create(await response.arrayBuffer(), options); }这样第一次加载还是慢之后刷新就直接从缓存里读二进制加载时间从几秒降到几百毫秒。这个优化在做本地工具类的页面时非常重要因为用户会频繁打开关闭页面每次等几十秒谁都会崩溃。5. 常见问题与排查技巧实录5.1 WASM 加载失败多半是路径或协议问题我在调试中遇到过无数次的报错是Cannot find module onnxruntime-web或者 WASM 文件 404。这类问题根源不外乎三个ort.min.js 路径写错尤其是使用相对路径时HTML 文件所在目录和你以为的目录不一致。wasm 文件路径不对ONNX Runtime 默认会在 JS 文件的同级目录寻找 wasm 文件如果你的目录结构不一样需要手动设置wasmPaths。直接双击 HTML 文件打开file:// 协议浏览器跨域限制导致 wasm 无法加载。排查顺序是先确认能不能访问到 ort.min.js再确认 wasm 文件路径最后确认是不是 file:// 协议。如果必须用 file:// 协议可以考虑把 wasm 文件转成 base64 内嵌或者用一个小工具把所有资源打包成单个 HTML。5.2 推理报错 Unsupported Operator算子版本不匹配这是模型转换阶段最容易遇到的问题。ONNX Runtime Web 的算子支持范围比 Python 的 onnxruntime 小特别是某些新版本 ONNX 算子比如GridSample、Multinomial等在 WASM 后端可能没有实现。我的排查方法很简单先用 Python 的 onnxruntime 跑一遍转换后的模型如果 Python 能跑通浏览器端报错那基本可以确定是算子兼容性问题。然后回到 paddle2onnx把--opset_version从 12 换到 13或者反过来换到 11重新转换测试。PP-OCRv4 的模型在 opset 12 下转换是最稳妥的如果不行可以尝试 v3 版本的模型。另外转换时加上--enable_onnx_checker参数做一次模型检查能提前发现结构问题。5.3 检测框漏检或框不准确参数调节有门道浏览器端和 Python 端的后处理参数理论上应该一致但因为我用纯 JavaScript 重写了部分逻辑数值细节可能会略有差异。如果你发现检测框总是包不完整文字或者框太大把无关区域也包进来优先检查这几个参数box_thresh概率图阈值默认 0.3。调高一点比如 0.4框会更少但更准调低一点比如 0.2框更多但容易误检。unclip_ratio扩展比例默认 1.6 到 2.0。值越大框向外扩得越多适合文字离边缘近的情况但太大会把相邻文字框连在一起。输入图像尺寸如果检测输入最大边设置太小长文本可能因为压缩导致笔画断裂产生漏检。我每次都建议先拿一张边界情况明显的测试图比如带长句、带小字、带倾斜文字的截图跑一遍以肉眼效果为准逐步微调。5.4 中文识别结果乱码或漏字字符表对齐是关键识别输出乱码最常见的原因是字符表没对齐。PP-OCR 的识别模型输出类别数是 6623或根据版本略有差异其中索引 0 是空白字符索引 1 到 6622 对应ppocr_keys_v1.txt里的字符。如果你在解码时偏移量处理错误所有文字都会错位看起来像乱码。另一个容易忽略的问题是字符表文件编码。ppocr_keys_v1.txt默认是 UTF-8 编码如果页面用脚本读取时没有正确指定编码可能会导致中文全部变成乱码。建议用fetch读取并手动指定charsetutf-8或者干脆把字符表作为一个 JS 数组写死在代码里省得读取文件出问题。5.5 内存占用过高大图和重复推理是元凶当识别一张 4000x3000 的大图时浏览器内存占用可能直接飙到 1GB 以上主要消耗在检测特征图、概率图后处理、以及循环识别时不断创建的 Tensor 上。我实测下来最有效的控制手段是检测阶段把图片缩到合理尺寸不要贪大识别阶段单张子图尺寸必要时做限制每识别完一批文本立刻手动释放中间变量需要处理大批量图片时做完一张就setTimeout让出主线程给 GC 机会避免连续大任务导致浏览器崩溃。还有一个笨办法但很有效给页面加一个“重新识别”按钮用户操作一次后主动销毁 Session 并重新创建虽然简单粗暴但在长期运行的页面里确实能缓解内存泄漏问题。6. 实测效果与后续扩展方向6.1 不同机型的性能参考我在三台设备上做了简单测试模型用的是 int8 量化版本识别一张 1920x1080 的网页截图。设备检测耗时识别耗时30个文本框总耗时台式机 i7-12700约 300ms约 500ms1s 左右笔记本 i5-1135G7约 500ms约 700ms1.5s 左右低端 ARM 平板约 1.5s约 3s5s 左右这个性能对于工具类场景完全够用。如果是批量识别大量图片单线程瓶颈会比较明显建议配合 Worker 并行拆分任务。6.2 可以继续做的方向我做完这个项目后感觉还有几个很有意思的扩展方向表格识别PP-OCR 还提供表格结构识别模型转 ONNX 后同样可以跑在浏览器里把识别结果直接输出为 HTML 表格或 CSV。文档比对结合浏览器的 File API让用户同时选择两张图自动用 OCR 的坐标信息做逐行比对差异。离线 PWA配合 Service Worker 把模型文件缓存本地做成一个可安装的离线应用体验接近原生 App。接入其他 ONNX 模型ONNX Runtime Web 支持绝大多数视觉模型比如人脸检测、物体识别理论上都可以在同一个小页面里集成。这个路线的核心价值其实不只是“OCR”而是证明了一个观点现代浏览器的算力已经足够承载中等规模的深度学习模型推理。前端工具不再需要依赖后端服务数据可以完全留在本地这对隐私敏感场景和离线场景都是一个非常有意义的突破。最后再分享一点我的实际感受这个项目最花时间的不是浏览器端代码而是模型转换和踩算子坑的过程。一旦把模型转换和预处理后处理的逻辑理顺把运行时的加载路径调通整个系统其实非常稳定。我强烈建议想试水的朋友先从一个小截图开始跑通再逐步加功能避免一上来就处理超大图和高并发那样调试起来会很痛苦。