Prettier与ESLint如何格式化JS代码？

大家好，我们又见面了啊~本文《Prettier与ESLint如何格式化JavaScript代码？》的内容中将会涉及到等等。如果你正在学习文章相关知识，欢迎关注我，以后会给大家带来更多文章相关文章，希望我们能一起进步！下面就开始本文的正式内容~

ESLint 负责代码逻辑正确性检查，Prettier 专注代码格式统一；二者分工明确、不可替代，需通过 eslint-config-prettier 关闭 ESLint 格式规则并交由 Prettier 全权处理格式，同时保留 ESLint 在语义层的校验能力。

ESLint 负责“对不对”，Prettier 负责“好不好看”

ESLint 检查代码逻辑是否符合规范，比如 var 是否被禁止、console.log 是否遗漏、变量是否未定义、是否有潜在的 undefined 访问等；Prettier 只管格式，比如缩进用 2 还是 4、单引号还是双引号、对象换行位置、箭头函数要不要写大括号。它俩不重叠，也不替代——一个报错，一个改写。

为什么不能只用 ESLint 自带的 fix？

ESLint 的 --fix 确实能修一部分格式问题（如分号、空格），但它的核心定位是规则引擎，格式能力有限且分散：

• 不同规则需单独开启（如 semi、quotes、object-curly-spacing）
• 多个规则间可能冲突（比如 prettier 插件和原生规则同时启用时会互相覆盖）
• 无法处理复杂格式（如链式调用换行、JSX 属性排序、长数组自动折行）

而 Prettier 是专一的格式化器，所有格式决策由单一配置驱动，结果确定、可预测、跨项目一致。

如何让 ESLint 和 Prettier 协同工作不打架？

关键不是“都装上”，而是让 ESLint 放弃格式职责，只保留代码质量检查，把格式全交给 Prettier：

• 卸载或禁用 ESLint 中所有与格式相关的规则（如 indent、quotes、comma-dangle）
• 安装 eslint-config-prettier，并在 .eslintrc.js 的 extends 末尾加入它，它会自动关闭所有冲突规则
• 安装 eslint-plugin-prettier（可选），把它加到 plugins 并在 rules 中启用 prettier/prettier，这样 ESLint 就能把 Prettier 的格式错误也当警告/错误抛出来

module.exports = {
  extends: [
    'eslint:recommended',
    'plugin:react/recommended',
    'prettier' // ← 这行就是 eslint-config-prettier
  ],
  plugins: ['prettier'],
  rules: {
    'prettier/prettier': 'error'
  }
};

Prettier 不处理的边界问题必须靠 ESLint

Prettier 明确声明不介入任何语义层：它不会加 typeof 判断、不会帮你补 await、不会警告 == 的隐式转换。这些全是 ESLint 的地盘。常见例子包括：

• eqeqeq：强制使用 ===
• no-unused-vars：标记未使用的参数或导入
• react-hooks/exhaustive-deps：检查 useEffect 依赖项是否完整
• no-console：禁止上线前残留 console

如果你只配了 Prettier，这些隐患完全不会被发现。 ESLint 和 Prettier 的分工边界非常清晰，但实际项目里最容易出问题的，是没意识到 eslint-config-prettier 必须放在 extends 数组的最后——顺序错了，前面的规则就会重新激活，导致修复时反复冲突。

以上就是《Prettier与ESLint如何格式化JS代码？》的详细内容，更多关于的资料请关注golang学习网公众号！