EasyOCR 評測：乾淨文字表現出色，但尺寸一縮就掉隊，CPU 進程還會吃掉 1 GB 記憶體

EasyOCR 是 JaidedAI 為 Python 推出的即用型 OCR 函式庫：pip install easyocr、兩行程式碼，圖片裡的文字就能直接轉回字串。它採用 Apache-2.0 授權，支援 80 多種語言，並透過兩個 PyTorch 模型串成流程運作——先由 CRAFT 偵測器框出它判定為文字的區域，再由辨識器讀出每個框內的字元。預訓練權重會在你第一次呼叫時自動下載。從定位來看，它是可自架的 Tesseract 與 PaddleOCR 替代方案，而不是按頁計費的雲端 OCR API。

基本 API 很短：Reader(['en'])，接著 readtext()。但部署成本可不小——在這個環境中，PyTorch 本體大約佔 2 GB，而且剛啟動的進程峰值常駐記憶體約 1 GB。我以 CPU 執行 easyocr 1.7.2，渲染了 36 張英文 PNG 測試圖，並逐字元對照生成的正解標註來評分。尺寸與方向是造成 CER 大幅惡化的主因；儀表板測試也暴露了短 token 偵測與美元符號辨識的問題。

最明顯的失敗，來自人人都推薦的那個參數。rotation_info 在問題追蹤區裡有「旋轉圖片救星」的名聲，所以我拿同一句話做了三張正交旋轉的版本測試。當角度是 270° 時，它確實做到承諾的效果，將字元錯誤率從 0.83 降到 0.10。到了 180°，它只成功了一半：從 0.85 降到 0.67，但有一段詞被漏掉。到了 90°，結果反而更差，從 0.81 升到 0.92，而且辨識器開始吐出鏡像文字。同一個參數、同一組角度，卻有三種不同結果——所以把它打開，並不等於「旋轉問題已處理」。同樣的 36 張測試圖還顯示出一條明顯的字體大小臨界線、一個系統性的美元符號誤判，以及一個我原本以為的判斷，最後證明完全錯了。

像穿著風衣的兩個模型

EasyOCR 不是單一模型，而是一條由兩個模型串起來的流程；你得先知道是哪一段出錯，才知道該怎麼排查。

第一段是 CRAFT，也就是偵測器。它唯一的工作就是定位——判斷圖片中哪裡有文字，並回傳框的位置。它不會讀任何字元。第二段是 CRNN 辨識器——先做 ResNet 特徵提取，再接 BiLSTM，最後用 CTC greedy decoding——負責讀出每個框內的文字。兩者都跑在 PyTorch 上。CPU 模式下，辨識器預設會做動態 int8 量化，這也是為什麼它比原始參數量看起來更快、更輕。

實際影響是：EasyOCR 會有兩種完全不同的失敗模式，而且需要不同的修法。若偵測器根本沒框出文字，那不管怎麼調辨識器都沒用——字元根本沒進入流程。若框有出現，但字串錯了，那就是辨識問題，前處理也許還有救。幾乎我看過的每一篇「EasyOCR 漏掉我的文字」討論，都把這兩件事混為一談。

截至 2026 年 7 月 27 日查核，專案目前狀態為：29,825 顆 stars、528 個 open issues、Apache-2.0 授權，版本為 v1.7.2（2024 年 9 月），而主分支最後一次推送是在 2025 年 12 月。這些日期本身無法證明架構穩定或維護狀況良好。實際採用前，請確認與你的 Python / PyTorch 堆疊是否相容、維護者近期是否有回應，以及是否有與你的輸入型態相關的 issue。

OCR 常被聯想到 CAPTCHA 破解，但這不是本文的用途。這裡沒有，也不鼓勵，任何繞過 bot detection 挑戰的行為。本文的工作範圍，是把你有權閱讀的圖片與截圖中的文字讀出來。

我測了什麼，以及這些數字沒涵蓋什麼

測試集是我自己渲染的 36 張 PNG：35 張單行圖片，涵蓋七種字體、八種尺寸、七種對比度、七種傾斜角、三種正交旋轉與三種背景；另外再加上一張包含 19 個獨立標註元素的合成儀表板截圖。所有圖片都由同一個固定字串（Sphinx of black quartz, judge my vow. 1234567890——48 個字元，含大小寫、數字與標點）生成，並在寫入正解標籤的同一流程中產生，所以影像與標籤不可能彼此漂移。

