Windows下std::cout输出中文乱码的根本原因是控制台代码页、源文件编码、编译器解释和C++流实现四者未对齐；可靠解法是SetConsoleOutputCP(CP_UTF8)配合禁用stdio同步。
Windows 控制台默认用 GBK 编码，而 C++ 源文件若保存为 UTF-8（无 BOM），std::cout 直接输出中文就会显示乱码——这不是 C++ 本身的问题，而是终端、源码、运行时 locale 三者没对齐。
setlocale(LC_ALL, "") 为什么有时无效？
调用 setlocale(LC_ALL, "") 是让程序继承系统区域设置，但它只影响 C 风格的 I/O（如 printf）和部分 C 标准库函数（如 strftime），对 C++ 的 std::cout 默认无效，因为 std::cout 绑定的是窄字符流，且未与 C locale 同步。
- 在 Windows 上，
""通常解析为"Chinese_China.936"（即 GBK），但若你的源文件是 UTF-8，字面量字符串（如"你好"）会被编译器按源文件编码解释，再以当前 locale 尝试转换，结果错位 - Linux/macOS 下
setlocale(LC_ALL, "")通常能生效，因为终端多为 UTF-8，且 libc 与 libstdc++/libc++ 耦合更紧 - VS2015 及之后版本需额外调用
_setmode(_fileno(stdout), _O_U16TEXT)才能让wcout正常输出 UTF-16，但这不适用于cout
Windows 下用 cout 输出中文的可靠做法
放弃让 std::cout 原生支持 UTF-8，改走宽字符路径，或手动转码。最轻量且兼容的做法是：强制使用 UTF-8 源码 + 控制台切换代码页 + 禁用流缓冲同步。
- 确保源文件保存为 UTF-8 无 BOM（VS 中“高级保存选项”里选）
- 程序开头加：
SetConsoleOutputCP(CP_UTF8);（需#include），这直接让控制台接收 UTF-8 字节流 - 关闭
std::cin/std::cout与 C stdio 的同步：std::ios_base::sync_with_stdio(false);，避免因缓冲机制导致输出错乱 - 不要依赖
setlocale，它此时反而可能干扰（比如设成 GBK 后再输出 UTF-8 字节，会双重解码）
示例：
立即学习“C++免费学习笔记（深入）”；
#include#include int main() { SetConsoleOutputCP(CP_UTF8); std::ios_base::sync_with_stdio(false); std::cout << "你好，世界！\n"; }
读写含中文的文件时怎么设编码？
C++ 标准库的 std::ifstream/std::ofstream 没有编码参数，它们只做字节搬运。所谓“UTF-8 文件读取”，本质是你自己负责把读出的字节按 UTF-8 解码为 Unicode（如转 std::u32string），或确保内容纯 ASCII/GBK 且终端匹配。
- 若文件是 UTF-8，用
std::ifstream以二进制模式打开（std::ios::binary），再用第三方库（如utf8cpp）或 Windows API（MultiByteToWideChar）解码 - 若坚持用窄字符流读写 GBK 文件，在 Windows 上可先
setlocale(LC_CTYPE, "Chinese_China.936")，再用fopen（而非std::fstream），因为fopen受 locale 影响 - 跨平台项目建议统一用
std::wifstream/std::wofstream+ UTF-16（Windows）或 UTF-8（Linux/macOS），但需注意std::codecvt_utf8在 C++17 已被弃用，新代码应避免
容易被忽略的关键点
很多人卡在“明明 setlocale 了，cout 还是乱码”，其实根本原因在于：控制台代码页、源文件编码、编译器解释方式、C++ 流的底层实现，四者必须一致才可能“看起来正常”。其中控制台代码页（chcp 命令查）是最终决定者——它不认 UTF-8，除非你用 SetConsoleOutputCP(CP_UTF8) 显式开启（Win10 1903+ 支持）。旧版 Windows 不支持该 API 时，只能退回到 GBK 源码 + GBK 控制台的组合，否则必乱。
