ESLint 工程師必備外掛：第一道程式碼品質檢測，一鍵清理舊程式碼，如何安裝與設定

#ESLint #AI #程式開發 #CodeReview #外掛插件

梨子2026-08-16

AI 寫 Code 忘記清理舊程式嗎？用 ESLint 築起專案第一道護欄，抓出潛在的程式碼地雷

今天來介紹一個基礎的檢查工具： ESLint ，它雖然不能保證程式碼從此萬無一失，卻是成本最低、能在第一時間幫你過濾雜訊、把關基本程式規範的「第一道防線」。

ESLint 是什麼？

ESLint

RESOURCE INFO

GitHub github.com/eslint/eslint

核心功能在 JavaScript / TypeScript 程式碼中快速找出語法瑕疵與潛在代碼地雷。

社群指標

27.5k Stars5.2k Forks

授權條款

MIT

＊社群指標數據為文章發布當下擷取，最新數值請以網站為準。

ESLint 是一款 JavaScript / TypeScript 的靜態分析工具，俗稱 Linter。

簡單說，它是一個會自動檢查程式碼語法與結構的工具。在你還沒執行程式、也不需要等測試跑完的情況下，只要一存檔，就能快速抓出常見的語法瑕疵、不符合規範的寫法，或是容易引發錯誤的程式碼模式。

不需要跑程式，不需要等測試，一存檔就能立刻看到警告與提示，這就是靜態分析最核心的優勢：即時且零成本的反饋。

💡 常見迷思：ESLint 只是給前端網頁用的嗎？

很多人初學時常有這個誤解：「只有寫網頁前端（Vue、React）時才需要裝 ESLint 吧？」

答案是：完全不限於前端，它是全端（Full-stack）通用的程式碼守門員！

只要專案的底層語言是 JavaScript 或 TypeScript，無論跑在哪個環境，ESLint 都能發揮關鍵作用：

前端網頁端（瀏覽器）：在 Vue / Nuxt、React / Next.js 專案中，幫你檢查組件語法、React Hooks 依賴項、DOM 渲染安全性等規範。
後端伺服器端（Node.js）：在 Express、NestJS、Fastify 等後端 API 專案中，幫你攔截未處理的非同步 Promise、記憶體洩漏風險、未捕獲的例外錯誤以及潛在的安全漏洞。
工具與自動化腳本：開發 CLI 工具、批次處理腳本或爬蟲程式，同樣能確保代碼嚴謹乾淨。

前端之所以讓人感覺「最常遇到 ESLint」，純粹是因為前端現代框架（如 Vite、Nuxt）的建立腳本通常預設整合了它，加上 VS Code 編輯器即時畫紅線的效果最為直觀。但對資深工程師而言，無論前後端，只要涉及 JS / TS，ESLint 都是團隊協作中不可或缺的基石。

其實「ESLint 不是新工具」

其實，ESLint 根本不是什麼 AI 時代才冒出來的新產物，早在十多年前（2013 年），它就已經誕生並逐漸成為現代 JavaScript / TypeScript 生態系的行業標準。

但在業界，你可能會發現一個耐人尋味的現象： 不少傳統科技業、接案外包團隊，甚至一些追求短期速度的公司，專案裡可能從未用過、甚至沒聽說過 ESLint。

這類專案往往只追求「功能先跑得動就好、上線要快」，忽略了工程規範與長期維護性。結果就是每個人用各自習慣的風格寫 code，變數命名混亂、格式不一、無效的陳舊代碼滿天飛，甚至留下一堆容易引發非同步錯誤的地雷，表面上求快，實際上卻在背後積累了龐大的技術債。

相反地，真正具備工程素養、注重代碼品質的專業工程師與成熟科技團隊，無一例外都會把 ESLint 列為開案的「第一道標配」。

回想早年在沒有 AI 輔助的純人工開發時代，團隊進行 Code Review 時，我就曾被前輩在 PR 裡細心圈出各種順序與格式瑕疵。當時總驚嘆前輩眼力驚人；直到後來自己更熟悉現代工具鏈才恍然大悟：原來這些瑣碎的規矩，專業團隊根本不用肉眼人工挑，只要在專案裡配好 ESLint，存檔或提交時就能在幾毫秒內自動過濾得一清二楚！

追求速度固然重要，但不設防線的「盲目求快」，往往只是在向未來借高利貸。專業工程師之所以專業，正是懂得把瑣碎的低級錯誤與格式規範交給自動化工具（ESLint）把關，將寶貴的專注力，保留給更具核心價值的系統架構與商業邏輯討論。

術語說明 / GLOSSARY

Code Review：程式碼審查，在程式碼正式合併前，由團隊成員人工檢視並給予優化建議的流程。
PR（Pull Request）：將自己的程式碼變更提交給團隊審查、確認無誤後合併進主分支的機制。

為什麼 AI 時代更需要 ESLint？

AI 生成程式碼的速度極快、量極大，但它不了解你的專案架構，不知道你們團隊的命名慣例，更不會主動遵守你訂的規範。

設定 ESLint 的目的，並不是指望它抓出所有深層的系統漏洞，而是把基本的編碼規範化為明確的規則，先自動濾掉 80% 的低級錯誤與風格雜訊，讓開發者不用浪費時間用肉眼去挑微小毛病：

GitHub Copilot 整合 Code Review：ESLint 在 2025 年底與 GitHub Copilot 的 Code Review 整合，在 PR 審查過程中直接標示 ESLint 違規，在合併前就先攔截基礎錯誤。
支援 MCP（Model Context Protocol）：ESLint 發布了官方 @eslint/mcp 套件，讓 AI 模型可以直接與 ESLint 互動，取得 Linting 結果並即時修正，減少 AI 產出帶有語法瑕疵的程式碼。