準確度使用 字元錯誤率（CER）：以字元層級的 Levenshtein distance 除以正解長度。CER 0 代表完全正確；CER 0.10 大約表示每 10 個字元就有 1 個錯。標題數字採用含大小寫的 CER，並同時附上不區分大小寫的結果，因為實際上大部分「錯誤」都集中在大小寫。

但真正重要的是邊界條件：

• 只測英文。 使用的是 english_g2 辨識器。EasyOCR 宣稱支援 80 多種語言，我只測了一種。這裡完全無法代表非拉丁文字，而那正是公開學術 OCR 比較最常討論的領域。
• 只測合成圖。 是渲染文字，不是照片。沒有相機噪訊、JPEG 壓縮、光線或透視問題。
• 不含手寫。 專案本身也明確表示尚未支援手寫。
• 只測 CPU。 macOS arm64，gpu=False。機器上雖有 MPS，但 EasyOCR 只要不是 CUDA 就會用 CPU。GPU 效能完全沒測，因此本文不會出現任何 GPU 數字。
• 單機單版本。 easyocr 1.7.2、torch 2.13.0、Python 3.12。

所以：這些是控制單一變因後的曲線，精準顯示在乾淨、渲染過的拉丁文字上，哪裡開始失真。它們不是現實世界的語料成績，也不能取代那種評估。

證據是可檢查的，不是鎖在 notebook 裡。測試圖生成器與正解字串放在 tests/build_fixtures.py 和 tests/fixtures/ground_truth.json；辨識、計時與資源採集在 tests/run_easyocr.py；而 tests/metrics.py 則根據原始輸出計算本文報告的錯誤率。最終的辨識記錄與彙總指標保存在 artifacts/raw/。重跑這條流程，有助於確認這台機器與這個版本的表現；但它仍不能回答 EasyOCR 在你的手機照片、語言、版型或前處理流程上會怎麼表現，因此正式上線前，仍應加入具代表性的輸入，而不是把這些測試圖當成認證套件。

這個測試架構有一個值得提醒的坑，因為它差點讓我得出錯誤的大標題數字。我的第一版指標計算，把乾淨黑色 Arial 的 CER 報成 0.375，對最簡單的輸入來說這糟得離譜。問題不是 EasyOCR。本來偵測器把一行文字拆成了文字框與數字框，而我那個單純依 y 再依 x 排序串接的方法，竟把數字先接了上去。改成以行為單位分組（依垂直重疊分框，再由左至右讀取）後，乾淨字體的 CER 便回到約 0.04–0.10。如果你也要自己做 OCR 評測，這個坑同樣在等你。

安裝很小，依賴卻不小

pip install easyocr

就是這樣，但它對成本說得並不完整。套件本身很輕；真正被一起拖進來的是 PyTorch，大約 2 GB。接著在你第一次呼叫 readtext() 時，EasyOCR 會悄悄把權重下載到 ~/.EasyOCR/model/ ——總共 93.7 MiB，其中 CRAFT 偵測器佔 79.30 MiB（craft_mlt_25k.pth），英文辨識器佔 14.44 MiB（english_g2.pth）。

教學文章通常不會特別提醒這件事，所以你第一次執行時需要網路，還會先停下來下載；而任何容器化部署，不是把權重先包進映像檔，就是在冷啟動時承受這段下載。快取完成後，就能離線運作。

冷啟動 Reader()——模型從磁碟進入 RAM，再加上 int8 量化流程——在多次執行中花了 1.3–1.7 秒。之後只要：

import easyocr
reader = easyocr.Reader(['en'], gpu=False)
result = reader.readtext('screenshot.png')

就能直接跑。兩行、無需設定、也不用自己去找 checkpoint。名字裡的「easy」在這一段是名副其實的——真正的摩擦點都在依賴重量，不在 API。

乾淨文字的底線：字元幾乎全對，但大小寫不完美

七種系統字體，黑字白底，32 px，每次都用同一句話：

平均 CER 為 0.071；一旦把大小寫歸一，則降到 0.024。這個差距就是重點。EasyOCR 並不是在乾淨的拉丁文字上漏字，而是字形抓對了、大小寫抓錯了。

