ESLint+Prettier：代码规范工具

可视化演示

展示ESLint的AST代码分析原理、Prettier格式化前后对比、ESLint+Prettier+Git Hooks集成流水线三种核心场景。

ESLint规则配置

质检员上岗前，必须先领到一本《检查手册》。手册里写着每一条检查项：食材是否过期、刀具是否消毒、生熟是否分开。ESLint 也一样，它的“手册”就是一份配置文件，里面是一条条规则（rules），每条规则都规定了“什么是对的、什么是违规的”。没有手册的质检员只会凭感觉行事，没有规则的 ESLint 也形同虚设。

ESLint 的配置文件通常叫 .eslintrc.js 或 .eslintrc.json。它先通过 parser 指定解析器，告诉 ESLint“我读的是 JavaScript 还是 TypeScript”；再用 extends 继承一套现成的规则集，比如 eslint:recommended 就内置了最常见的问题检查；最后用 rules 字段自定义或覆盖规则，精细到每一类问题。一个最小配置就像一张点菜单：

每条规则的取值代表了问题的严重程度，这个“三级制”正是 ESLint 的灵魂：

回到厨房里：off 相当于这条检查项“不做要求”，warn 是质检员嘀咕一句“下次注意”，error 则是直接把这盘菜打回重做。规则定得越严，后厨越安全，但也要避免过度苛刻把团队逼疯——合理的等级搭配，是规范落地的第一步。

{  "parser": "@typescript-eslint/parser",  "extends": ["eslint:recommended"],  "rules": {    "no-console": "warn",    "semi": ["error", "always"]  }}

Prettier格式化

质检员只负责“这东西能不能吃”，至于盘子正不正、酱汁画得圆不圆，他不管。这时候摆盘师登场了。Prettier 就是那位强迫症摆盘师：双引号还是单引号、行尾加不加分号、缩进用两个空格还是四个空格、一行最多写多少个字符——它有一套“黄金比例”，看到不符合的就默默帮你改整齐。

Prettier 的配置一般写在 .prettierrc 文件里，核心是一组风格选项。最常见的几个选项像摆盘的“标准模板”：printWidth 控制每行最大宽度，默认 80 个字符；tabWidth 控制缩进的空格数；semi 决定行尾是否加分号；singleQuote 决定是否统一用单引号。它们共同构成一套风格公式：

Prettier 还有两个贴心配置：.prettierignore 文件像“免检清单”，告诉摆盘师哪些菜不用摆（比如构建产物、第三方库）；同时它也能集成进 VS Code，在保存文件的瞬间自动“摆盘”。摆盘师不评判菜品好坏，只负责让每一道菜端上来时都赏心悦目——这正是它和 ESLint 最本质的区别。

两者集成方案

一家后厨里，质检员和摆盘师各管一摊，但如果两人同时上手，就可能打架：摆盘师刚把盘子摆正，质检员却说“这个角度不合格”，两人争执不下。ESLint 和 Prettier 也有这种冲突——Prettier 说“字符串要用单引号”，ESLint 却可能配置了“必须双引号”。怎么办？答案是明确分工、关闭冲突。

业界标准做法是引入 eslint-config-prettier，它像一份“和平协议”：把 ESLint 中与 Prettier 冲突的格式类规则统统关掉，让 ESLint 专心管代码质量，Prettier 专心管格式美观。另一方面，也有人用 eslint-plugin-prettier 把 Prettier 塞进 ESLint 当一条规则跑，相当于让质检员兼职摆盘——不推荐，但存在。理想的流水线是先让摆盘师 Prettier 格式化，再让质检员 ESLint 查质量：

在项目里，我们通常把两个检查串成一条 npm 脚本命令，比如 npm run lint 里先写 prettier --write . 再写 eslint .。这样不管是本地开发还是 CI 服务器，执行的永远是同一条“后厨流水线”。质检员和摆盘师各就各位，效率反而最高。

TypeScript配合

如果你是一位质检员，突然被派去检查海鲜档口——海胆新不新鲜、河豚处理得对不对，这需要专门的资格证书。TypeScript 对 ESLint 来说就是“海鲜档口”：它有自己的类型、接口、泛型语法，普通解析器根本读不懂。这时候需要专用解析器登场。

@typescript-eslint/parser 是 TS 世界的“海鲜明档解析器”，它先把 TS 语法翻译成 ESLint 能理解的结构；@typescript-eslint/eslint-plugin 则提供了一批专属规则，比如“不允许使用 any 类型”“不允许未使用的变量”。更进一步，如果开启 parserOptions.project 指向 tsconfig.json，ESLint 还能获得类型信息，做“类型感知”的深度检查——相当于质检员能看懂食材的检测报告，而不仅是看外观。这套逻辑可以写成：

有了这套配合，团队写 TypeScript 时就能提前拦住“滥用 any”“类型断言满天飞”这类问题。质检员考到了海鲜执照，后厨的“高级菜品”才能放心上桌。

Git Hooks集成

质检和摆盘都到位了，但还有一个漏洞：如果厨师做完菜不经过检查台就直接端出去呢？后厨的规矩是——所有菜必须经过传菜口的闸门。对应到代码世界，这个闸门就是 Git Hooks：在 git commit 提交代码之前，强制先跑一遍检查，不合格就拦下。

搭建这道闸门常用两个工具：husky 用来“挂钩子”，它能在 .husky 目录下注册 pre-commit 钩子；lint-staged 让检查只针对暂存区里“即将出锅的菜”，而不是把整座后厨翻个底朝天——这样速度快得多。典型配置是在 package.json 里写 "lint-staged": { "*.{js,ts}": ["eslint --fix", "prettier --write"] }。整个流程可以表示为：

