ESLint 与 Prettier 应分工协作：ESLint 专注逻辑错误和代码质量，Prettier 专责格式化；冲突源于规则重叠，解法是用 eslint-config-prettier 禁用 ESLint 中所有格式规则，并将 prettier 放在 extends 最后。
ESLint 和 Prettier 不是二选一的关系，而是分工明确：ESLint 检查逻辑错误和代码质量（比如 no-unused-vars、eqeqeq），Prettier 只做格式化（缩进、分号、引号、换行等）。强行让 ESLint 管格式，或让 Prettier 查逻辑，都会导致冲突、误报、配置臃肿。
为什么 ESLint + Prettier 一起用会报红？
常见原因是两者规则重叠且冲突，比如 ESLint 启用了 semi（要求分号），而 Prettier 默认不加分号，保存时 Prettier 格式化完立刻被 ESLint 报错。根本解法不是“调高某条规则优先级”，而是让 ESLint 忽略所有格式类规则，只专注代码质量。
- 安装
eslint-config-prettier：它会禁用 ESLint 中所有与 Prettier 冲突的规则 - 在 ESLint 配置中，把
prettier放在 extends 数组 ** 最后 **（覆盖优先） - 不要手动启用
prettier/prettier规则后又去配semi、quotes这类格式规则
推荐的最小可行配置组合
以现代 前端 项目（React + TypeScript）为例，不堆砌插件，只留真正需要的：
- 依赖安装：
npm install -D eslint prettier eslint-config-prettier eslint-plugin-react eslint-plugin-react-hooks @typescript-eslint/eslint-plugin @typescript-eslint/parser - ESLint 配置（
.eslintrc.cjs）：module.exports = {root: true, parser: '@typescript-eslint/parser', plugins: ['react', 'react-hooks', '@typescript-eslint'], extends: ['eslint:recommended', 'plugin:react/recommended', 'plugin:react-hooks/recommended', 'plugin:@typescript-eslint/recommended', 'prettier' // 必须放最后], rules: {'react/react-in-jsx-scope': 'off', // React 17+ 不需要 '@typescript-eslint/no-explicit-any': 'warn'} }; - Prettier 配置（
.prettierrc）保持极简，只覆盖默认行为：{"semi": true, "singleQuote": true, "tabWidth": 2, "trailingComma": "es5"}
编辑器和提交前怎么确保生效？
光配好文件没用，关键在执行时机和 工具 链协同：
立即学习“Java 免费学习笔记（深入）”；
- VS Code 需装插件
ESLint和Prettier，并在设置中指定："editor.codeActionsOnSave": {"source.fixAll.eslint": true}, "editor.formatOnSave": false // 关闭 Prettier 自动格式化，交给 ESLint 统一处理 - 提交前加
lint-staged防漏："lint-staged": {"*.{js,jsx,ts,tsx}": ["eslint --fix", "prettier --write"] }注意顺序：先 ESLint 修复逻辑 / 结构问题，再 Prettier 统一格式，避免来回打架
- CI 中跑
eslint . --max-warnings 0，把警告当错误卡住构建，否则配置形同虚设
最容易被忽略的是「Prettier 不该参与 lint 命令」——它没有 lint 功能，只是格式化器。如果在 package.json 的 lint 脚本里混写 prettier --check，就会让团队误以为“格式问题 = 代码问题”，模糊了质量红线和风格偏好之间的界限。
