VSCode格式化本身不直接导致Git冲突，但多人协作中缺乏统一规则、时机和工具控制时，会因格式差异（如引号、分号、换行符）及保存/修复机制冲突（如Pretterr与ESLint争抢）显著增加冲突概率。
VSCode格式化本身不会直接导致Git冲突，但格式化行为若在多人协作中缺乏统一控制，就会让冲突概率飙升——尤其是当不同人用不同规则、不同时机、不同工具格式化同一段代码时。
formatOnSave + 未统一配置 = 冲突温床
很多团队开启 editor.formatOnSave，却没同步 .prettierrc 或 .editorconfig 到仓库，结果是：
- 开发者A保存时把
const foo = bar;格式化成单引号+分号，B却用双引号+无分号 - 同一行代码被反复“来回改”，Git 认为这是真实业务修改，合并时必然标红冲突
- VSCode 的语言特定设置（如
"[javascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }）若只写在用户级 settings.json，团队成员根本看不到
Prettier 和 ESLint 同时 fixAll 会互相覆盖
当 editor.codeActionsOnSave 同时启用 "source.fixAll.eslint" 和 editor.formatOnSave（背后是 Prettier），二者会在保存瞬间争抢同一段代码：
Evez Github Manager
下载
在 OpenClaw 中管理 GitHub 仓库、Pull Request、Issue 与工作流。适用于审查 PR、管理 Issue、自动化 GitHub Actions、同步仓库等场景。
- ESLint 先加了分号，Prettier 紧接着删掉 → 编辑器卡顿、光标跳动、保存失败
- 更糟的是：某次只触发了 ESLint 修复，另一次只走了 Prettier，导致同个文件在不同人本地产生不一致的 diff
- 正确做法是二选一：要么关掉
editor.formatOnSave，只靠source.fixAll.eslint（需配eslint-config-prettier）；要么开formatOnSave，但禁用 ESLint 的自动修复，改用提交前 lint-staged 统一处理
Git 提交前格式化没限定范围，反而放大冲突
用 husky + lint-staged 做 pre-commit 格式化时，如果 glob 模式太宽（比如 "*" 或 "src/**"），就可能：
- 格式化了别人刚暂存、但你本地还没拉取的文件 → 提交后引入大量无关变更
- 对 JSON、YAML 等配置文件也执行 Prettier，导致字段顺序重排，Git 显示整块差异（实际内容没变）
- 建议严格限定：只处理暂存区中真正被修改的源码文件，例如
"*.{js,ts,jsx,tsx}"，并配合git add回写，避免漏掉格式化后的变更
换行符 + 自动保存 = 隐形冲突制造机
VSCode 默认开启 files.autoSave: "afterDelay"，而 Windows/macOS/Linux 对 \r\n 和 \n 处理不一致：
- 你编辑完保存，VSCode 自动把 LF 转成 CRLF（或反之），Git 就认为整行都变了
- 这种“空变更”混在真实逻辑修改里，拉取/合并时极难分辨哪些是真冲突、哪些是噪音
- 必须全局统一：
git config --global core.autocrlf input（macOS/Linux）或true（Windows），并在项目根目录放.gitattributes显式声明* text=auto eol=lf
最易被忽略的一点：格式化冲突往往不是发生在「你改了什么」，而是发生在「你什么时候、用什么、改了谁的代码」——所有自动化动作都必须有明确边界和团队共识，否则越自动化，越容易把协作拖进泥潭。
