Chrome扩展上传PDF至Express/multer后端OCR性能优化问询

背景与当前流程 #

• 正在开发基于浏览器扩展的数据保护功能，要求AI工具上传文件前完成敏感信息（PII、密钥、金融数据等）扫描
• 当前处理流程：用户通过Chrome扩展上传文件 → 发送至Node.js/Express后端（用multer接收）→ 按文件类型提取文本 → 送入敏感数据扫描器 → 返回放行/拦截/脱敏决策

现有文件处理方案 #

• 文本PDF：使用pdf-parse提取文本
• DOCX：使用mammoth提取文本
• Excel：使用xlsx提取文本
• CSV/TXT：直接读取提取文本
• 图片：经sharp预处理后，用tesseract.js执行OCR识别
• ZIP/TAR等归档文件：递归解压后逐一扫描内部文件

当前瓶颈 #

• 图像密集型或大文件（10-50MB）的OCR处理速度慢，用户等待时间过长
• 扫描型PDF无法通过pdf-parse提取文本，必须走OCR流程，进一步拉长等待时长

拟优化方向 #

• 优先尝试直接提取文本，仅在必要时触发OCR
• 单独识别扫描型PDF，针对性处理
• 优化图像预处理逻辑，提升OCR效率
• 基于文件哈希值缓存扫描结果，避免重复处理
• 添加OCR超时机制，防止长时间阻塞
• 后续计划迁移至任务队列，实现异步处理

待解决的技术问题 #

1. Node.js后端处理扫描PDF的最佳开源OCR方案是什么？
2. pdftoppm搭配原生Tesseract CLI，与PaddleOCR相比哪个更适合生产环境？
3. 处理10-50MB的文件时，是否应该弃用multer.memoryStorage()，改用磁盘存储或对象存储？
4. 生产系统中，如何在后台执行全量OCR的同时，快速向用户返回风险决策？
5. 这类文件扫描流程的最优架构是什么？

恳请具备OCR流水线、文档扫描、DLP、浏览器扩展上传或文件检测系统实践经验的从业者提供建议。

内容的提问来源于stack exchange，提问作者Nishith Joshi