reviewdog：面向任意 linter 的 diff 感知自動化程式碼審查
自動程式碼審查工具與任何程式碼分析工具集成，無論程式語言如何。
秒懂
- 它是什麼？
- reviewdog 解析 linter 輸出，將結果過濾到補丁中改動的行，並發布為 GitHub、GitLab、Bitbucket 等平台上的審查評論。
- 適合誰用？
- reviewdog 是一個專注的工具，它把任意 linter 的文字輸出轉化為可操作的審查評論，前提是 linter 能輸出可解析的格式。它不試圖取代 linter，而是位於 linter 和程式碼託管服務之間，用 diff 決定報告什麼。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 2 天前。
- 用什麼語言寫的？
- 主要是 Go（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月14日）與我們的分析，不構成法律意見。
開源專案深度解析
reviewdog｜1｜reviewdog 對 linter 輸出做什麼
reviewdog 是一個 Go 命令列工具，將 linter 輸出連接到程式碼審查系統。它讀取 linter 或編譯器的標準輸出，用格式描述解析，然後針對 unified diff 過濾結果。只有補丁中新增或修改行上的發現才會被報告。該工具可以將這些發現發布為 GitHub、GitLab、Bitbucket 或 Gerrit 上的審查評論，也可以直接列印到終端用於本地使用。這種設計意味著 linter 本身不需要知道託管服務的任何資訊；reviewdog 負責轉換和 diff 過濾。
第 1 節在 reviewdog/reviewdog 的專屬觀察：這個專案使用 Go，預設分支是 master，授權標示為 MIT。README 把能力放在自己的命令、模組與資料格式中，不能只用一句產品描述取代這些邊界。README 未說明的效能上限、部署規模與相依版本，也不能由倉庫星數或描述推導。
針對 reviewdog/reviewdog 的第 1 個判讀，應從 README 列出的安裝或執行命令開始，保存命令使用的參數，再對照它宣稱的輸出、設定檔與錯誤訊息。若文章涉及 reviewdog 的版本行為，請以 GitHub Releases 的版本標記核對，並把本機環境、輸入資料與輸出結果分開記錄。這個核對只回答該功能是否按文件運作，不代表其他模組也有同樣結果。
第 1 節的判斷還要留意責任邊界：reviewdog/reviewdog README 有明確寫出的內容才可作為事實，沒有寫出的整合方式、容量數字或可靠性保證應保留疑問。對採用者來說，最有用的結果不是把功能清單全部列完，而是知道這個章節中的入口是否能在指定版本重現，以及失敗時哪一層留下可讀的訊息。
reviewdog｜2｜輸入格式：從 errorformat 到 SARIF
主要輸入格式是 errorformat，它是 Vim errorfile 格式的一個移植。使用像 %f:%l:%c: %m 這樣的小格式字串，reviewdog 可以解析許多工具產生的典型 file:line:column: message 輸出。對於常見工具，reviewdog 包含預定義的 errorformat；執行 reviewdog -list 會顯示哪些可用，-f 旗標選擇其中一個。除 errorformat 外，reviewdog 還接受 Reviewdog Diagnostic Format（RDFormat），它支援更豐富的診斷資訊，如嚴重級別、規則程式碼和程式碼建議。它還接受 unified diff 輸出作為輸入，這使其能處理產生 diff 的格式化工具，並且可以讀取 checkstyle XML 和 SARIF 2.1.0 JSON。README 展示了類似 golint ./... | reviewdog -efm="%f:%l:%c: %m" -diff="git diff FETCH_HEAD" 的管道用於本地過濾。
第 2 節在 reviewdog/reviewdog 的專屬觀察：這個專案使用 Go，預設分支是 master，授權標示為 MIT。README 把能力放在自己的命令、模組與資料格式中，不能只用一句產品描述取代這些邊界。README 未說明的效能上限、部署規模與相依版本，也不能由倉庫星數或描述推導。
針對 reviewdog/reviewdog 的第 2 個判讀，應從 README 列出的安裝或執行命令開始，保存命令使用的參數，再對照它宣稱的輸出、設定檔與錯誤訊息。若文章涉及 reviewdog 的版本行為，請以 GitHub Releases 的版本標記核對，並把本機環境、輸入資料與輸出結果分開記錄。這個核對只回答該功能是否按文件運作，不代表其他模組也有同樣結果。
第 2 節的判斷還要留意責任邊界：reviewdog/reviewdog README 有明確寫出的內容才可作為事實，沒有寫出的整合方式、容量數字或可靠性保證應保留疑問。對採用者來說，最有用的結果不是把功能清單全部列完，而是知道這個章節中的入口是否能在指定版本重現，以及失敗時哪一層留下可讀的訊息。
reviewdog｜3｜使用 .reviewdog.yml 和 runner 進行設定
reviewdog 可以透過 .reviewdog.yml 檔案驅動，而不是每次呼叫都傳遞旗標。該檔案定義 runner，每個 runner 包含要執行的命令，以及 errorformat 或命名格式。runner 還可以設定名稱和報告級別。不帶 -f 旗標執行 reviewdog 會讀取設定並執行定義的 runner。-runners 旗標限制執行特定 runner，-conf 指向自訂設定路徑。README 展示了一個包含 golint 和 govet 範例的設定，此類執行輸出的行會包含工具名稱，如 project/run_test.go:61:28: [golint] error strings should not end with punctuation。
第 3 節在 reviewdog/reviewdog 的專屬觀察：這個專案使用 Go，預設分支是 master，授權標示為 MIT。README 把能力放在自己的命令、模組與資料格式中，不能只用一句產品描述取代這些邊界。README 未說明的效能上限、部署規模與相依版本，也不能由倉庫星數或描述推導。
針對 reviewdog/reviewdog 的第 3 個判讀，應從 README 列出的安裝或執行命令開始，保存命令使用的參數，再對照它宣稱的輸出、設定檔與錯誤訊息。若文章涉及 reviewdog 的版本行為，請以 GitHub Releases 的版本標記核對，並把本機環境、輸入資料與輸出結果分開記錄。這個核對只回答該功能是否按文件運作，不代表其他模組也有同樣結果。
第 3 節的判斷還要留意責任邊界：reviewdog/reviewdog README 有明確寫出的內容才可作為事實，沒有寫出的整合方式、容量數字或可靠性保證應保留疑問。對採用者來說，最有用的結果不是把功能清單全部列完，而是知道這個章節中的入口是否能在指定版本重現，以及失敗時哪一層留下可讀的訊息。
reviewdog｜4｜報告器與評論的落點
reviewdog 有一組報告器，決定發現結果發布到哪裡。預設報告器 local 將結果列印到終端，用於檢查哪些發現落在改動的行上。對於 GitHub，有幾個報告器：github-pr-check 發布到 GitHub Checks，github-check 同時適用於提交和拉取請求，github-pr-review 使用 GitHub API 發布審查評論，github-annotations 發出 GitHub Actions 工作流命令。GitLab 報告器發布到合併請求討論或單個提交，還有針對 Bitbucket Code Insights 和 Gerrit 的報告器。根據 README 中的支援表，程式碼建議（提出具體替換內容的建議）僅由 github-pr-review 和 gitlab-mr-discussion 報告器支援；其他報告器要麼服務本身不支援，要麼尚未實現。
第 4 節在 reviewdog/reviewdog 的專屬觀察：這個專案使用 Go，預設分支是 master，授權標示為 MIT。README 把能力放在自己的命令、模組與資料格式中，不能只用一句產品描述取代這些邊界。README 未說明的效能上限、部署規模與相依版本，也不能由倉庫星數或描述推導。
針對 reviewdog/reviewdog 的第 4 個判讀，應從 README 列出的安裝或執行命令開始，保存命令使用的參數，再對照它宣稱的輸出、設定檔與錯誤訊息。若文章涉及 reviewdog 的版本行為，請以 GitHub Releases 的版本標記核對，並把本機環境、輸入資料與輸出結果分開記錄。這個核對只回答該功能是否按文件運作，不代表其他模組也有同樣結果。
第 4 節的判斷還要留意責任邊界：reviewdog/reviewdog README 有明確寫出的內容才可作為事實，沒有寫出的整合方式、容量數字或可靠性保證應保留疑問。對採用者來說，最有用的結果不是把功能清單全部列完，而是知道這個章節中的入口是否能在指定版本重現，以及失敗時哪一層留下可讀的訊息。
reviewdog｜5｜過濾模式與退出碼
預設情況下，reviewdog 將發現過濾到新增或修改的行（filter-mode=added）。其他模式包括 diff_context（在更改行周圍包含幾行上下文）、file（只要檔案被修改就報告檔案中的任何發現）和 nofilter（完全停用過濾）。README 指出並非每個報告器都支援所有模式；例如，github-pr-review 對 diff 上下文之外的發現會回退到 check annotation。退出碼由 -fail-level 控制。預設的 -fail-level=none 下，即使發現問題，reviewdog 總是返回 0。將 -fail-level 設定為 any、info、warning 或 error 時，只要至少有一個發現達到或超過該嚴重級別，工具就會以 1 退出。這使 CI 步驟可以在 lint 發現失敗。
第 5 節在 reviewdog/reviewdog 的專屬觀察：這個專案使用 Go，預設分支是 master，授權標示為 MIT。README 把能力放在自己的命令、模組與資料格式中，不能只用一句產品描述取代這些邊界。README 未說明的效能上限、部署規模與相依版本，也不能由倉庫星數或描述推導。
針對 reviewdog/reviewdog 的第 5 個判讀，應從 README 列出的安裝或執行命令開始，保存命令使用的參數，再對照它宣稱的輸出、設定檔與錯誤訊息。若文章涉及 reviewdog 的版本行為，請以 GitHub Releases 的版本標記核對，並把本機環境、輸入資料與輸出結果分開記錄。這個核對只回答該功能是否按文件運作，不代表其他模組也有同樣結果。
第 5 節的判斷還要留意責任邊界：reviewdog/reviewdog README 有明確寫出的內容才可作為事實，沒有寫出的整合方式、容量數字或可靠性保證應保留疑問。對採用者來說，最有用的結果不是把功能清單全部列完，而是知道這個章節中的入口是否能在指定版本重現，以及失敗時哪一層留下可讀的訊息。
reviewdog｜6｜CI 整合與 GitHub Actions 生態
reviewdog 設計用於在持續整合中執行。README 記錄了 Travis CI、Circle CI、GitLab CI 和 Bitbucket Pipelines 的設定，並包含一組適用於任何 CI 系統的環境變數（CI_PULL_REQUEST、CI_COMMIT、CI_REPO_OWNER、CI_REPO_NAME）。對於 GitHub Actions，有一個專用 action reviewdog/action-setup 來安裝 reviewdog，還有許多社群 action 包裝了特定 linter，如 ESLint、ShellCheck、golangci-lint 等。README 還描述了從 fork 倉庫拉取請求時的優雅降級路徑：當 GITHUB_TOKEN 沒有寫入 Checks 或 Reviews 的權限時，reviewdog 回退到 GitHub Actions 日誌命令來建立 annotations。
第 6 節在 reviewdog/reviewdog 的專屬觀察：這個專案使用 Go，預設分支是 master，授權標示為 MIT。README 把能力放在自己的命令、模組與資料格式中，不能只用一句產品描述取代這些邊界。README 未說明的效能上限、部署規模與相依版本，也不能由倉庫星數或描述推導。
針對 reviewdog/reviewdog 的第 6 個判讀，應從 README 列出的安裝或執行命令開始，保存命令使用的參數，再對照它宣稱的輸出、設定檔與錯誤訊息。若文章涉及 reviewdog 的版本行為，請以 GitHub Releases 的版本標記核對，並把本機環境、輸入資料與輸出結果分開記錄。這個核對只回答該功能是否按文件運作，不代表其他模組也有同樣結果。
第 6 節的判斷還要留意責任邊界：reviewdog/reviewdog README 有明確寫出的內容才可作為事實，沒有寫出的整合方式、容量數字或可靠性保證應保留疑問。對採用者來說，最有用的結果不是把功能清單全部列完，而是知道這個章節中的入口是否能在指定版本重現，以及失敗時哪一層留下可讀的訊息。
reviewdog｜7｜安裝與發布管道
README 列出了多種安裝方法。主要方法是 curl 管道到 install.sh 指令碼，預設安裝最新版本到 ./bin/。-b 旗標可以指定不同目錄，也可以將版本作為引數傳遞。由於 Alpine Linux 預設沒有 curl，提供了 wget 變體。還有 Homebrew 和 Linuxbrew 套件（brew install reviewdog/tap/reviewdog）、Windows 的 Scoop 套件，以及 go install 命令從原始碼建置。每晚發布到單獨的倉庫 reviewdog/nightly，並提供自己的安裝指令碼。倉庫中繼資料顯示該專案用 Go 編寫，採用 MIT 許可證。
第 7 節在 reviewdog/reviewdog 的專屬觀察：這個專案使用 Go，預設分支是 master，授權標示為 MIT。README 把能力放在自己的命令、模組與資料格式中，不能只用一句產品描述取代這些邊界。README 未說明的效能上限、部署規模與相依版本，也不能由倉庫星數或描述推導。
針對 reviewdog/reviewdog 的第 7 個判讀，應從 README 列出的安裝或執行命令開始，保存命令使用的參數，再對照它宣稱的輸出、設定檔與錯誤訊息。若文章涉及 reviewdog 的版本行為，請以 GitHub Releases 的版本標記核對，並把本機環境、輸入資料與輸出結果分開記錄。這個核對只回答該功能是否按文件運作，不代表其他模組也有同樣結果。
第 7 節的判斷還要留意責任邊界：reviewdog/reviewdog README 有明確寫出的內容才可作為事實，沒有寫出的整合方式、容量數字或可靠性保證應保留疑問。對採用者來說，最有用的結果不是把功能清單全部列完，而是知道這個章節中的入口是否能在指定版本重現，以及失敗時哪一層留下可讀的訊息。
編輯結論
reviewdog 是一個專注的工具，它把任意 linter 的文字輸出轉化為可操作的審查評論，前提是 linter 能輸出可解析的格式。它不試圖取代 linter，而是位於 linter 和程式碼託管服務之間，用 diff 決定報告什麼。 對 reviewdog/reviewdog 而言，適合由能控制 Go 執行環境的開發者先從 README 指定入口開始；不適合把倉庫描述直接視為跨版本或跨平台保證。採用前，請先執行 reviewdog/reviewdog README 寫出的最小命令，記下實際版本、輸入、輸出與錯誤，再按文章所述功能逐項比對。MIT 授權對修改、散布或託管方式的影響，也要放回你的交付模式中確認。
社群筆記