windows下std::cout输出中文乱码是因源文件编码、编译器解析、控制台解码三者未对齐；必须在main()开头立即调用setconsoleoutputcp(cp_utf8)使控制台识别utf-8字节流。
Windows 下 std::cout 输出中文显示为问号、方块或乱码，不是代码写错了，而是源文件编码、编译器解析、控制台解码三者没对齐。只改其中一环，大概率还是乱。
SetConsoleOutputCP(CP_UTF8) 必须在 main() 开头立即调用
这是 Windows 控制台识别 UTF-8 字节流的前提。不调用它，std::cout 就算源文件和编译都正确，控制台仍按默认 GBK（代码页 936）去解码，必然错位。
-
SetConsoleOutputCP(CP_UTF8)需#include <windows.h></windows.h>，且必须放在std::cout第一次输出之前 - 不要用
system("chcp 65001")替代——它只改 cmd 窗口的代码页，对已启动的进程无效 - 跨平台代码中必须用
#ifdef _WIN32包裹，否则 Linux/macOS 下编译直接报错：'SetConsoleOutputCP' was not declared in this scope - 如果程序还要读中文输入（比如
std::cin），额外加一句SetConsoleCP(CP_UTF8)
源文件必须存为 UTF-8 without BOM
VS Code、CLion 默认保存为 UTF-8 无 BOM，但 Visual Studio 新建文件默认是 UTF-8 with BOM。BOM（\xEF\xBB\xBF）会被 MSVC 当作非法字符处理，导致 error C2001: 常量中有换行符 或首字符异常。
- VS 用户：「文件 → 另存为 → 编码 → UTF-8」（注意不是「UTF-8 带签名」）
- VS Code 用户：右下角点击编码 → 选「UTF-8」→ 点击「以编码保存」
- 别信「自动检测」——编辑器有时会把带 BOM 的文件误判为 GBK，输出时多出三个乱码字节
g++/clang++ 编译时必须加 -finput-charset=UTF-8 -fexec-charset=UTF-8
GCC/Clang 默认把源文件当 Latin-1 处理。即使你存的是 UTF-8，“你好”也会被编译器拆成 6 个错误字节，运行时再怎么设控制台也没用。
-
-finput-charset=UTF-8：告诉编译器“源码是 UTF-8” -
-fexec-charset=UTF-8：决定字符串字面量在内存中以什么编码存储（关键！不加它，GCC 在 Windows 下默认用 GBK） - MSVC 不需要这些参数，但要确保项目属性里勾选了「UTF-8」或命令行加
/utf-8 - MinGW 用户注意：某些旧版 MinGW 缺少
SetConsoleOutputCP声明，需在#include <windows.h></windows.h>前加#define WIN32_LEAN_AND_MEAN
控制台字体不支持中文，照样显示为空格或方框
就算编码全对，Windows 控制台默认字体（如 Consolas、Courier New）不含中文字形。结果就是“字节对了，形没了”。
- 右键控制台标题栏 →「属性」→「字体」→ 选
Lucida Console（最稳）或NSimSun（宋体） - 别选
Microsoft YaHei——它不是等宽字体，表格、日志对齐会崩 - VS 调试控制台（Debug Console）行为和真实 CMD 不一致，验证效果务必在外部 CMD 或 Windows Terminal 中运行 exe
- Windows 10/11 可开启系统级 UTF-8 支持：设置 → 时间和语言 → 语言 → 管理语言 → 管理 Windows 语言设置 → 勾选「Beta: 使用 Unicode UTF-8 提供全球语言支持」（需重启）
最容易被忽略的是「三者同步」：源文件编码、编译器理解的编码、控制台解码的编码，缺一不可。很多人调了 SetConsoleOutputCP 就以为万事大吉，结果发现 VS 里调试输出正常，双击 exe 却还是乱码——那八成是字体没换，或者用了带 BOM 的源文件。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
