本文没有正经开场白。今天是我第一次正式接触 ESLint，结果刚把代码交上去，就被一个"看不见的保安"当场抓包。它不说话，只报错，每一行都精准得让人头皮发麻。下面是我和这位"代码保安"的完整交锋记录。
先认识一下这位"保安"
先说结论：ESLint 是代码工程质量的重要保证，它强制团队写出一致风格的代码，严格检查代码里的潜在 bug。
arduino
读着像是"代码风格检查工具"？
不，它更像一个"强迫症晚期 + 猎犬嗅觉"的纪律委员。它不跑你的代码，但会用一套规则把你的代码"过一遍筛子"------哪一行不规范，它当场点名。
第一轮交锋：no-var，禁止 var
我的代码（差点写成）：
javascript
var name = "qxh"; // ❌ 如果这么写，当场被点名ESLint 规则（eslint.config.mjs）：
javascript
rules: {
"no-var": 2, // 不能用 var！2 = error，直接报错
...
}规则里的数字是什么意思？
| 数字 | 级别 | 含义 |
|---|---|---|
| 0 | off | 关掉，不管 |
| 1 | warn | 警告，不阻断 |
| 2 | error | 报错，必须改 |
"no-var": 2 意味着：谁写 var 谁就编译报错。
正确姿势：
javascript
let name = "qxh"; // ✅ let 才符合规范为什么禁 var？ 老生常谈：var 没有块级作用域、会挂到 window 上污染全局、还会变量提升搞出各种诡异 bug。团队代码里禁掉它，等于从源头消灭一大类"灵异事件"。
第二轮交锋：quotes 和 semi，双引号 + 分号
javascript
rules: {
"quotes": ["error", "double"], // 必须用双引号
"semi": ["error", "always"], // 必须加分号
...
}被点名现场：
javascript
let name = 'qxh' // ❌ 单引号 + 没分号，双重暴击
hello() // ❌ 没分号合规姿势：
javascript
let name = "qxh"; // ✅ 双引号
hello(); // ✅ 有分号为什么这么较真？ 因为团队协作里，最消耗精力的往往不是算法难题，而是"为什么你写的代码和我写的不像一个人的"------统一引号、统一分号，代码看起来就像出自一人之手，review 起来毫无心理负担。
第三轮交锋：indent，缩进必须 2 格
javascript
rules: {
"indent": ["error", 2] // 缩进必须 2 个空格
}被点名现场：
javascript
function hello() {
console.log(name + "hello"); // ❌ 4 格缩进？报错！
}合规姿势：
javascript
function hello() {
console.log(name + "hello"); // ✅ 2 格
}写 4 格和写 2 格有区别吗？ 对机器没有，但对团队有------十几个人各自按喜好缩进，代码就会变成"视觉灾难现场"。统一缩进，是维护代码可读性的底线。
第四轮交锋：no-console，警告但不阻断
javascript
rules: {
"no-console": 1 // 1 = warn，警告
}为什么 console.log 也要管？
- 开发时：console.log 是好帮手，打日志排查问题。
- 上线后：一堆 console.log 留在生产环境，既暴露信息又不美观。
所以 ESLint 的态度是：警告（1），不报错（2）------你开发时可以打日志，但上线前要记得清掉。
这就像学校里的"口头警告"：不记过，但你心里得有数。
完整配置一览
把我们被点名的所有规则汇总（eslint.config.mjs）：
javascript
import js from "@eslint/js";
import globals from "globals";
import tseslint from "typescript-eslint";
import { defineConfig } from "eslint/config";
export default defineConfig([
{
files: ["**/*.{js,mjs,cjs,ts,mts,cts}"],
plugins: { js },
extends: ["js/recommended"], // JS 官方推荐规则集
languageOptions: { globals: globals.node }, // Node 环境全局变量
rules: {
"no-var": 2, // 禁 var（error）
"no-console": 1, // 禁 console（warn）
"quotes": ["error", "double"], // 双引号
"semi": ["error", "always"], // 必须有分号
"indent": ["error", 2] // 2 格缩进
}
},
tseslint.configs.recommended, // TS 官方推荐规则集
]);配置的四个层次：
| 部分 | 作用 |
|---|---|
extends: ["js/recommended"] |
引入 JS 官方推荐规则（白嫖） |
tseslint.configs.recommended |
引入 TS 官方推荐规则 |
languageOptions.globals |
声明环境（Node 的全局变量不误报） |
rules |
自定义规则，覆盖团队约定 |
交锋结束：为什么团队一定要用 ESLint？
被"抓包"一下午，我的真实感受：
- 消灭潜在 bug ：
no-var这类规则直接封掉一类隐患。 - 统一代码风格：不管谁写的，看起来都像一个人写的。
- review 更轻松：reviewer 不用纠结"你为啥用单引号"，只看逻辑。
- 新人快速上手：不规范？保存即报错，当场学会规范。
ESLint 不是限制你，是保护整个团队的代码不被"风格混沌"淹没。 它就像体检报告------看着烦，但能救命。
最后划个重点
面试官要是问"ESLint 是干嘛的、规则级别怎么分"，记住三句话：
- ESLint 是代码质量工具，强制团队一致风格 + 检查潜在 bug。
- 规则级别：
0关闭 /1警告 /2报错。 - 常用团队规则：
no-var、quotes、semi、indent、no-console。
本文所有代码示例均来自课堂学习资料，真实可运行。