目前 ESLint 的下載量趨勢

ESLint 官方網站數據顯示 ESLint 目前是 npm 上下載量第一的 JavaScript Linter，每週下載量超過 1.56 億次，被 Microsoft、Airbnb、Netflix、Facebook 等大公司廣泛使用，而且下載趨勢仍在上升中。

ESLint 能幫你抓什麼？（以及它的能力邊界）

ESLint 的本質是規則與語法樹（AST）的比對，它非常擅長抓出「明確定義的寫法問題」，但無法理解深層的「業務邏輯」：

它非常擅長的領域（基礎防線）：

程式碼風格統一：縮排、命名方式、引號用單引號還是雙引號。當 AI 生成大量程式碼時，若無約束，專案風格很快會凌亂不堪。
明確的語法與邏輯漏洞：例如宣告了變數卻沒有使用、誤用了 == 而不是 ===、忘記處理 Promise 的錯誤等。
已知的反模式與安全規範：透過自訂規則攔截寫死的憑證、缺少身份驗證的 API 端點等。

它的能力邊界（需要搭配測試與人工審查）：

看不懂商業邏輯：例如轉帳功能中，AI 漏掉了「餘額是否大於轉帳金額」，這種語法完全合法但邏輯致命的錯誤，ESLint 是無法察覺的。
深層與跨檔案漏洞：複雜的資料流追蹤或 AI 幻覺套件，仍需仰賴單元測試、Code Review 以及專門的 AI 安全分析工具。

怎麼開始設定 ESLint？

現在的時代要套用 ESLint 很簡單，不需要自己研究複雜的規則設定，直接把下面這段提示詞丟給 AI：「請幫我針對這個專案分析並設定 ESLint 」。

📋 跟著參考步驟可能會執行以下指令：

步驟一：安裝 ESLint
Bash
```
npm install --save-dev eslint
```
步驟二：初始化設定檔
Bash
```
npx eslint --init
```

接著就會幫你生成一份基本的設定檔（例如以下格式的 eslint.config.js）

eslint.config.js 基本結構範例

自 ESLint v9 起，官方全面採用 Flat Config 設定格式。設定檔本質上就是一個純 JavaScript 陣列設定檔，可以直接 import 推薦規則與套件進行組合：

eslint.config.js

// 參考的簡單規範：可依照專案自由增加規則
import js from "@eslint/js";

export default [
  // 1. 引入官方推薦規則集 依照專案自由增加
  js.configs.recommended,
  // 2. 自訂專案規則 依照專案自由增加
  {
    files: ["**/*.{js,mjs,cjs,ts,jsx,tsx}"],
    rules: {
      "no-unused-vars": "warn", // 抓出宣告卻未使用的變數
      "prefer-const": "error",  // 建議未重新賦值的變數使用 const
      "no-console": "warn",     // 避免遺漏 console.log ...
    },
  },
  // 3. 忽略非程式碼相關特定目錄
  {
    ignores: ["dist/**", "node_modules/**", ".output/**"],
  },
];

🔍 怎麼執行檢查？

終端機指令：設定完成後可以直接在終端機執行 npx eslint .，或在 package.json 加入腳本，透過 npm run lint 一鍵檢查全專案，搭配 npx eslint . --fix 還能自動修復格式等常見問題。
VS Code 擴充套件（強烈推薦）：安裝「ESLint」外掛即可獲得即時波浪線提示；搭配「存檔自動修復」設定，存檔瞬間就能自動修好格式問題，連指令都省了！
點擊放大
ESLint 即時抓出語法瑕疵與未使用的變數

進階規則與社群外掛

當基礎檢查跑起來後，還能請 AI 針對專案語言與框架加入進階規則；甚至額外安裝熱門的 ESLint 插件（例如無障礙設計檢查、安全性掃描、偵測 AI 生成程式碼安全漏洞等各種不同用途的社群插件），提供更完善的程式品質把關。

以下有更進階的文章與檔案參考：

📚 官方參考：更完整的設定與外掛整合方式，可參考 ESLint 官方設定文件 (Configuration Files)。
📍延伸閱讀：只有 ESLint 還不夠！我在程式專案加裝了 eslint-plugin-security 安全檢查

⚠️ 注意：小心 AI 繞過規則

如果你是請 AI 幫忙修 ESLint 報錯時，記得多瞄一眼它的修改方法！AI 有時候為了圖快，可能會採用 // eslint-disable-next-line 跳過規則強行通關。要留意它是真的把問題修好了與這樣做的合理性，還是只是偷偷把警報器給拔掉喔！

結語：ESLint 絕對是寫程式的人必備的工具

AI 帶來了前所未有的生成速度，但速度越快，專案底層的「品質護欄」就必須越穩固。

與其每次在程式審查時人工肉眼挑錯、或是任由微小瑕疵污染 AI 的上下文，不如讓 ESLint 在存檔的第一秒就自動擋下 80% 的語法錯誤。

你自己的專案平常都有配置哪些資安工具或私房 ESLint 規則呢？或者在設定上有遇到什麼眉角？非常歡迎在底下留言交流你的實戰經驗，或者給我一些建議喔！

兩道品質守護流程 — 第 1 關 ESLint 語法守門，第 2 關業務邏輯與測試

在下一篇文章中，我們將介紹如何搭配 Husky 將這些檢查自動化鎖進 Git 流程中，徹底告別「手動執行容易忘記」的痛點！