vscode自身不改逻辑，格式化扩展误配或混用（如eslint参与格式化、pretterr与clang-format规则冲突）才可能引入逻辑错误；必须隔离职责：prettier仅负责样式，eslint仅负责代码质量，并禁用eslint.format.enable。
editor.formatOnSave 开启后，VSCode 本身不会改变代码逻辑，但格式化扩展（如 Prettier、clang-format、ESLint）在特定配置或 bug 下可能引入逻辑错误——这不是编辑器问题，而是工具链误用或规则冲突的直接后果。
editor.formatOnSave 触发后代码行为突变？先查这三点
- 格式化扩展是否在重写代码结构而非仅调整空白符？例如：
-
clang-format的PointerAlignment: Left在 C++ 中可能把int<em> p</em>改成int p（语义不变），但若误配为PointerAlignment: Right且配合宏定义，可能影响类型推导 -
Prettier的arrowParens: "avoid"会把(x) => x + 1简化为x => x + 1，但如果原始代码是(x, y) => { ... }被错误缩略为x, y => { ... }（语法错误），说明插件版本过旧或配置被覆盖
-
- 是否启用了带修复能力的 Linter（如
ESLint）并和格式化混用？"editor.codeActionsOnSave": { "source.fixAll.eslint": true }可能自动插入return、删除console.log、甚至重写if (a) b(); else c();为三元表达式——这属于语义变更，不是格式化本职工作 - 文件编码不一致导致解析错乱：比如 C++ 项目用
files.encoding: "gb2312"，而源码含 UTF-8 中文注释，clang-format解析时字节偏移错位，把<em>it</em>拆成it或吞掉运算符
Prettier 和 ESLint 同时启用时，谁在偷偷改逻辑？
二者职责必须隔离，否则必然出事：
-
Prettier只管“怎么写好看”：缩进、换行、引号、分号、括号位置 -
ESLint只管“怎么写正确”：变量未使用、==替换为===、禁止eval - 若
eslint-config-prettier未禁用与 Prettier 冲突的规则（如semi、quotes），ESLint 的fix就会和 Prettier 反复拉扯，最终可能漏掉分号或改错引号类型，间接导致运行时错误（比如模板字符串中单引号未转义）
推荐设置：
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
},
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"eslint.enable": true,
"eslint.format.enable": false
关键点：eslint.format.enable 必须关掉——ESLint 不该参与格式化。
C++ / Python 等语言格式化“越整越错”的真实原因
这类问题几乎从不来自 VSCode，而是底层格式化工具与环境不匹配：
- C++：
C_Cpp.clang_format_style设为"file"，但项目根目录没放.clang-format，VSCode 就 fallback 到内置默认风格（可能是LLVM），而该风格对指针/引用符号的空格处理与项目历史代码不兼容 - Python：
python.formatting.provider设为"black"，但项目实际用autopep8风格（如允许行尾逗号、强制空行数不同），Black 会强行删逗号、合并空行，破坏已有测试断言的行号映射 - 所有语言共性陷阱：格式化工具读取了错误的配置文件层级。例如 VSCode 先加载用户级
~/.prettierrc，再被项目级.prettierrc覆盖；但如果项目里只有prettier.config.js而没导出module.exports，Prettier 就静默降级，按默认规则跑
最稳妥做法：在项目根目录放明确命名的配置文件（.prettierrc、.clang-format、pyproject.toml），并在 .vscode/settings.json 中显式指向它：
"[cpp]": {
"editor.defaultFormatter": "ms-vscode.cpptools",
"C_Cpp.clang_format_style": "file"
}
格式化工具链的复杂性不在表面开关，而在配置落地的每一层是否真正生效。最容易被忽略的是：你看到的“格式化结果”，往往混合了编辑器设置、语言扩展、外部 CLI 工具、项目配置文件、甚至 Git hooks 的多次介入。任何一层脱节，都可能让空格变成语法错误。
