先确认是终端输出还是程序自身输出：若乱码出现在集成终端，属vscode终端配置问题；若在debug console或外部窗口，则与程序运行时及系统环境变量相关。
运行结果乱码，先分清是终端输出还是程序自身输出
VSCode里看到的“运行结果乱码”，90%不是VSCode的问题，而是程序执行环境和编码预期不一致。关键要判断：乱码出现在集成终端（Terminal）里，还是调试控制台（Debug Console），或是外部命令行窗口？前者属于VSCode终端配置范畴，后者往往跟你的程序语言运行时、系统环境变量强相关。
终端里 print("中文") 显示乱码，检查 LANG 和字体
Linux/macOS 下终端乱码，大概率是 shell 环境没设对 UTF-8：
- 在终端里运行
echo $LANG，如果不是zh_CN.UTF-8或en_US.UTF-8，就得改~/.bashrc或~/.zshrc - 追加这两行：
export LANG=zh_CN.UTF-8和export PYTHONIOENCODING=utf-8（Python 项目尤其需要） - 改完别忘了
source ~/.zshrc，再重启 VSCode 终端 - 同时检查 VSCode 设置里的
terminal.integrated.fontFamily，确保设为支持中文的字体，比如"Fira Code", "Microsoft YaHei", "SimSun"
Python/C/Java 运行时输出乱码，得看语言层编码假设
即使终端编码正确，程序自己也可能“读错”或“写错”：
- Python 脚本开头没加
# -*- coding: utf-8 -*-，且文件实际是 GBK 编码 → 用Reopen with Encoding改成 GBK 再保存 - C 语言中字符串字面量含中文，但编译器（如
gcc）默认按 UTF-8 解析，而源文件是 GBK → 编译加-finput-charset=GBK -fexec-charset=UTF-8 - Java 的
.java文件用 GBK 保存，但javac按 UTF-8 读 → 编译时加-encoding GBK - Node.js 默认 UTF-8，一般没问题；但若读取了 GBK 编码的配置文件，要用
iconv-lite显式转码
别忽略 BOM 和自动保存编码的副作用
VSCode 默认保存为 UTF-8 无 BOM，但有些旧工具（如 Windows 记事本、某些 C++ 编译器）会把 UTF-8 with BOM 当作“带签名的 UTF-8”，导致多出 \ufeff 字符，表现为开头一个空格或异常符号：
- 右下角点击编码显示 → 选
Save with Encoding→ 改成UTF-8（注意不是UTF-8 with BOM） - 全局禁用 BOM：在
settings.json加"files.autoGuessEncoding": false和"files.encoding": "utf8"，避免自动插入 BOM - 如果项目必须兼容老工具，可临时用
iconv或Notepad++批量转存为 GBK，但长期建议统一迁移到 UTF-8
真正卡住人的，往往是终端编码、文件保存编码、程序运行时编码这三层之间有两层对不上——比如文件存的是 UTF-8，终端设的是 zh_CN.UTF-8，但 Python 解释器启动时没读到 PYTHONIOENCODING，就仍按系统 locale 解码 stdout，结果一串问号。这种链路问题，不能只调一个地方。
