VSCode中切换文件编码唯一可靠方式是点击状态栏编码标识：先确保光标在目标文件编辑器，点击右下角UTF-8等编码文字，选择Reopen with Encoding（仅重解码）或Save with Encoding（重写磁盘），二者行为不同且不可互换。
VSCode里转义选中文本，别用快捷键硬记
VSCode 没有“一键转义选中内容”的原生快捷键。所谓 Ctrl+Shift+P 里搜“转义”出来的命令，本质是调用正则替换逻辑，不是独立功能模块。你真正能稳定用上的，只有 Ctrl+H（打开替换面板）+ 启用 .*（正则模式）这条路径。
常见错误是试图把 "、
、 一股脑塞进搜索框——不加转义会匹配失败；或者在替换框里写
却没开正则，结果真打出两个字符
而非换行。
- 搜索时要转义的字符：
→\，"→"，\n（注意：这里\n是让正则引擎匹配字面的换行符，不是插入换行） - 替换时要用的特殊含义：
\表示插入单个反斜杠 - 多字符批量处理建议分步：先双引号，再换行，再制表符——比写一个超长正则更可控，也方便回退
Reopen with Encoding 和 Save with Encoding 完全不是一回事
状态栏点击编码后弹出的两个选项，行为差异直接决定文件是否损坏。选错一次，可能就丢数据。
-
Reopen with Encoding：只改当前编辑器怎么“读”磁盘上的字节，不碰文件本身。适合排查乱码——试错成本低，按Ctrl+Z就能撤销重开 -
Save with Encoding：把当前编辑器里已解码的内容，**按新编码重新编码写回磁盘**。一旦保存，原始字节流被覆盖，不可逆 - 文件没保存过？
Save with Encoding选项是灰色的，必须先Ctrl+S存一次 - 右下角编码旁出现锁图标 ?？说明 VSCode 记住了你上次的手动选择，自动检测（Auto Detect）已失效，但
Reopen with Encoding仍可用
为什么不能给切换编码绑快捷键
VSCode 明确禁止通过 keybindings.json 直接触发编码变更。这不是功能缺失，而是设计约束。
- 绑定
workbench.action.unicodeEncoding只会打开菜单，不会执行任何操作——它不接受参数，也没法指定“用 UTF-8 重开”还是“用 GBK 保存” - 插件无法绕过：VSCode API 不提供
editor.document.saveAs(encoding)这类接口，所有写入必须经用户显式确认 - 所谓“快捷键切换”都是伪方案：比如用宏插件模拟鼠标点击状态栏，但依赖 UI 元素位置，Remote-SSH 或 Codespaces 下极易失效
- 唯一可配置的，是默认新建文件编码：
"files.encoding": "utf8"，但它对已打开文件完全无效
GBK 文件在 VSCode 里显示正常，但 Git 提交变乱码？
这问题不在 VSCode，而在 Git 的文本处理链路。VSCode 正确用 GBK 打开了，不代表 Git 知道该用什么编码处理它。
- Git 默认按字节操作，不解析编码。如果工作区是 GBK，而
core.autocrlf或core.safecrlf配置不当，换行符可能被误改 - GitHub Web 界面只认 UTF-8。提交 GBK 编码文件后，网页上中文全变成 ，但本地
git show仍能正常显示——因为 Git 没“转码”，只是渲染端错了 - 解决方案不是强求 VSCode 改编码，而是统一项目约定：
.gitattributes里加* text=auto eol=lf，再配合files.encoding设为utf8，从源头避免混用 - 已有 GBK 文件需迁移？先用
Reopen with Encoding确认内容无误，再用Save with Encoding存成 UTF-8，最后手动检查中文和特殊符号是否完整
实际操作中最容易被忽略的，是 Save with Encoding 的不可逆性，以及 Git 对编码的“无知”——VSCode 显示正常，不等于协作环境也安全。
