Prettier与ESLint代码格式化方法

ESLint 和 Prettier 并非竞争关系，而是各司其职的黄金搭档：ESLint 专注代码逻辑正确性与质量保障（如潜在错误、未使用变量、React Hooks 依赖检查），Prettier 则专精于统一、可预测的代码格式（缩进、引号、换行、JSX 排版等）；二者协同的关键在于通过 `eslint-config-prettier` 彻底关闭 ESLint 的格式规则，让 ESLint 退守语义层校验，Prettier 全权接管格式化——这种清晰分工既避免了规则冲突，又兼顾了健壮性与可读性，是现代前端工程化中高效、可靠、一致的代码规范基石。

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代码格式化方法》的详细内容，更多关于的资料请关注golang学习网公众号！