chcp 65001仅临时生效，关终端即失效；须在settings.json中通过terminal.integrated.profiles.windows为PowerShell/cmd配置启动参数（如"-NoExit -Command $OutputEncoding=[Console]::OutputEncoding=[System.Text.Encoding]::UTF8;chcp 65001>$null"），并设terminal.integrated.env.windows为{"PYTHONIOENCODING":"utf-8"}，最后彻底重启VSCode。
chcp 65001 只是临时修复，关掉终端就失效
在 VSCode 终端里敲 chcp 65001 确实能让当前会话显示中文，但这是 shell 层面的单次设置。VSCode 每新建一个终端，都会重新启动 cmd 或 PowerShell 进程，而 Windows 默认代码页仍是 936（GBK），所以乱码立刻回归。这不是操作没用，而是它根本没被“固化”进终端启动流程。
真正要解决，得让每次新终端一打开就自动执行 chcp 65001，同时还要确保输出流本身也走 UTF-8——尤其对 PowerShell 来说，chcp 只改控制台输入/输出页，不改 PowerShell 自己的 $OutputEncoding，两者必须同步。
- cmd 场景：靠
terminal.integrated.shellArgs.windows加["/c", "chcp 65001 > nul && cmd.exe"] - PowerShell 场景：不能只靠
chcp，必须在args中同时设置$OutputEncoding和代码页 - 所有修改后，必须手动关闭所有已打开的终端标签页，再按
Ctrl + `新建——旧终端不会刷新编码
PowerShell 终端必须同时设 $OutputEncoding 和 chcp
PowerShell 的乱码比 cmd 更隐蔽：即使 chcp 显示 65001，Write-Host "你好" 仍可能变方块。因为 PowerShell 默认用 UTF-16 输出，而 VSCode 终端渲染器期望的是 UTF-8 字节流。只改代码页不管用，必须显式重置输出编码。
正确做法是在终端 profile 的 args 里把两件事串起来：
"PowerShell": {
"source": "PowerShell",
"args": [
"-NoExit",
"-Command",
"$OutputEncoding = [Console]::OutputEncoding = [System.Text.Encoding]::UTF8; chcp 65001 > $null"
]
}
- 顺序不能反：先设
$OutputEncoding，再chcp，否则部分命令（如git log）仍可能走旧编码 -
> $null是为了隐藏Active code page: 65001这行提示，避免干扰输出 - 如果用了自定义 PowerShell 配置文件（
$PROFILE），里面也设了$OutputEncoding，和这里冲突时以后者为准
terminal.integrated.encoding 是个无效配置项
很多人在设置里搜到 terminal.integrated.encoding 并设为 utf8，结果毫无作用——这个配置项在 VSCode 1.80+ 版本中已被废弃，文档里还留着，但实际不生效。VSCode 终端根本不读这个值，它完全依赖底层 shell 进程的编码行为。
真正起效的只有三类配置：
-
terminal.integrated.defaultProfile.windows：指定默认用哪个 shell（"PowerShell"还是"Command Prompt"） -
terminal.integrated.profiles.windows：给每个 shell 定义启动参数，包括args和source -
terminal.integrated.env.windows：可注入环境变量，比如{"PYTHONIOENCODING": "utf-8"}，这对 Python 脚本输出很关键
别在 encoding 上浪费时间，它现在就是个空壳。
混合环境（如 Remote-WSL + 本地终端）要分层验证
如果你用 Windows 版 VSCode 连 WSL，又在同一个窗口里开了本地 PowerShell 终端，那这两个终端的编码来源完全不同：WSL 终端由 Linux 系统的 locale 和 LANG 决定，本地终端则受 Windows 代码页和 PowerShell 配置影响。改了 VSCode 设置，只会影响本地终端；改了 WSL 的 /etc/default/locale，只会影响远程终端。
排查时必须分清楚当前乱码发生在哪一层：
- 执行
git log乱码 → 看 git 配置和 shell 编码是否一致 -
python -c "print('你好')"乱码 → 检查PYTHONIOENCODING环境变量和 Python 源文件保存编码 - 路径含中文的
cd失败 → 说明 shell 启动时就读错了当前目录名，问题出在进程初始化阶段，不是输出渲染
最常被忽略的是：Windows 系统级的「Beta 版：使用 Unicode UTF-8 提供全球语言支持」选项。它影响所有新创建的控制台进程，但启用后需重启系统才彻底生效——很多用户改了 VSCode 配置却忘了这一步，导致始终差一口气。
