Lint

自動檢查程式碼格式、潛在錯誤與團隊規則。

先用一句話理解

自動檢查程式碼格式、潛在錯誤與團隊規則。

打個比方

像文書校對，先抓錯字與基本格式問題。

什麼時候會遇到

提交前、CI/CD、多人協作時。

再往深一點看

Lint 是由 ESLint 這類工具自動掃描程式碼，針對「未使用的變數」、「忘記加 dependency array 的 useEffect」、「沒有處理 Promise 的 await」等常見問題發出警告或錯誤。和 typecheck 不同，lint 不只看型別，還會執行一套可自訂的規則——例如禁止用 console.log 進 production、強制所有 React 元件都要有 key 屬性、或強制 import 順序整齊。Lint 的規則可以靜默通知（warning）也可以設成阻斷合併（error），後者搭配 CI 才能真正把關。Prettier 通常和 ESLint 搭配使用，但分工不同：ESLint 抓邏輯與規則問題，Prettier 只管縮排、引號、換行等純格式問題。

舉個例子

你的 React 元件裡有一個 useEffect 忘記在 dependency array 加某個變數，ESLint 的 react-hooks/exhaustive-deps 規則會立刻標紅。把 npm run lint 設進 GitHub Actions，每次 PR 都會自動跑，有 lint error 就阻止合併，不需要 reviewer 人工審每一行格式問題。

常見誤解

- 把 lint 全設成 warning 而不是 error，開發者習慣無視警告，幾個月後 CI 輸出幾百條 warning 但大家都不在乎，lint 形同虛設。
- 只在本機偶爾手動跑 lint，沒有加進 CI 流水線，導致不同人的程式碼風格差異越來越大，code review 時浪費時間討論格式問題。
- 把 eslint-disable 或 // eslint-disable-next-line 當成解法，真正的問題（例如缺少 key、錯誤的 hooks 用法）被蓋掉而非修好，留下潛在 bug。