始终使用64位架构与IronOCR
IronOCR在后台进行内存密集型工作，因此32位（x86）版本会达到约2GB的内存上限，在处理大体积或高容量的文档时开始失败。 目标为64位（x64）是解决方法。
无论机器有多少RAM，32位进程的可用内存上限大约是2GB。 在这个限制下，OCR工作通常表现为：
System.OutOfMemoryException相同限制的其他症状包括OCR引擎执行期间的死锁、图像预处理中的资源饥饿、崩溃或未处理的异常，以及超时或失败的OCR结果。
压力来自于IronOCR对每个文档执行的操作：高分辨率图像渲染、临时光栅化、光学字符识别，以及使用机器学习模型进行深度文本提取（由SearchablePDF输出使用）。 这些每个都可能要求每个文档数百MB，而多页PDF、多页TIFF和300+ DPI图像会将其推得更高。
解决方案
选项1：在Visual Studio中设置平台目标
通过构建设置将项目切换到x64：
- 右键点击您的项目并打开属性。
- 打开生成选项卡。
- 将平台目标设置为
x64。 - 不勾选偏好32位。
选项2：从CLI或.csproj设置目标
发布到64位运行时以在构建时强制执行架构：
dotnet publish -c Release -r win-x64或者直接在您的.csproj中固定目标：
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>当项目是<Prefer32Bit>false</Prefer32Bit>行很重要：启用后，应用程序仍会以32位进程启动并继承相同的上限。
怀疑架构何时
如果您发现OCR任务意外挂起或崩溃、间歇性内存不足异常或高容量文档性能下降，首先检查架构。 如果您运行在x86上，请切换到x64，然后再调查其他内容。
在生产中保持一些习惯：
- **为生产目标x64：**这是唯一支持重型OCR工作负载的配置。
- **在x64上开发：**在x64上测试可以反映现实世界中的内存行为并早期发现问题。
- **构建64位Docker镜像：**确保基本镜像为
linux/amd64。
请注意，并发OCR工作会快速增加内存。即使是小文档，使用多线程或异步操作也可以快速增长。
如果您无法改变架构
当x64不可用时，将大文档分成更小的块，并以较低分辨率处理。 预计在性能和准确性之间会有所权衡。 针对32位项目的稳定支持正在调查中。
Curtis Chau 拥有卡尔顿大学的计算机科学学士学位，专注于前端开发，精通 Node.js、TypeScript、JavaScript 和 React。他热衷于打造直观且美观的用户界面，喜欢使用现代框架并创建结构良好、视觉吸引力强的手册。
