ESLint 和 Prettier 有什么区别？如何配合使用？

简化版

ESLint 是基于 AST 的静态分析器，主要发现潜在错误和违反工程规则的代码；Prettier 是确定性的代码格式化器，主要统一空格、换行和引号等排版。当前实践通常让 ESLint 管质量、Prettier 管格式，并用 eslint-config-prettier 关闭冲突规则，在编辑器、提交前和 CI 分层执行。

详细版

ESLint 可借助 TypeScript、React、Vue 等插件检查语言和框架规则，部分规则能 --fix，但并非所有修复都安全。Prettier 解析代码后按自身打印模型重新输出，对业务语义几乎不做判断。

ESLint 已不再推荐用核心格式规则承担排版，Prettier 官方也推荐通过 eslint-config-prettier 关闭冲突项。通常分别运行 eslint 与 prettier --check，而不是必须把 Prettier 包装成一条 ESLint 规则。

本地保存格式化是即时反馈，lint-staged 缩短提交检查，CI 对全量或受影响代码做最终裁决。工具版本、Node 版本与配置必须进入仓库并由 lockfile 固定。

完整版教学

一、Lint 与 Format 检查的是不同层次

格式化主要处理不改变 AST 语义的排版，例如缩进、空格和换行；Lint 会分析标识符、控制流和框架约束，能发现未使用变量、错误 Promise 处理或 Hooks 调用问题。

能力	ESLint	Prettier
潜在逻辑问题	核心职责	不负责
框架约束	通过插件支持	不负责
统一排版	可做但不再是推荐重点	核心职责
自动修复	取决于规则	整体重排

记忆钩子：Prettier 让代码“长得一致”，ESLint 尽量让代码“写得可靠”。

二、两者都解析代码，为什么仍不能互相替代

Prettier 会把源码解析成结构，再根据打印宽度等规则重新排版，因此能主动消灭大量风格选择。它不会判断业务变量是否用错，也不会证明 React Hook 依赖完整。

ESLint 的每条规则访问 AST 节点和作用域信息，报告具体违规。某些规则只需局部替换就能自动修复，另一些涉及语义选择，只能让开发者判断。

// Prettier 能统一排版，但不会判断请求结果是否被错误忽略
async function save() {
  api.updateProfile()
}

要检测浮动 Promise，通常还需要 TypeScript 类型信息和对应插件规则。工具能力取决于 parser、plugin 与配置，不能只安装 ESLint 包就期待所有问题自动出现。

三、冲突从哪里来，怎样正确消除

若 ESLint 要求单引号，而 Prettier 配置为双引号，两者会来回修改同一代码。正确思路是确定唯一格式化来源，并关闭 linter 中不必要或冲突的排版规则。

eslint-config-prettier 的作用是“关闭冲突规则”，不是执行 Prettier。把 Prettier 作为 ESLint 插件运行虽可统一输出通道，但会增加 lint 开销，官方集成说明也指出通常没有必要。

源码 ──Prettier──> 统一排版
  └──ESLint──────> 质量与工程约束报告
两条检查在 CI 汇合，职责不重叠

四、flat config、插件与类型信息的边界

当前 ESLint 以 eslint.config.js 等 flat config 形式组织配置，可以按文件匹配语言选项、插件和规则。旧项目仍可能使用历史配置格式，面试回答应说明项目版本背景而不是强行混写。

Type-aware 规则需要 TypeScript 程序信息，准确度更高但初始化和分析成本也更大。假设无类型 lint 需 8 秒，启用全量类型规则后变为 28 秒，增幅为 250%；可把快速规则放提交前，完整规则放 CI 或按受影响项目执行。

插件版本必须和 ESLint、parser、框架版本兼容。升级时应阅读迁移说明并在单独 PR 中观察新增告警，避免顺手升级造成海量无关改动。

五、从编辑器到 CI 的分层反馈

编辑器保存时运行 Prettier，能在几百毫秒内处理当前文件；提交前只检查暂存文件，通常比扫描整个仓库快。CI 则不能信任个人编辑器，应独立运行可重复命令。

层级	典型动作	目标
编辑器	format on save	最快反馈
pre-commit	lint-staged	阻止明显问题进入提交
CI	lint + format check	统一最终标准

提交钩子不是安全边界，开发者可以跳过，CI 才是合入规则的中心。CI 应用 prettier --check 而不是 --write，发现差异后失败，避免流水线偷偷修改未提交代码。

六、怎样处理误报、禁用与自动修复

规则不适合业务时，先确认配置范围和版本，再决定调整规则。局部禁用要写原因并缩小到具体行，不能在文件顶部永久关闭一大片规则。

eslint --fix 只执行标为可修复的规则，也不代表修改必然符合业务意图。批量修复后仍需测试和 diff 审查，尤其是涉及类型导入、Promise 和框架生命周期的变更。

规范的价值可用缺陷和协作成本衡量，而不是规则数量。1000 条噪声告警会让团队忽略真正问题；零容忍策略应建立在低误报、快速反馈和清晰修复说明之上。

七、常见误区与追问

误区：ESLint 只负责代码格式。 它的核心价值是静态分析与工程规则，格式化应交给专用工具。
误区：安装 eslint-config-prettier 就会自动格式化。 它只关闭冲突规则，仍需单独运行 Prettier。
误区：本地保存时通过就不需要 CI。 编辑器插件和个人配置可被关闭，CI 才能提供统一裁决。
追问：为什么不推荐让 ESLint 和 Prettier同时管引号？ 两套规则会产生冲突和反复修改，增加无意义反馈。
追问：为什么开启类型规则后 lint 变慢？ 工具需要构建 TypeScript 程序和类型关系，不再只是遍历单文件语法树。
追问：--fix 是否可以无审查直接提交？ 不可以，可修复只代表工具能变换代码，仍需测试与 diff 审核。
追问：本地通过而 CI 失败怎么排查？ 对齐 Node、包管理器、依赖锁、命令参数、忽略规则和换行环境。

八、加强记忆

把协作模型记成“质量归 ESLint、排版归 Prettier、裁决归 CI”：先消除职责冲突，再按编辑器、暂存文件和流水线分层反馈；类型规则换来更深检查也带来性能成本。这样既能回答工具区别，也能说明配置、速度和团队治理的实际取舍。

简化版

详细版