根本原因是Windows（默认GBK）与macOS/Linux（默认UTF-8）对同一字节流使用不同编码解读；只要保存与打开编码不一致，乱码必然发生，本质是跨平台编码规则冲突而非文件损坏。
跨平台同步代码时出现中文乱码，根本原因不是文件“坏了”，而是 Windows（默认 GBK）和 macOS/Linux（默认 UTF-8）对同一份字节流用了不同编码去解读。只要文件保存时的编码和打开时的编码不一致，乱码就必然发生——这不是 VSCode 的 bug，是编码规则在不同系统间天然存在的冲突。
为什么 Git 同步后 Windows 上打开是乱码，macOS 上却正常
Git 本身不转换编码，它只原样存储文件的字节。当你在 macOS 上用 UTF-8 保存一个含中文的 .py 文件并提交，Git 存的就是 UTF-8 字节序列（如 E4 B8 AD 表示“中”）。Windows 上的 VSCode 默认按 GBK 解码这串字节，把 E4 B8 当作一个双字节字符处理，结果就是“涓”。反过来，如果文件是 Windows 上用 GBK 保存的（D6 D0），macOS 上用 UTF-8 解，也会出错。
- Git 不会自动重编码文件，也不会提示你编码冲突
- VSCode 在 Windows 上默认读取无 BOM 的纯中文文本时，大概率猜成 GBK；macOS 上则倾向猜 UTF-8
- 即使你在 Windows 上手动设了
files.encoding为utf8，只要文件没带 BOM，下次别人拉下来仍可能被误判
强制统一为 UTF-8 并保留 BOM（仅限 Windows 场景）
UTF-8 是跨平台唯一稳妥选择，但 Windows 上某些老工具（如批处理、部分终端）对无 BOM 的 UTF-8 支持差。加 BOM 能让 VSCode 和多数 Windows 工具稳稳识别编码，代价是文件开头多三个字节 EF BB BF，对现代程序完全无害。
- 在 VSCode 中打开乱码文件 → 点右下角编码显示（如
GBK）→ 选Reopen with Encoding→ 找到并选UTF-8 with BOM - 确认中文显示正常后，点同个编码按钮 → 选
Save with Encoding→ 再次选UTF-8 with BOM - 保存后提交 Git，这样所有平台打开都会优先识别为 UTF-8
- 注意：
UTF-8 with BOM不推荐用于 Linux/macOS 原生脚本（如#!/usr/bin/env python3开头的文件），BOM 可能导致解释器报错
按文件类型配置默认编码，避免每次手动切
靠状态栏点来点去只适合救急，团队协作必须靠配置固化行为。关键是把 settings.json 里 files.associations 和 files.encoding 配对使用，让不同后缀走不同策略。
- 打开命令面板（
Ctrl+Shift+P/Cmd+Shift+P），输入Preferences: Open Settings (JSON) - 添加如下内容（示例）：
{ "files.encoding": "utf8", "files.autoGuessEncoding": false, "files.associations": { "*.java": "utf8", "*.py": "utf8", "*.md": "utf8", "*.txt": "gbk", "*.log": "gb2312" } } -
files.autoGuessEncoding关掉很关键：自动猜测在跨平台场景下错误率极高，尤其对短文本或纯中文内容 -
*.txt和*.log设为gbk是为了兼容 Windows 本地生成的日志/文本，避免打开即乱
终端输出乱码别跟文件编码混为一谈
你在 VSCode 集成终端里跑 Python，看到中文是“”，这跟上面说的文件编码无关。这是终端自身的代码页（Windows）或 locale（macOS/Linux）不支持 UTF-8 输出导致的。
- Windows：终端默认代码页是
936（GBK），运行chcp 65001切到 UTF-8，再执行脚本 - macOS/Linux：检查
locale输出是否含UTF-8，不是就改~/.zshrc加export LANG=en_US.UTF-8 - Python 脚本里不要依赖
sys.getdefaultencoding()，显式用print("中文".encode('utf8').decode('utf8'))测试终端直通能力 - VSCode 终端编码设置在
terminal.integrated.defaultProfile和terminal.integrated.env里，但通常修系统级环境更可靠
最易被忽略的一点：BOM 是把双刃剑。它能帮 Windows 工具认出 UTF-8，但也会让某些构建工具（如 Webpack、Makefile）把 BOM 当作非法字符报错。所以统一编码不能只靠加 BOM，得从源头约束——团队约定所有源码文件必须用 UTF-8 无 BOM 提交，并在 .editorconfig 里写死 charset = utf-8，这才是可持续方案。
