根本原因是控制台编码与源文件编码不匹配：Windows 控制台默认 GBK，而 VS 默认 UTF-8 源码，需用 setlocale 配合 C 风格 I/O 或设置控制台代码页解决。
C++ 控制台输出中文乱码，根本原因不是代码写错了，而是控制台环境没告诉 C++ “我支持中文”——setlocale 是最直接有效的破局点，但必须配对使用、且仅对 C 风格 I/O 有效。
为什么 cout 输出中文还是乱码？
Windows 控制台默认使用 GBK 编码（如 cmd/powershell），而源文件若保存为 UTF-8（尤其 VS 默认），cout 实际发送的是 UTF-8 字节流，控制台按 GBK 解析就必然乱码。C++ 标准库本身不处理编码转换，setlocale 就是用来“对齐”这个预期的桥梁。
-
setlocale(LC_ALL, "")会读取系统区域设置（Windows 下通常对应 GBK），让printf/fputs等 C 函数能正确输出中文 -
std::cout不受setlocale影响——它走的是 C++ 流缓冲机制，和 locale 设置是两套体系 - 如果你混用
printf和cout，且只调了setlocale，会发现printf正常、cout仍乱码
setlocale 必须在哪儿调？参数怎么选？
位置不对等于白设：必须在任何中文输出操作之前调用，且推荐放在 main() 开头第一行。参数选择取决于目标环境：
- Windows 下最稳：
setlocale(LC_ALL, "Chinese_China.936")或简写setlocale(LC_ALL, ".936")（936 = GBK） - 用空字符串：
setlocale(LC_ALL, "")，依赖系统当前区域设置，可移植性好但不保险（比如用户改过区域） - Linux/macOS 一般用
setlocale(LC_ALL, "zh_CN.UTF-8")，但控制台需真支持 UTF-8，否则照样乱 - 千万别用
"C"或"POSIX"——这是纯 ASCII 模式，中文直接变问号或方块
想用 cout 输出中文？绕不开 imbue + codecvt_utf8（C++11~C++17）
如果坚持用 C++ 流，setlocale 不起作用，得换路子：std::wcout 配合宽字符和本地化 facet。但注意：codecvt_utf8 在 C++20 已被移除，新项目慎用。
立即学习“C++免费学习笔记（深入）”；
std::wcout.imbue(std::locale("")); // Windows 下需确保系统 locale 是中文
std::wcout << L"你好" << std::endl; // 必须用 L"" 前缀
- 必须用
std::wcout+L"..."，普通cout无法承载宽字符语义 -
imbue的 locale 参数同样要匹配系统编码，例如 Windows 上传""或"Chinese_China.936" - VS2019+ 默认禁用
codecvt，启用需加编译选项/Zc:char8_t-（非必需），但更推荐回归 C 风格输出
最简单可靠的方案：放弃 cout，改用 wprintf 或 SetConsoleOutputCP
工程实践中，与其折腾 C++ 流的 locale 适配，不如直击底层。Windows 平台两个轻量级解法：
- 用
wprintf(L"%ls", L"你好")，前提是已调setlocale(LC_ALL, "")，且源文件存为 UTF-8 with BOM（VS 默认） - 更彻底：启动时调
SetConsoleOutputCP(CP_UTF8)（需#include），再用printf输出 UTF-8 字符串——此时源文件必须存为 UTF-8 without BOM，否则编译器可能把 BOM 当作非法字符 - 注意：PowerShell 对 UTF-8 支持比 cmd 好，但旧版仍可能需手动执行
chcp 65001
真正麻烦的从来不是函数怎么写，而是编辑器编码、编译器解析、控制台解码这三层是否咬合。漏掉任意一环，setlocale 就只是个摆设。
