Mago 1.0 正式登場 — Rust 寫的 PHP 工具鏈讓 composer require 都尷尬了

過去十年，PHP 的工具鏈一直是個有禮貌但動作很慢的委員會：PHP-CS-Fixer 負責格式化、PHPStan 或 Psalm 負責靜態分析、PHP_CodeSniffer 負責 lint — 三個獨立程序、三份設定、三條 CI、三個會在 PR 留言的機器人。2026 年 5 月 2 日，carthage-software 推出了 Mago 1.0.0，這個委員會被一顆 25 MB、用 Rust 寫的單一執行檔取代，它做完三件事的時間，差不多就是 PHPStan 還在熱機的時間。

這個週末在 X 上瘋傳的數字很直接：一個 25 萬行、過去 PHPStan 要跑 90 秒的 Laravel 大型 monolith，Mago 用大約 8 秒就能完成同等規則覆蓋的分析，整個 repo 格式化不到 2 秒，記憶體尖峰遠低於 1 GB。因為 Mago 是無 PHP runtime 依賴的單一靜態執行檔，可以乾淨塞進 Docker 映像檔、GitHub Actions、pre-commit hook，不需要 autoloader、vendor 目錄、也不會卡 PHP 版本。

一、為什麼是 Rust，為什麼是現在

Mago 是第一個被廣泛採用的 PHP 工具，作者直接斷言瓶頸不在 PHP 語言本身，而在 host。PHP 跑 PHP 應用程式很棒，但每次 CI 用來 parse 別人 50 萬行 PHP，就沒那麼棒了。把 AST、型別推導、規則引擎搬到 Rust，Mago 拿到的是多核平行、零成本抽象與瞬間啟動。同樣的洞察催生了 Biome（JS）、Ruff（Python）、Oxlint，現在輪到 PHP。

二、1.0 真正帶來的東西

1.0 凍結了 mago.toml 設定格式，承諾規則 ID 穩定，這樣你的 PR 留言不會每升一版就大洗牌，並提供有文件的 plugin API。有真正的 LSP server，不是包了 CLI，所以 PhpStorm 與 VS Code 的診斷延遲低於 100 毫秒。Formatter 走 gofmt 路線，幾乎沒有可調旗標，「公司風格指南」這種爭論直接消失。靜態分析覆蓋大致對應 PHPStan level 8/9，還多了一些 Mago 自家的 lint，特別是 PHPStan 在 union type 與泛型推導上仍會誤判的部分。

三、對你的資料庫 / 後端的意義

如果你維護的是用 PDO 連 MySQL 或 PostgreSQL 的 Laravel、Symfony 或原生 PHP 專案，最直接的紅利是打開 Mago 的 SQL 字串 lint：它會抓出把變數直接串接進 query 字串的寫法（也就是今天這份報的安全段，LiteLLM 剛剛因此中槍的同一個 bug 類別）。再搭配 Mago 可以自動 scaffold 的 declare(strict_types=1)，多數團隊在第一週就能看到「不小心被注入」這類缺陷的數量明顯下降。

四、CI 的算術

如果你的 monorepo 串接 CS-Fixer + PHPStan + PHPCS、每次 push 燒掉 ~3 分鐘，三者全部換成 Mago 通常會落在 ~20 秒。一個一天 60 個 PR 的團隊，每天能省回大約 3 個工程師工時。代價是 tools/ 裡多一個執行檔。

我的觀點

我做 PHPStan 死忠用戶很多年，這週要換了。這件事的啟示比 PHP 還大：當一個語言生態系的核心開發工具，仍然用 host 語言寫的時候 — Python、Ruby、PHP 都是 — 對任何願意花一個週末動 Rust 編譯器的人來說都是套利機會。PHP 剛拿到一個快十倍的 CI，程式碼品質的下限被往上拉了一級，下次團隊 code review 的爭論不會再是「分析器為什麼沒抓到？」，而是「為什麼沒設成存檔時自動跑？」