团队统一代码规范需共用ESLint和Prettier配置文件（.eslintrc.cjs、.prettierrc）及.vscode/settings.json，后者仅声明格式化开关，不可替代规则定义；须用eslint-config-prettier消除冲突，并验证插件、版本、设置生效链路。
想让团队代码风格统一，靠的不是口头约定，更不是让每个人手动去调编辑器。核心在于，把一套可执行的规则引擎（比如ESLint和Prettier）及其配置文件，作为项目资产提交到代码仓库里。这样，任何人打开项目，都能获得一致的检查和格式化体验。
为什么直接改 VSCode Settings.json 不适合团队协作
这里有个常见的误区：以为在.vscode/settings.json里写满规则就能搞定一切。其实不然。这个文件本质上只是个“开关控制器”，它只能告诉VSCode“什么时候触发格式化”、“用哪个工具来格式化”，但它本身并不能定义“什么算错误”或者“缩进应该是2个还是4个空格”——这些规则，必须由ESLint或Prettier的专属配置文件来定义。
- 你就算设置了
"editor.formatOnSa ve": true，如果项目根目录下没有.prettierrc或eslint.config.js，格式化工具也不知道该按什么标准执行。 - 团队成员安装的插件版本可能不同。举个例子，Prettier插件v11和v12对
semi（分号）的默认处理方式可能就不一样，光靠本地设置无法对齐。 - 如果你发现，在终端运行
npm run lint的结果，和编辑器保存时自动修复的效果不一致，那几乎可以断定，问题就出在配置文件没有真正共用。
必须提交到仓库的 3 个核心配置文件
所以，要想实现“开箱即用”的统一规范，下面这三个文件必须放进版本控制，它们共同构成了项目代码规范的基石。
.eslintrc.cjs（或新的eslint.config.js）：这里定义的是代码质量规则。比如，是否允许使用console.log，变量定义了没使用要不要警告，这些逻辑层面的约束都在这里。.prettierrc：这个文件只关心代码的“颜值”——空格、换行、引号、末尾分号等等。它不管逻辑对错，只管格式统一。.vscode/settings.json：这个文件的作用是激活上述工具。关键配置项包括：指定默认格式化工具为Prettier、开启保存时格式化、以及启用ESLint的自动修复功能。记住，这里只放与项目规则强相关的开关，避免写入个人偏好（比如自动保存策略）。
ESLint 和 Prettier 冲突怎么办
既然两者分工不同，那为什么还会打架？问题就出在职责有重叠的部分，比如缩进、行尾逗号。典型的冲突场景是：保存时，Prettier把行尾逗号删了，紧接着ESLint又标红提示“缺少逗号”。
- 标准解决方案是使用
eslint-config-prettier。这个包的作用很明确：关掉ESLint中所有与Prettier功能重叠的格式化规则。这不是妥协，而是让两者各司其职的最佳实践。 - 确保Prettier成为唯一的“格式仲裁者”，ESLint则专心做代码质量检查。通常，在ESLint配置的
extends中加入"plugin:prettier/recommended"就能实现这一点。 - 如何验证配置生效了？有个简单的测试方法：临时删掉
.prettierrc文件，然后运行npx eslint --fix src/。如果修复后的代码格式变得“奇奇怪怪”，不符合团队风格，那就说明ESLint还在越俎代庖地处理格式问题，配置没清理干净。
新成员拉代码后仍不生效？检查这 4 点
配置文件都齐了，但新同事克隆项目后，自动格式化还是没反应？别急，这通常不是配置写错了，而是整个生效链路的某个环节断了。可以按顺序排查以下几点：
- 插件安装了吗？ VSCode右下角是否弹出了“Recommended extensions”的提示？务必点击“Install All”安装所有推荐插件，特别是
esbenp.prettier-vscode和dbaeumer.vscode-eslint这两个核心。 - 工具版本对吗？ 在项目根目录下，分别运行
npx eslint --version和npx prettier --version，确认本地使用的版本与package.json中声明的依赖版本一致。避免全局安装的旧版本工具干扰项目。 - 保存触发设置对吗？ 在VSCode设置里搜索“format on sa ve”，确认勾选的是“Format On Sa ve”选项。注意不要和“Format On Type”混淆，后者只对实时输入生效。
- 默认格式化工具选对了吗？ 在任意文件中右键，选择“Format Document With…”，看看默认选项是不是
Prettier。如果不是，说明项目的"editor.defaultFormatter"设置可能被用户级别的全局设置覆盖了。
最后，还有一个比较隐蔽的“坑”：如果某位成员本地安装的VSCode ESLint插件版本太旧（比如v2.x），而项目已经采用了ESLint v8+的新扁平化配置（eslint.config.js），那么旧版插件可能根本无法识别新格式的配置文件，导致ESLint在编辑器中静默失效，既不报错也不修复。
