VS Code 依赖外部工具（如 Prettier、ESLint、Black）实现格式化，统一团队风格需统一配置、工具和触发方式；Prettier 负责“怎么写好看”，ESLint 负责“怎么写正确”，须用 eslint-config-prettier 消除冲突，并通过 CI（如 prettier --check）强制校验。
VS Code 本身不定义代码格式化规则，它只调用外部格式化工具（如 Prettier、ESLint、Black、clang-format 等）；所谓“统一团队编码风格”，本质是**统一配置 + 统一工具 + 统一触发方式**，不是靠 VS Code 设置面板点几下就能搞定的。
怎么让 VS Code 调用 Prettier 格式化 JavaScript/TypeScript
绝大多数前端团队用 Prettier 做基础格式化（缩进、引号、换行等），但它不校验逻辑错误，需配合 ESLint。关键不是装插件，而是确保：
-
Prettier以 CLI 方式被调用（推荐本地安装：npm install --save-dev prettier），避免全局版本不一致 - 在项目根目录放
.prettierrc（或prettier.config.js），内容例如：{ "semi": false, "singleQuote": true, "tabWidth": 2 } - VS Code 的
settings.json中启用保存时格式化，并指定默认格式化工具："editor.formatOnSave": true,<br>"editor.defaultFormatter": "esbenp.prettier-vscode",<br>"[javascript]": { "editor.formatOnSave": true },<br>"[typescript]": { "editor.formatOnSave": true } - 禁用可能冲突的设置：
"prettier.requireConfig": true（强制读取配置文件，避免插件自作主张）
为什么 ESLint 和 Prettier 一起用还报红？
因为 ESLint 默认不做格式化，只报告问题；而 Prettier 不检查变量未使用、函数复杂度等逻辑问题。两者职责不同，但规则有重叠（比如缩进），直接共存会打架。
- 必须用
eslint-config-prettier关闭 ESLint 中所有与 Prettier 冲突的规则 - 推荐组合：用
Prettier处理“怎么写好看”，用ESLint处理“怎么写正确” - VS Code 中不要同时开启
ESLint的自动修复（eslint.codeAction.onSave.mode）和Prettier的保存格式化，否则保存一次触发两轮修改，容易丢空行或改错位置 - 验证是否生效：删掉一个分号，保存后只有 ESLint 报错（没自动加）→ 说明 Prettier 没接管格式化；加了分号却仍报 ESLint 错 → 可能
eslint-config-prettier没正确集成
后端或 Python/Go 项目怎么同步风格？
核心逻辑一样，只是工具链换掉：
- Python：用
black（无需配置）或autopep8+pylint；VS Code 安装ms-python.python插件后，在settings.json设"python.formatting.provider": "black"，并确保项目里有pyproject.toml或setup.cfg声明 black 配置 - Go：VS Code 默认用
gopls（内置语言服务器），它会读gofmt规则；若要强制用goimports，需设"go.formatTool": "goimports"，且本地GOBIN路径下要有该命令 - 关键陷阱：不同语言的格式化工具对“保存即格式化”的响应时机不同——有些在编辑器内存中操作，有些会重写整个文件。如果团队混用 Windows/macOS/Linux，注意换行符（
endOfLine）和路径分隔符是否被工具隐式处理
真正难的不是配出一套能跑的规则，而是让所有人提交的代码都过 CI 的格式化检查。建议把 prettier --check 或 black --check 加进 package.json 的 test 脚本，并在 GitHub Actions / GitLab CI 里跑；本地 VS Code 配置只是辅助，CI 才是最终裁判。
