VSCode代码格式化需通过扩展与配置协同实现，关键在于明确当前生效的格式化器及配置是否生效；默认内置格式化器能力有限，推荐安装Prettier并设为默认，同时禁用ESLint格式化功能以避免冲突。
VSCode 本身不自带代码格式化能力，必须通过扩展（Extension）和配置协同实现统一风格——关键不在“装了什么”，而在“谁在控制格式化行为”以及“配置是否生效”。
确认当前语言的默认格式化器是否已启用
VSCode 对不同语言会绑定默认格式化器（如 JavaScript 默认用 vscode.typescript-language-features），但这个内置格式化器能力有限，不支持 Prettier 规则、不处理引号/分号/空行等细节。你看到的“自动格式化没反应”或“格式化后和预期不符”，大概率是它在默默接管却没按你的规则走。
- 打开命令面板（
Ctrl+Shift+P或Cmd+Shift+P），输入并执行Format Document With... - 查看列表：如果只有
Configure Default Formatter...一项，说明没装任何第三方格式化扩展 - 如果列出了多个（如
Prettier、ESLint、Python），选中后看右下角状态栏是否显示对应名称——只有显示的那个才是当前生效的格式化器
安装 Prettier 并设为默认（以 JavaScript/TypeScript 为例）
Prettier 是目前最主流的“开箱即用”格式化工具，它不接受配置项博弈，强制统一风格。装它不是为了“多一个功能”，而是为了“关掉其他干扰”。
- 在 VSCode 扩展市场搜索
Prettier，安装官方发布的esbenp.prettier-vscode - 安装后，打开任意
.js或.ts文件，按下Shift+Alt+F（Windows）或Shift+Option+F（macOS）——应立即格式化 - 若无反应，检查设置中是否禁用了保存时格式化：
editor.formatOnSave设为true；同时确保[javascript].editor.defaultFormatter和[typescript].editor.defaultFormatter都设为esbenp.prettier-vscode
避免 ESLint 和 Prettier 冲突（常见报错：fix on save 不生效 / 保存后又被改回去）
很多人同时装了 ESLint 和 Prettier，结果发现保存时格式乱跳——这是因为 ESLint 的 eslint --fix 和 Prettier 各自修改代码，互相覆盖。
- 不要让 ESLint 承担格式化职责：在
.eslintrc.js中移除所有和格式相关的规则（如quotes、semi、comma-dangle），只保留逻辑/安全类规则（如no-unused-vars、eqeqeq） - 安装
eslint-config-prettier并在extends中追加它，它会自动关闭所有与 Prettier 冲突的 ESLint 规则 - 在 VSCode 设置中，把
eslint.format.enable设为false，明确交由 Prettier 负责格式化，ESLint 只做检查
项目级配置比用户级更可靠（尤其团队协作）
你在 VSCode 用户设置里配好了 Prettier，但同事打开项目还是格式混乱？因为 VSCode 优先读取项目根目录下的配置文件，而不是你的全局偏好。
- 在项目根目录放一个
.prettierrc（JSON 或 YAML），哪怕只是空对象{}，也能触发 VSCode 识别该项目启用 Prettier - 配合
.editorconfig统一基础编辑行为（如缩进大小、换行符），避免因编辑器差异导致 Git 提交脏 diff - 如果项目用 TypeScript，务必确认
prettier版本 ≥ 2.0，并在.prettierrc中添加"parser": "typescript"，否则可能解析失败报错Unexpected token 'const'
真正卡住人的往往不是“怎么装”，而是“谁在管”和“配置在哪生效”。一个项目里同时存在 settings.json、.prettierrc、.eslintrc.js、package.json 里的 prettier 字段时，优先级和隐式覆盖关系很容易被忽略。先关掉所有格式化扩展，再逐个启用并验证输出，比堆砌插件更有效。
