关键在于建立可共享、可复现的项目级配置体系：用.editorconfig统一基础编辑行为，prettier+eslint分工协作格式与质量检查，.vscode/settings.json确保开箱即用，husky+lint-staged在提交前自动校验修复。
直接在 VSCode 中统一团队代码规范，关键不是装一堆插件，而是建立可共享、可复现、不依赖个人设置的配置体系。核心是：用项目级配置覆盖全局设置，靠格式化工具自动修正，用 ESLint / Prettier 等工具做静态检查，再通过 Git 提交前校验兜底。
用 .editorconfig 统一基础编辑行为
这是跨编辑器、跨语言的第一道防线，定义缩进、换行、字符编码等基础规则，VSCode 通过 EditorConfig for VS Code 插件自动读取。
- 在项目根目录新建 .editorconfig，例如：
[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
[*.md]
max_line_length = 0
trim_trailing_whitespace = false
- 团队只需维护这一个文件，所有成员打开项目即生效，无需手动调编辑器设置
- 注意：VSCode 默认启用 EditorConfig 支持，但需确认插件已安装且未被禁用
用 Prettier + ESLint 做格式化与质量检查
Prettier 负责“怎么写好看”，ESLint 负责“怎么写正确”。两者配合，避免规则冲突的关键是让 Prettier 只管格式，ESLint 只管逻辑和风格（如变量命名、无用代码）。
- 安装依赖：
npm install --save-dev prettier eslint eslint-config-prettier eslint-plugin-prettier - 配置 .prettierrc（专注格式）：
{ "semi": false, "singleQuote": true, "tabWidth": 2 } - 配置 .eslintrc.js（专注质量）：
启用plugin:prettier/recommended，它会关闭所有与 Prettier 冲突的规则 - 在 VSCode 设置中开启保存时自动修复：
"editor.formatOnSave": true,
"editor.codeActionsOnSave": { "source.fixAll.eslint": true }
把配置纳入项目，不依赖个人设置
团队协作最怕“在我电脑上是好的”。必须确保新成员克隆代码后，开箱即用。
{"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
},
"eslint.validate": ["javascript", "typescript", "vue"]
}
- 这个文件应提交到 Git（加到 .gitignore 是常见错误）
- 同时建议在 README 中说明：“本项目已内置 VSCode 推荐配置，打开项目即生效”
- 可选：配 .vscode/extensions.json 推荐插件列表，引导新成员一键安装
提交前加一层保护：husky + lint-staged
防止格式/质量不合规的代码进入仓库，光靠编辑器不够，得卡在 Git 提交环节。
- 安装：
npx husky-init && npm install，然后添加 pre-commit 钩子 - 配置 lint-staged，只检查暂存区文件，速度快：
"*.{js,ts,vue}": ["eslint --fix", "prettier --write"],
"*.{json,md,css}": ["prettier --write"]
}
- 这样即使有人关了 VSCode 自动修复，或用了其他编辑器，提交时也会被拦截并自动修正
- 团队规范真正落地，靠的是流程卡点，不是靠自觉
基本上就这些。不复杂，但容易忽略项目级配置的完整性。重点不是插件多，而是规则集中、自动执行、全链路覆盖——从打开文件，到保存，再到提交，每一步都有响应。
