全局设置不能替代项目级配置，editor.formatonsave盲目开启会导致风格冲突、格式化失效或保存卡死；editor.defaultformatter仅兜底生效，语言块配置优先级更高；真正全局有效的仅有formatonsave、formatonpaste和tabsize等少数设置。
全局设置不能替代项目级配置，盲目开 editor.formatOnSave 会导致不同项目风格冲突、格式化失效甚至保存卡死。
为什么全局 defaultFormatter 大多时候没用
VSCode 的 editor.defaultFormatter 全局设置只在“找不到语言专属配置”时兜底生效。而真实项目中，你几乎总会遇到：[javascript]、[typescript]、[python] 这类语言块配置——它们优先级更高，会直接覆盖全局值。
常见后果是：你设了全局用 esbenp.prettier-vscode，但打开一个 .py 文件，它依然调用 ms-python.black-formatter（因为 Python 语言块存在且已启用）。
更麻烦的是，某些扩展（如 Vue、Svelte 支持）根本不响应全局 defaultFormatter，必须显式声明 [vue] 或 [svelte] 块，否则按 Shift+Alt+F 就是静默失败。
- 检查方式：打开任意文件 →
Ctrl+Shift+P→ 输入Format Document With，看列表里有没有你期望的格式化器 - 若列表为空，说明该语言未被当前格式化扩展支持，或扩展未启用
- 若列表有多个选项但默认不是你想要的，说明语言块配置缺失或写错了 ID
哪些设置真能全局生效
真正跨语言、稳定起效的全局项其实很少，但以下三个最实用：
-
"editor.formatOnSave": true—— 开启后，只要当前文件有匹配的格式化器，就会触发；但它不保证“用谁”，只负责“喊一声” -
"editor.formatOnPaste": true—— 粘贴代码时自动整理缩进和换行，对写 Markdown、JSON、YAML 特别友好 -
"editor.tabSize": 2（或4）—— 所有语言默认缩进宽度，.editorconfig会覆盖它，但没配.editorconfig时它就是最终决定者
注意："editor.formatOnType": true 虽然也是全局开关，但对 JS/TS 外的语言基本无效，且容易在输入过程中频繁触发，打断思路，不建议开启。
全局设置 + 项目配置的正确协作方式
全局设置只该做两件事：统一基础行为（如自动保存、粘贴格式化）、提供 fallback 格式器。所有具体规则（用单引号还是双引号、是否加分号）必须下沉到项目级。
典型错误路径：
用户在全局 settings.json 里配了 "semi": false 和 "singleQuote": true —— 这些根本不会被 VSCode 解析，因为它们是 prettier 的配置项，不是 VSCode 的。
正确做法是：
- 在项目根目录放
.prettierrc.json（内容是{"semi": false, "singleQuote": true}） - 在
.vscode/settings.json里只写语言块和开关："[javascript]": {"editor.defaultFormatter": "esbenp.prettier-vscode"} - 把
.vscode/settings.json提交进 Git，让团队成员开箱即用
这样，全局设置管“要不要做”，项目配置管“怎么做”和“用谁做”，边界清晰，改起来也不怕误伤其他项目。
容易被忽略的编码层干扰
格式化看似只是空格换行的事，但底层依赖文件编码。如果 VSCode 读取文件时用了错误编码（比如把 UTF-8 文件当 GBK 解，或反之），Prettier 解析 AST 就会失败，直接报错 Invalid character 或静默跳过。
排查方法：
- 看右下角状态栏显示的编码（如
UTF-8），点击它确认是否与文件实际编码一致 - 在
.vscode/settings.json中加一行："files.encoding": "utf8"，强制统一读取编码 - 避免在 Windows 上用记事本另存为文件，它默认用
GBK，极易引发格式化崩溃
这个点不常被提到，但一旦出问题，你会花大量时间怀疑插件或配置，而实际只是编辑器“没读懂”你的文件。
