不推荐自动猜测编码，如果实在需要不用UTF8，更合适的是针对不同语言用不同的设置：
首先，如果你没有注意到一个GBK编码的文件被VSC以UTF-8的编码打开了，又进行了保存，这个文件里的中文是找不回来的。大家可以试试以GBK保存一个文件，以UTF8打开，不修改任何内容，按一下ctrl+s，再以GBK打开。原来的内容已经变成锟斤拷了。
这是因为GBK中存在UTF-8不存在的二进制序列，而Unicode标准规定所有无法识别的字符全用同一个字符替代：U+FFFD。所以这个过程是不可逆的。
如果既不打开编码猜测，又不手动设置默认编码，即默认设置，那VSC打开所有文件就都用的是UTF8（当然UTF16等还是正常的），就有可能发生上面的事。
打开编码猜测时，猜对了就万事大吉。但如果猜错了（中文字较少时可能发生），编码一般是Windows 125X，如果你没注意到，还是可能发生上面的事。
而关闭编码猜测且设置全局默认编码为GBK，我想不出有什么理由这样做，除非你不是程序员。
我实际上使用的是默认设置。因为txt我默认用记事本打开，实在要用VSC打开我会特别注意，手动选择以GBK打开；其它语言我通通用UTF8，像C的源代码乱码只有可能是我在打开别人写的代码文件时发生，我也会特别注意。
现在来解释一下开头的设置。
对于txt来说，“ANSI”是最常见的编码；其它想用GBK的语言自己加。这样不会影响到所有其它正常使用UTF8的语言。注意语言和后缀并不完全相同，txt写的就是plaintext。
但这样仍存在缺点：
第一：源代码管理无法diff UTF16。这个现象非常少，基本没人用UTF16作为源代码。
第二：未指定直接新建文件(ctrl + n)的语言时默认用的是plaintext，会受到这个设置的影响。这一点还是有点坑的。
第三：不知从什么时候开始，记事本保存的时候已经使用的是UTF8了。一旦像上面这样指定，即使开启了猜测编码（且即使本来能猜出正确的编码），打开txt还是会用GBK。
所以结论是：如果你确定要在VSC上写某种以GBK为主的语言，就像开头那样设置吧，批处理就属于这样。如果仅仅是偶尔打开GBK文件，且发生过猜测错误的现象，那我建议像我一样用默认设置，人工辨别。如果你不担心猜错，那就自动猜测咯。
而理论上最合适的方式：指定允许猜测哪些编码，（比如只在UTF8和GBK中猜），还未实现。大家可以Follow：Allow to configure a list of encodings to use when guessing · Issue #36951 · microsoft/vscode 一旦实现，此问题应该能得到良好解决。UTF8和GBK之间猜错，可能性应该是非常小的。
---
扩展商店里有一个“GBKtoUTF8”扩展（看起来作者就在本回答里）。理论上如果VSC检测出的是GBK编码的，它就会自动做“以UTF-8格式保存”这个操作；但如果VSC没有检测出是GBK编码，它就什么也不会做，就会发生上面加粗文字的事情。
而且貌似它有bug，会把当前文件复制一遍插入到光标处，见 VS code 很好用，但是有个恶心的bug，大家谨慎！大神帮解决一下 以及那个答主的评论区。它也很久没有更新了。总之不推荐使用。
