1. 为什么需要同时使用 ESLint 和 Prettier在 JavaScript 生态系统中代码质量和代码风格是两个不同的维度。ESLint 主要关注代码质量它能检测出潜在的错误、未使用的变量、不推荐的语法等而 Prettier 则专注于代码风格的统一它能自动格式化代码确保团队中所有代码的缩进、引号、分号等风格一致。我见过太多项目因为缺乏统一的代码风格而变得难以维护。一个典型的例子是团队中有人喜欢单引号有人坚持双引号有人习惯在行末加分号有人则坚决不加。这种风格上的不一致虽然不会直接影响代码运行但会显著增加代码审查的负担降低代码的可读性。提示ESLint 和 Prettier 的分工可以类比为语法检查和排版工具 - 前者确保你说的话没有语病后者确保你的字体和段落整齐美观。2. 基础配置与集成方案2.1 安装必要依赖首先需要安装核心包和它们的配套工具npm install --save-dev eslint prettier eslint-config-prettier eslint-plugin-prettier这里解释下每个包的作用eslint: JavaScript 代码质量检查工具prettier: 代码格式化工具eslint-config-prettier: 关闭 ESLint 中与 Prettier 冲突的规则eslint-plugin-prettier: 将 Prettier 作为 ESLint 规则运行2.2 配置文件设置.eslintrc.js示例配置module.exports { extends: [ eslint:recommended, plugin:prettier/recommended // 必须放在最后 ], rules: { // 你的其他规则 } }.prettierrc示例配置{ semi: false, singleQuote: true, printWidth: 80, tabWidth: 2 }注意plugin:prettier/recommended实际上做了三件事启用 eslint-plugin-prettier设置 prettier/prettier 规则为 error继承 eslint-config-prettier 配置3. 编辑器集成与自动化3.1 VS Code 配置在 VS Code 中安装 ESLint 和 Prettier 插件后添加以下工作区设置{ editor.defaultFormatter: esbenp.prettier-vscode, editor.formatOnSave: true, eslint.validate: [javascript, javascriptreact], eslint.autoFixOnSave: true }3.2 解决常见编辑器问题根据热词中反映的问题这里提供几个常见问题的解决方案formcomponents is not defined 错误 这是 ESLint 的未定义变量检查需要在.eslintrc.js中添加rules: { react/jsx-no-undef: [error, { allowGlobals: true }] }格式化快捷键不可用 检查是否安装了 Prettier 插件并确保没有其他插件冲突。ESLint 运行缓慢 可以尝试添加.eslintignore文件忽略不需要检查的目录node_modules/ dist/4. 高级配置与优化4.1 只对修改的文件运行 ESLint在大型项目中全量运行 ESLint 会很慢。可以使用lint-staged只对暂存区的文件进行检查npm install --save-dev husky lint-stagedpackage.json配置{ husky: { hooks: { pre-commit: lint-staged } }, lint-staged: { *.{js,jsx}: [eslint --fix, prettier --write] } }4.2 性能优化技巧使用.eslintcache 在 ESLint 命令后添加--cache参数可以显著提高后续检查速度。并行运行 对于大型项目可以使用eslint-parallel来并行执行检查。增量检查 结合 Git 的变更记录只检查修改过的文件。5. 替代方案评估热词中提到的oxfmt是 Facebook 内部使用的格式化工具与 Prettier 类似但有一些不同的设计选择特性Prettieroxfmt配置选项较少但足够更少速度快更快社区支持非常好有限可扩展性高低除非有特殊需求否则对于大多数项目Prettier 仍然是更好的选择因为它有更成熟的生态系统和更广泛的编辑器支持。6. 实际项目中的经验分享在多个大型 React 项目中配置 ESLint Prettier 后我总结出以下几点经验规则的选择 不要盲目启用所有规则。开始时只启用最重要的规则然后根据团队需求逐步添加。过于严格的规则会导致开发体验下降。自动修复的范围 有些 ESLint 规则的自动修复可能不安全如no-unused-vars建议只在简单规则上启用自动修复。与 TypeScript 集成 如果使用 TypeScript需要额外安装typescript-eslint相关插件并注意调整解析器设置。处理遗留代码 对于已有的大型代码库可以先用--fix干运行评估修改范围后再实际应用。团队协作 确保所有团队成员使用相同的编辑器配置或者将格式化步骤放在 pre-commit 钩子中强制执行。我在实际项目中遇到过 Prettier 格式化后导致测试失败的情况原因是某些测试依赖特定的代码格式如多行字符串的缩进。这种情况下可以通过// prettier-ignore注释来排除特定代码块的格式化。