作者：默思編輯部 發布：2026-06-28
2026 年幾項標準化比較顯示，Pyright 在型別規範相符度測試中達到 98%（139 項測試中通過 136 項），mypy 則只有 58.3%（139 項中通過 81 項）——這個差距相當顯著，代表 Pyright 對 Python 官方型別提示規範的支援更完整、更精確。
過去業界常說「Pyright 比 mypy 快 2 到 5 倍」，但這個說法已經有點過時——mypy 近期透過 mypyc 編譯（用 mypy 自己的編譯器把 mypy 本身編譯成原生程式碼）以及 1.18 版以後的優化工作，讓 mypy 在自己的程式碼庫上有大約 40% 的效能提升，讓兩者的效能差距已經沒有過去那麼懸殊。
除了速度與相符度，mypy 與 Pyright 有一項容易被忽略、卻影響深遠的行為差異：mypy 預設會跳過沒有型別註解的函式,也就是說沒有加型別提示的程式碼，除非啟用嚴格模式（strict mode），否則完全不會被檢查；Pyright 則預設會檢查所有程式碼，不管有沒有型別註解。這代表如果專案還在漸進式導入型別提示的過程中，兩款工具實際抓到的問題數量可能有明顯落差。
型別檢查工具的競爭版圖在 2026 年變得更加熱鬧：Meta 於 2025 年 5 月發表了 Pyrefly 的 alpha 版本；Astral（併入 OpenAI 前推出 Ruff 與 uv 的公司）則在去年 12 月釋出了自己的型別檢查器 ty，同樣用 Rust 打造，目標是延續 Ruff 那種「用 Rust 重寫、換來數量級效能提升」的成功模式。
對於全新專案，Pyright 在型別規範相符度、速度與 VS Code／Pylance 整合三方面都具備優勢，是目前較推薦的預設選擇。但如果專案的 CI 流程已經圍繞 mypy 建置、依賴特定的 mypy 外掛（例如 Django-stubs、SQLAlchemy 的型別外掛），或是身處大型 monorepo、遷移成本過高，繼續留在 mypy 也完全合理，沒有急迫的遷移壓力。
型別檢查工具的選擇，不應該只看單一 benchmark 數字——專案現有的外掛生態依賴、團隊熟悉度、CI 流程整合成本，往往比抽象的相符度或速度差距更關鍵。對於正在學習 Python 型別系統的開發者而言，理解不同工具「預設行為」上的差異（例如是否檢查未標註型別的程式碼），會比單純比較效能數字更有實務價值。