Cloud Run中Tesseract OCR输出异常，本地正常求排查方案

我们在Google Cloud Platform运行一条文档处理流水线：

• 从文档图片中提取裁剪图
• 处理裁剪图确保为黑字白底
• 将裁剪图传入pytesseract提取文本

多数情况正常，但部分裁剪图OCR结果错误，例如：

35LURC194-     -> output as SSLUBe404-
6                           6      

所有在Cloud Run上识别错误的案例，在本地运行都能得到正确结果。本地与Cloud环境差异如下：

已尝试的排查步骤：

• 确保pytesseract、torch、torchvision、Tesseract等关键包版本一致
• 为Cloud Run实例增加RAM和CPU
• 将容器Python版本升级至3.10.10
• 确认传入Tesseract的裁剪图在两地完全一致
• 反复核对本地与云端代码一致
• 在两地尝试不同OEM设置及正确的PSM（多行模式）

进一步排查方向 #

• 检查Tesseract训练数据/语言包差异：Debian Slim默认的Tesseract训练数据（如eng.traineddata）版本可能与Arch Linux上的不同，甚至是否存在自定义训练数据未同步到容器中。可在两地执行tesseract --list-langs验证已安装的语言包，对比训练数据的版本和哈希值。
• 核对图像处理依赖的底层库版本：PIL/Pillow、OpenCV等图像处理库的版本差异，或系统级图像解码库（如libjpeg、libpng）的版本不同，可能导致图像像素的细微差异（即使视觉上一致）。可在两地分别输出pip list查看Python库版本，用dpkg -l | grep libjpeg（Debian）或pacman -Q libjpeg（Arch）查看系统库版本。
• 验证Tesseract系统依赖库版本：Tesseract依赖Leptonica等系统库，Debian Slim的Leptonica版本可能与Arch上的存在差异。执行tesseract --version查看依赖库版本，对比两地的Leptonica版本号，若不一致，尝试在容器中编译安装与本地相同版本的Leptonica和Tesseract。
• 检查容器环境变量与系统locale：确认容器中TESSDATA_PREFIX环境变量是否指向正确的训练数据目录；同时检查系统locale设置（执行locale命令），Tesseract的字符识别可能受locale编码影响，确保两地locale一致（如en_US.UTF-8）。
• 在本地Docker中复现环境：拉取Debian Slim Buster镜像，在本地Docker中构建相同的运行环境，运行测试用例，看是否能复现Cloud Run上的错误。若能复现，即可排除Cloud Run平台的影响，聚焦到Docker与原生环境的差异。
• 开启Tesseract调试日志：在pytesseract的配置中添加--debug all参数，输出详细的识别日志，对比本地与云端的日志流程，查看图像预处理、字符分割、匹配等环节是否存在差异，定位问题节点。
• 检查图片DPI元数据：Tesseract对图像DPI敏感，容器中处理图片时可能丢失或修改了DPI元数据。使用ImageMagick的identify -verbose 图片路径命令，对比两地图片的DPI信息是否一致，若不一致，可在容器中手动设置图片DPI后再传入Tesseract。
• 替换Tesseract二进制版本：Debian仓库中的Tesseract版本可能较旧，尝试在Docker容器中手动编译安装与本地完全相同版本的Tesseract二进制文件，而非通过apt安装。

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