必须在cmd.exe启动时执行chcp 65001，因其默认cp936启动而python等工具输出utf-8字节流，导致中文显示为□或问号；需配置terminal.integrated.profiles.windows的args为["/k","chcp","65001"]，并设pythonioencoding=utf-8及中文字体链。
chcp 65001 必须在 cmd.exe 启动时执行，不能靠手动补
VSCode 里 cmd.exe 默认用 CP936（GBK）启动，但 Python、Node 等工具默认输出 UTF-8 字节流，终端却按 GBK 解码——结果就是 print("你好") 显示 □ 或问号。临时输 chcp 65001 能立刻变正常，但新开终端又回退，这不是操作问题，是配置没生效。
关键点在于：cmd.exe 启动时必须带参数自动执行该命令，不是靠后续交互。正确做法是修改 terminal.integrated.profiles.windows：
-
"args": ["/k", "chcp", "65001"]——/k保证命令执行后保持窗口打开；/c会直接退出，不能用 - JSON 格式必须合法，尤其注意逗号位置和引号闭合，拼错一个字符整个 profile 就不加载
- 改完保存后，必须关闭所有已打开的终端页签，再按
Ctrl + Shift + `新开——旧进程不会重读配置，也不会刷新代码页
验证 chcp 是否真生效，别信“看起来正常”
很多人改完配置就跑脚本，发现还是乱码，其实根本没生效。新开终端后第一件事不是写代码，而是运行两行验证命令：
-
chcp—— 输出必须是活动代码页: 65001，不是936或其他数字 -
echo %PYTHONIOENCODING%—— 若为空，说明环境变量没配，Python 仍可能 fallback 到 cp936
如果 chcp 返回不是 65001，常见原因有：JSON 层级写错（比如写成 terminal.integrated.profiles 漏了 .windows），或误加了多余逗号导致解析失败。
必须配 PYTHONIOENCODING=utf-8，否则 Python 还是认 CP936
即使 chcp 65001 成功了，python -c "import sys; print(sys.stdout.encoding)" 仍可能输出 cp936。这是因为 Python 启动时读取的是父进程（cmd.exe）初始代码页，不是动态感知变化后的值。
微软正式发布 Visual Studio Code 1.118 版本 。本次更新重点强化了 AI 开发体验与企业管理能力，其中最引人注目的是新增 Copilot CLI 远程控制功能，允许开发者通过手机或网页远程监控和接管 AI 会话 。同时，为了提高 AI 的运行性价比，新版本优化了令牌缓存策略以降低成本 。此外，1.118 版还引入了 Chronicle 本地历史追踪、TypeScript 7.0 支持以及更严格的企业级访问管控 。
解决方式是在 terminal.integrated.env.windows 中强制注入环境变量：
-
"PYTHONIOENCODING": "utf-8"—— 让 Python 的 stdin/stdout/stderr 全部走 UTF-8 编码 - 不要用
set PYTHONIOENCODING=utf-8 & python xxx.py这种手动前缀，容易漏、难维护 - 别碰
[Console]::OutputEncoding，它只影响 .NET API，对 Python 子进程完全无效
字体链要显式指定含中文的等宽字体
编码对了，但显示仍是空格或小方块？那大概率是字体问题。Consolas、Fira Code 这类主流等宽字体不含中文字形，VSCode fallback 行为不稳定，尤其开启连字（ligature）时容易断掉。
解决方案是显式配置 terminal.integrated.fontFamily，把中文字体放在英文之后：
- 推荐组合：
"Fira Code", "Microsoft YaHei Mono", "SimSun" - 顺序很重要：前面字体负责英文和符号渲染，后面字体只兜底中文，避免覆盖英文效果
- 不要只写
"SimSun"，它不是等宽字体，会导致对齐错乱
真正麻烦的不是配哪几项，而是每一项都得单独验证——chcp、sys.stdout.encoding、echo %PYTHONIOENCODING%、终端实际渲染效果，缺一不可。少验一步，就可能以为修好了，结果跑个 subprocess 又崩。