具體來說，它會把小寫 vow 在七種字體中的六種讀成 VOW（Comic Sans 則讀成 Vow）。Impact 甚至把 of 讀成 Of。另一個常見錯誤是標點：句尾句點在幾種字體裡會變成 : 或 _。只要不把大小寫算進去，Georgia 甚至是 完全正確。

這個形狀很有實用價值。如果你的下游是模糊比對、關鍵字搜尋，或把文字送給語言模型，大小寫翻轉幾乎不構成成本。但如果下游是拿來跟資料庫鍵值做精確字串比對，那就等於全錯。比較前先做大小寫標準化，EasyOCR 看起來的一半錯誤率就會消失。

Courier 表現最差（0.1042）也說得通：等寬字體會讓字元間距顯得不自然地寬，這對學過常見字距的 CTC 解碼器來說更難處理。

尺寸臨界點，剛好落在文件說的位置

readtext() 有一個文件化的參數 min_size=10，會丟掉低於 10 像素的偵測框。很多人會直接滑過去。但對於做截圖或 PDF 擷取的人來說，它是 API 裡最關鍵的數字，以下是我在掃描渲染字高時看到的結果：

從 12 px 到 8 px，CER 直接從 0.04 跳到 0.77，這不是緩慢退化，而是某個過濾條件照文件設定被正確執行，導致大約 10 px 以下的文字在預設 EasyOCR 下幾乎等於隱形。

最佳區間是 12–28 px，其中 16 px 時整體 CER 可到 0。超過 40 px 後，CER 又會略微回升——不是因為字元讀不出來，而是因為 vow → VOW 的翻轉又出現了。大字不一定更難讀，只是已經不再享受 16 px 時那種剛剛好的字距效果。

如果你正在從截圖擷取文字：先確認渲染字高，再怪模型。 在 HiDPI 顯示器上用 1× 擷取儀表板，或把 PDF 以 72 DPI 光柵化，常常會讓本文字掉到 10 px 以下。改成 2× 擷取或先放大再 OCR，就能避開一整類「EasyOCR 只讀出我一半頁面」的 bug 報告。如果兩者都做不到，再考慮降低 min_size——但要預期更多雜訊，因為這個過濾器本來就是用來壓掉垃圾偵測的。

旋轉：10° 容忍度，以及一個不對稱的修法

先看傾斜。小角度、Arial 32 px、預設設定對比 rotation_info=[90,180,270]：

預設 EasyOCR 對約 10° 以內的傾斜幾乎不受影響（CER ≤ 0.083），到了 15° 開始晃動，20° 便已崩壞。rotation_info 對傾斜完全無能為力，這在理解它的作用後其實合理——它只會針對你列出的角度重試，而 15° 的傾斜並不是 90、180 或 270。到了 10° 時，它甚至讓結果稍微變差（0.021 → 0.083），因為錯角度重試也可能在信心分數上勝出。

正交旋轉就更奇怪了：

同一個參數、同一組角度，卻有三種結果。

在 270° 時，rotation_info 的確做到了 issue 討論串 所說的效果：CER 從 0.83 降到 0.10，是個真正可用的結果。到了 180°，它只成功一半——CER 改善到 0.67，但 my vow. 這段詞直接被漏掉。到了 90°，結果反而倒退，從 0.81 變成 0.92，而原始輸出也說明了原因：辨識器回傳的是鏡像字串。VOW 變成 MOA，quartz 變成 zuuenb。把這些字串拿去照鏡子看，反而是對的，這很有趣，但對資料流程毫無用處。

我不是只看彙總指標，而是直接檢查原始預測，因為我第一個懷疑是「串接順序搞亂了」。但不是——那就是 EasyOCR 真正回傳的內容。

機制部分只能算推測，不是實測；我並沒有做旋轉慣例實驗。Pillow 以正角度逆時針渲染，所以只有 270° 的圖片剛好對上辨識器能處理的重試方向，而 90° 的情況則把最佳分數落在翻轉後的方向上。不管機制到底是什麼，實務上的結論都一樣：

這組測試顯示，不能假設 rotation_info 在不同方向上會對稱地發揮作用。請驗證你的輸入最常出現哪些旋轉；若能先在上游做方向正規化，那會是可行的緩解方式，但不是靠這三張渲染圖就能推導出來的必然要求。

