git 默认跟踪文件权限变更导致 vscode 保存时误报修改；推荐全局执行 git config --global core.filemode false 关闭权限跟踪，已有脏状态需先 git reset --hard；当前仓库禁用则运行 git config core.filemode false。
Git 为什么把文件权限改动能当成修改
Linux/macOS 下 Git 默认会跟踪 chmod 变化（比如从 644 变成 755），而 VSCode 在保存文件时可能悄悄重设权限（尤其通过远程开发、WSL 或某些插件），导致大量“看似没改内容却显示已修改”的文件。这不是 VSCode 的 bug，是 Git 的默认行为在作祟。
全局关闭 Git 的文件权限跟踪（推荐）
对绝大多数项目（尤其是跨平台协作的），根本不需要 Git 管理权限位。执行这条命令即可一劳永逸：
git config --global core.filemode false
这样 Git 就完全忽略 chmod 变化，VSCode 保存后也不会再冒出一堆权限相关修改。注意：该设置只影响后续的 git status 判断，不会自动恢复已暂存的权限变更——如果已有大量误提交的权限修改，先用 git reset --hard 清掉工作区脏状态，再运行上面命令。
只对当前仓库禁用（临时或特殊场景）
某些项目确实需要保留权限（如 shell 脚本必须 755），那就别动全局配置，只关当前库：
- 进项目根目录，运行
git config core.filemode false - 检查是否生效：
git config core.filemode应输出false - 如果之前已因权限产生脏状态，运行
git update-index --chmod=-x *（去掉所有可执行位标记）或git add --chmod=+x path/to/script.sh（仅加特定文件）
VSCode 插件或设置可能干扰权限（容易被忽略）
有些插件（比如 Remote-SSH、SFTP 同步工具）或用户设置了 "files.autoSave": "onFocusChange" + WSL 文件系统，会在保存时触发权限重置。排查时注意：
- 关掉所有非必要插件，看问题是否消失
- 检查 VSCode 设置里有没有启用
files.preserveWatchers或remote.SSH.useLocalServer（后者在旧版中曾引发权限同步异常） - 终端里直接用
ls -l对比 VSCode 保存前后某个文件的权限，确认是不是编辑器本身在改
真正麻烦的不是怎么关，而是很多人改了 core.filemode 却忘了 git reset 已有的权限脏状态，结果还是满屏红色。另外，Windows 用户如果用 Git for Windows，默认就是 core.filemode false，但一旦切到 WSL 里操作同一仓库，就得单独配一次——这点特别容易漏。
