始終使用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擁有Carleton大學的電腦科學學士學位，專精於前端開發，擁有Node.js、TypeScript、JavaScript和React的專業知識。Curtis熱衷於建立直觀且美觀的使用者介面，喜愛使用現代框架並建立結構良好、視覺吸引力的手冊。