我猜錯的那件事

我一開始以為，低對比度會是 EasyOCR 的軟肋。淡灰字印在白底上，這是 OCR 經典失敗案例，而且文件也提供了一條明確的救援路徑：contrast_ths=0.1 搭配 adjust_contrast=0.5，會把低對比度框重新用增強版本再跑一次，然後保留信心較高的結果。

但它從頭到尾都沒觸發，因為根本不需要。

CER 一路都沒離開乾淨區間，直到 Weber 0.14——也就是白底上的灰 220；那已經淡到我得瞇著眼看測試圖，才能確定文字真的有在上面。而對比增強欄位在每一步都和預設欄位完全相同，因為預設本來就成功了。

背景也說明了同樣的事。文字都是黑色：

在整組測試裡最吵的一張圖，反而是完美讀取。

但這個範圍很窄：這是純色、無拍攝噪訊的低對比測試，不是帶有感光雜訊與 JPEG 壓縮的實拍收據。在這組測試中，幾何與短 token 造成的失敗最嚴重；所測的色彩與合成噪訊變體並沒有。

真實場景：從儀表板截圖拉出數字

這其實就是多數 Python OCR 工作最後會變成的樣子。有人傳來一張內部儀表板的截圖，或者你正在對一個圖表很多、數字只以渲染像素存在的分析頁跑 Python scraping pipeline，而你要的是可用的數據值。

我渲染了一個「Sales Dashboard」視窗——深色標頭含標題與圓形頭像徽章、三個 KPI 面板、三個按鈕、一個 2×3 表格——並替全部 19 個文字元素 標上精確字串與像素框，再用框的重疊程度把 EasyOCR 的輸出對回去。

偵測召回率：19 個中抓到 16 個。 漏掉的三個是：

• 單字母徽章「A」
• 表格欄位 「Q1」
• 表格欄位 「Q2」

而 「Q3」有被偵測到。同一種字體、同一個大小、同一欄——偵測器保留了一個兩字元 token，卻漏掉另外兩個。對外觀很像的儲存格來說，偵測並不一致。由於這些執行結果是 deterministic，這不能被解讀成隨機的「擲硬幣」行為。相關的截圖品質問題可參考 #460。

在它抓到的 16 個元素裡，文字幾乎都完美：平均 CER 0.027，其中 13 個完全正確。標題、標籤、按鈕（"Save"、"Cancel"、"Export CSV"）、欄標，以及帶逗號的數字都能以 CER 0 回傳。1,284 也正確讀出，連逗號都在。

那三個不完美的讀取，全是同一種錯誤：美元金額。

四個美元符號裡有三個被看成了大寫 S。從視覺上說，這勉強算合理——但這代表你擷取出的每個貨幣欄位，都只差一個字元就變成垃圾，而單純的 float() 會全部報錯。

如果你的截圖流程含有短標籤或貨幣值，請先驗證可行的緩解方式，例如放大、加邊距裁切、限制欄位格式，或做符號感知的後處理。本文沒有測試這些方法，而一條把前導 S 直接改寫掉的 regex，也可能誤傷合法值。只有在 schema 與驗證規則能確保安全時，才應套用修正。

執行成本

同一台機器上的數字（macOS arm64、CPU、單一主機、在可能有並行負載下測得——請把它們當作形狀參考，而不是通用基準）：

最大的成本不是 94 MB 的權重，而是每個 worker 進程大約 1 GB 的常駐記憶體，再加上約 2 GB 的 torch 安裝。真正決定它能不能放進容器的，是這個數字；而這也是沒多少人會提的數字。

速度在簡單場景下是可以接受的。CPU 上單行乾淨文字的暖機延遲不到 0.1 秒，完全可用。但那確實是簡單場景：一行短、對比高的文字。網路上常見的 「EasyOCR 在 CPU 上要花幾十秒」 抱怨，多半是在處理整頁、多區塊的大型文件；我沒有在這裡重現它——那是不同工作負載，我也只是引用它，而不是聲稱自己證實了這點。

順手戳破一個小迷思：detail=0 不會讓 EasyOCR 更快。它只是把回傳值中的 bounding box 與 confidence score 拿掉而已，運算本身早就做完了。中位數只差 1 毫秒，這就是雜訊等級。