这道闸门最大的价值是“把问题挡在提交之前”。再也不用在 Code Review 里争论“这里该不该加分号”——闸门已经替你处理好了，评审专家只需关注真正的业务逻辑。

团队规范落地

一个人店的规矩好定，一百家分店要执行同一套标准就难了。团队推行代码规范，最大的敌人不是工具，而是“大家不照着做”。所以落地要讲策略：共享配置、渐进推行、文化养成三管齐下。

首先，把 .eslintrc 和 .prettierrc 抽成独立的 npm 包（比如 @company/eslint-config），发布到私有仓库，所有项目安装即用——这就是“总店统一印刷的标准菜谱”。其次，别想着一夜之间重写全部老代码：新代码用 Git Hooks 严格把关，老代码排期分批整改，避免一次大改动引发海量冲突。最后，把规范的目的、常用规则的取舍写进文档，让团队成员理解“为什么这么定”，而不是被迫服从。规范达成可以总结为：

想想连锁餐厅：统一菜谱让厨师有据可依，试点门店积累经验再推广，最终每位厨师都形成肌肉记忆。代码规范也是如此，工具只是“他律”的起点，团队的“自律”才是终点。

工程化实战

最后，我们把整套流程放进真实的工程流水线里：本地开发、提交代码、CI 检查、合并上线，每个环节都有质检员和摆盘师的身影。所谓“工程化”，就是把这些检查动作自动化、脚本化、无法跳过。

本地开发时，VS Code 插件在保存瞬间自动跑 Prettier；提交代码时，husky + lint-staged 在 pre-commit 里跑 eslint --fix 和 prettier --write；推送分支后，CI（如 GitHub Actions）再跑一次完整检查：eslint .、prettier --check .、以及 TypeScript 的 tsc --noEmit。只有全部通过，代码才有资格合并到主分支。整个门禁可以抽象成：

到了这一步，你的“标准化后厨”就真正建成了：质检员、摆盘师、传菜口闸门、统一菜谱全部就位。无论团队扩张到多少人，代码质量和风格都稳如泰山——这就是工程化的力量。

AI 应用场景

Python 演示

"""迷你版 ESLint + Prettier: 代码质量检查与格式化流水线"""  class CodeInspector:    """质检员类: 模拟 ESLint 规则检查与 Prettier 格式化"""     def __init__(self, max_line_len=80):        self.max_line_len = max_line_len        self.error_count = 0     def lint(self, code_lines):        """逐行检查风格问题, 返回 (行号, 规则名, 等级) 列表"""        problems = []        for i, line in enumerate(code_lines, 1):            line = line.rstrip("\n")            if len(line) > self.max_line_len:                problems.append((i, "line-too-long", "error"))            if line.rstrip() != line:                problems.append((i, "trailing-space", "warn"))            if line.startswith("\t"):                problems.append((i, "tab-as-indent", "error"))        self.error_count = len(problems)        return problems     def format(self, code_lines):        """统一风格: 去行尾空白, Tab 转 4 空格"""        result = []        for line in code_lines:            line = line.rstrip()            line = line.expandtabs(4)            result.append(line)        return result     def run_gate(self, code_lines):        """总检闸门: 先格式化再检查, error 级问题直接拦截"""        clean = self.format(code_lines)        problems = self.lint(clean)        has_error = any(level == "error" for _, _, level in problems)        return clean, problems, not has_error  def main():    messy_code = [        "def greet(name):      \n",        "\tprint('Hello, ' + name)\n",        "    if name == 'AI':\n",        "        print('Welcome AI dev with a very very long message over limit!')\n",    ]    inspector = CodeInspector(max_line_len=60)     print("=== Step 1: ESLint 质检 ===")    for lineno, rule, level in inspector.lint(messy_code):        print(f"  line {lineno} violates {rule}, level={level}")    print(f"found {inspector.error_count} problems\n")     print("=== Step 2: Prettier 格式化 ===")    clean = inspector.format(messy_code)    for line in clean:        print(repr(line))    print()     print("=== Step 3: 总检闸门 ===")    _, problems, ok = inspector.run_gate(messy_code)    print("PASS, ship it!" if ok else "BLOCKED, fix error-level issues first!")  if __name__ == "__main__":    main()

1. def lint(self, code_lines)质检员方法：逐行检查三种违规（超长、行尾空格、Tab 缩进），并返回带等级的检查报告。
2. problems.append((i, "line-too-long", "error"))超长行记为 error 级，相当于 ESLint 的 max-len 规则设为 "error"。
3. if line.startswith("\t")检测 Tab 缩进并记为 error，模拟 ESLint 的 no-tabs 规则，TS 项目里尤其常见。
4. self.error_count = len(problems)统计问题总数，对应 ESLint 控制台输出的"problems"汇总。
5. def format(self, code_lines)摆盘师方法：去掉行尾空白并把 Tab 转成 4 空格，模拟 Prettier 的 tabWidth: 4。
6. line.expandtabs(4)把 Tab 字符展开为 4 个空格，是格式统一的核心操作。
7. def run_gate(self, code_lines)组合流水线：先 format 再 lint，返回最终是否放行，对应 Git Hooks 的 pre-commit 拦截。
8. any(level == "error" for _, _, level in problems)存在任一条 error 级问题即拦截，模拟 ESLint 非零退出码导致提交失败。

常见误区

面试题