问题根源在于vscode插件配置、eslint规则与执行时机未对齐；需配齐.eslintrc.js、.vscode/settings.json，明确prettier负责格式、eslint负责校验，并通过ci强制lint:fix保障一致性。
团队里 JS 代码风格不统一、PR 经常被拒、本地跑通但 CI 报 ESLint 错误——这些问题基本不是人的问题，是 VSCode 插件没配对、规则没对齐、执行时机没卡准。
ESLint 插件必须配合 .eslintrc.js 项目级配置使用
只装 ESLint 插件但没在项目根目录放配置文件，等于装了刹车片却没连刹车线。VSCode 默认只启用极简规则（比如 no-unused-vars），根本覆盖不了团队约定的引号、分号、空行等细节。
- 必须创建
.eslintrc.js或.eslintrc.json，且文件要放在项目最外层（package.json同级） - 推荐继承
eslint:recommended+ 框架插件（如plugin:react/recommended），再用eslint-config-prettier关掉所有与 Prettier 冲突的格式类规则 - 如果项目用 TypeScript，
parserOptions.project必须指向tsconfig.json，否则类型相关规则（如no-explicit-any）不会生效
prettier-vscode 的格式化行为受两个开关控制
很多人以为开了 “Format on Save” 就万事大吉，结果发现保存后代码没变，或者变了但和 ESLint 提示冲突——问题往往出在格式化责任没划清。
-
"editor.formatOnSave": true：触发 VSCode 的格式化流程，但具体谁来格式化，取决于"editor.defaultFormatter" -
"editor.defaultFormatter": "esbenp.prettier-vscode"：指定 Prettier 为默认格式器；若这里写的是dbaeumer.vscode-eslint，那格式化就由 ESLint 的--fix承担，容易漏掉缩进/空格等 Prettier 更擅长的规则 - 关键陷阱：
prettier和eslint插件同时启用时，必须禁用 ESLint 的自动格式化能力，即删掉或注释掉"eslint.format.enable": true，否则两者打架
团队成员的 VSCode 设置不能靠口头约定
哪怕你本地配置完美，只要有人没开 formatOnSave，或用了不同版本的 Prettier，提交的代码就会破坏一致性。靠“提醒”“教育”解决不了，得靠机制兜底。
- 在项目根目录加
.vscode/settings.json，写入"editor.formatOnSave": true等关键项，VSCode 会优先读取它（注意：这个文件不应提交到 Git 的.gitignore中，它是项目级配置） - 用
editor.codeActionsOnSave补充 ESLint 自动修复：{"source.fixAll.eslint": true}，这样保存时既格式化又修错 - 更彻底的做法：在
package.json的scripts里定义"lint:fix": "eslint --ext .js,.jsx,.ts,.tsx src/ --fix"，CI 流程强制跑这一条，本地只是预演
真正卡住协同效率的，从来不是某个插件好不好用，而是「谁在什么时候、以什么顺序、按什么规则」处理代码。Prettier 负责“怎么排”，ESLint 负责“对不对”，而 .vscode/settings.json 和 .eslintrc.js 共同决定了这两者不互相踩脚。漏掉任一环，协作成本就藏在每次 git commit 之后的反复修改里。