優缺點

優點

• 在乾淨、渲染過的拉丁文字上，字元召回幾乎完美——含大小寫平均 CER 0.071、不含大小寫 0.024，而且在 16 px 時可達到完整 CER 0。
• API 真的只要兩行。Reader(['en']) 再 readtext()，不用設定，也不用自己挑模型。
• 對對比度的耐受度比坊間印象高得多：乾淨文字一路到 Weber 0.14 都沒崩，帶雜訊／漸層／彩色背景也沒有明顯拖垮表現（高斯雜訊那張甚至完美讀取）。
• 在能偵測到的截圖元素上幾乎完美：平均 CER 0.027、16 個中有 13 個完全正確，連帶逗號的數字也沒問題。
• 結果具決定性。這裡所有準確度數字，在兩次完全獨立的進程執行中都 byte-identical；只有計時有變化。
• Apache-2.0、可自架，沒有供應商使用費；真正的成本在於運算、記憶體、儲存與佇列處理。

缺點

• 一旦低於文件中的 min_size=10，表現就會硬崩——8 px 時 CER 高達 0.77。小型 UI 文字預設下等於看不見。
• 對傾斜的容忍大約只到 10°，20° 左右就會崩掉。
• rotation_info 不是對稱的修復手段：270° 會恢復、180° 只恢復一部分，90° 反而更差，還會回傳鏡像文字。
• 偵測器會漏掉孤立短 token——例如單字母徽章與兩個 2 字元儲存格，但卻保留另一個格式相同的儲存格。
• 貨幣值的 $ 會系統性被誤讀成 S（4 個中有 3 個）。
• 每個進程約要 1 GB 常駐記憶體，再加上約 2 GB 的 torch 相依。
• 最新版本來自 2024 年 9 月；專案偏穩定，而不是高速演進。

適合誰，不適合誰

當你的輸入是乾淨、正向、大小合適的渲染文字時——例如截圖、UI 擷取、光柵化 PDF，或產生式報告——而且你想要一條沒有供應商使用費的 Python 自架流程時，應該評估 EasyOCR。本文的英文 CPU 測試結果適用於這條路線；照片、手寫與其他文字系統都需要另行測試。

如果你的輸入符合下列任一情況，就可以考慮放棄。照片——本文數字來自合成渲染文字，對相機噪訊、透視與光線毫無代表性。手寫——專案本身就沒宣稱支援。非拉丁文字——EasyOCR 雖然支援 80 多種語言，但我只測了一種，而公開學術比較才是那個領域的參考。任意旋轉的輸入——除非你會先自己做方向校正。記憶體受限的部署——每個 worker 就要一個 GB，累積很快。

在選 OCR 之前，先檢查 DOM 和 network response。如果你要的數值本來就已經以結構化文字存在，那直接抽取原始來源，會比 OCR 少掉偵測與辨識兩道誤差。只有在像素是唯一可得表示時，OCR 才是正解。

替代方案，以及我們的技術棧該放在哪裡

EasyOCR 採 Apache-2.0 授權，可自架，沒有供應商使用費，但會有實際的運算與營運成本。PaddleOCR、Tesseract 與 vision-language model 沒有一起跑過這個基準，因此本文不會做頭對頭結論。

更有意思的比較，不是 OCR 對 OCR，而是你到底該不該做 OCR。

我看到的大多數截圖擷取工作，其實都是在繞開一個不好抓的網頁——像是 JavaScript 渲染表格、需要登入的儀表板、或是網站刻意設阻。截圖再 OCR 感覺像是最省事的路，但你等於把本來就存在的結構化文字丟掉，然後再付出一筆美元符號稅，只換回一個更差的版本。

作者註： Thunderbit 是我們用來擷取網頁的託管方案。它沒有跑這些圖片測試。真正的界線在於來源表示形式：當網頁已有結構化資料時，應優先做 DOM／network 擷取；只有在像素是唯一來源時，才評估 OCR。

同一套測試平台的延伸閱讀：完整開源爬蟲比較、Crawl4AI 評測，以及更全面的 AI 驅動擷取，特別適合那些抗拒 selector 的頁面。

試用 Thunderbit 進行網頁資料擷取

