ESLint 负责代码逻辑正确性检查,Prettier 专注代码格式统一;二者分工明确、不可替代,需通过 eslint-config-prettier 关闭 ESLint 格式规则并交由 Prettier 全权处理格式,同时保留 ESLint 在语义层的校验能力。
ESLint 检查代码逻辑是否符合规范,比如 var 是否被禁止、console.log 是否遗漏、变量是否未定义、是否有潜在的 undefined 访问等;Prettier 只管格式,比如缩进用 2 还是 4、单引号还是双引号、对象换行位置、箭头函数要不要写大括号。它俩不重叠,也不替代——一个报错,一个改写。
ESLint 的 --fix 确实能修一部分格式问题(如分号、空格),但它的核心定位是规则引擎,格式能力有限且分散:
semi、quotes、object-curly-spacing)prettier 插件和原生规则同时启用时会互相覆盖)关键不是“都装上”,而是让 ESLint 放弃格式职责,只保留代码质量检查,把格式全交给 Prettier:
indent、quotes、comma-dangle)eslint-config-prettier,并在 .eslintrc.js 的 extends 末尾加入它,它会自动关闭所有冲突规则eslint-plugin-prettier(可选),把它加到 plugins 并在 rules 中启用 prettier/prettier,这样 ESLint 就能把 Prettier 的格式错误也当警告/错误抛出来module.exports = {
extends: [
'eslint:recomm
ended',
'plugin:react/recommended',
'prettier' // ← 这行就是 eslint-config-prettier
],
plugins: ['prettier'],
rules: {
'prettier/prettier': 'error'
}
};
Prettier 明确声明不介入任何语义层:它不会加 typeof 判断、不会帮你补 await、不会警告 == 的隐式转换。这些全是 ESLint 的地盘。常见例子包括:
eqeqeq:强制使用 ===
no-unused-vars:标记未使用的参数或导入react-hooks/exhaustive-deps:检查 useEffect 依赖项是否完整no-console:禁止上线前残留 console
eslint-config-prettier 必须放在 extends 数组的最后——顺序错了,前面的规则就会重新激活,导致修复时反复冲突。