結論

EasyOCR 值不值得用？如果你的圖片是正向的、字元高度至少 12 像素，而且你處理的是拉丁文字，那答案是肯定的。在這些條件內，它表現很好——乾淨文字的平均 CER 0.071，大小寫標準化後降到 0.024，16 px 時可完全正確，而且它的對比度穩定度比名聲還好。API 真的是兩行，輸出也具決定性，這在你排查流程時比很多人承認的都更重要。

但超出這些條件，它會以可預測、可學習的方式失敗。10 px 以下的文字會直接被 min_size 過濾掉。傾斜超過 20°，讀取會崩壞。rotation_info 只能修好一個正交方向，另一個只修半套，第三個還會因為鏡像文字而更糟。單字母與兩字元 token 會從偵測器中掉出來，而旁邊的鄰居卻安然無事。美元符號會變成字母 S。

這些測試圖的失敗，來自流程兩個階段：幾何層面的框漏掉或方向錯誤，以及辨識層面的美元符號混淆。把放大、方向正規化、加邊距裁切，以及符合 schema 的符號修正，都視為需要驗證的候選方案，而不是對所有情況都安全的固定解法。

只是別像我差點做的那樣，用一個壞掉的評測架構和一個你根本不理解的數字來測它。自己渲染測試圖，精準知道正解是什麼，然後找出你自己的臨界點。

試用 Thunderbit 進行網頁資料擷取 Get Started Free

常見問題

EasyOCR 的準確度夠不夠拿來做正式的截圖文字擷取？ 在合成儀表板上，成功對上的元素平均 CER 為 0.027，其中 16 個有 13 個完全正確。19 個元素中有 3 個沒被偵測到，而 4 個美元符號裡有 3 個變成了 S。這樣的結果是否可接受，以及放大或 schema-aware 修正是否有幫助，都必須在你的目標版型上再測一次。

EasyOCR 最小可以讀多小的字？ 實務上，大約是渲染字高 12 像素。readtext() 的 min_size=10 會丟掉小於 10 px 的偵測框，而且效果不是平滑下降，而是斷崖式下滑：8 px 時 CER 0.77、10 px 時 0.15、12 px 時 0.04、16 px 時是 0。我掃描時的乾淨區間是 12–28 px。如果你的來源是 1× 擷取的 HiDPI 截圖，或 72 DPI 的 PDF 光柵化圖，與其降低 min_size，不如先放大再 OCR，因為這個過濾器本來就是用來壓掉垃圾偵測的。

rotation_info 能修好 EasyOCR 的旋轉圖片嗎？ 不能穩定修好，而且不是對稱的。把同一句話做成三張正交旋轉圖，並設 rotation_info=[90,180,270] 時，270° 圖片能順利恢復（CER 0.83 → 0.10），180° 圖片只部分恢復（0.85 → 0.67，且有一段詞被漏掉），而 90° 圖片反而更差（0.81 → 0.92），還會回傳像 VOW → MOA 這種鏡像文字。它對小角度傾斜也沒用，因為它只會針對你列出的角度重試。與其依賴這個參數，不如先把方向校正好再呼叫 EasyOCR。

EasyOCR 需要多少記憶體與磁碟空間？ 權重檔案共 93.7 MiB，第一次使用時會下載到 ~/.EasyOCR/model/——其中偵測器 79.30 MiB，英文辨識器 14.44 MiB。測得的新鮮 CPU 進程峰值常駐記憶體是 984.5 MiB，此外還有約 2 GB 的 torch 安裝。冷啟動 Reader() 需 1.3–1.7 秒；之後在這台機器上，單行乾淨文字的 p50 約為 0.062 秒。detail=0 只改回傳格式，不改實測執行時間。

EasyOCR 可不可以商用？現在還有在維護嗎？ 它是 Apache-2.0 授權，屬於寬鬆且對商業友善的授權。以 2026 年 7 月 27 日來看，repo 有 29,825 顆 stars、528 個 open issues，最新版本是 2024 年 9 月的 v1.7.2，而主分支最後一次推送是在 2025 年 12 月。應該把它理解為穩定，而不是停更——架構已經一陣子沒大改，活躍度主要在 issue tracker。正式開發前，請自行確認最新的 授權 與版本狀態。