Windows控制台默认GBK编码导致UTF-8中文乱码，需调用SetConsoleOutputCP(CP_UTF8)并保存源文件为UTF-8无BOM；宽字符输出需L"字符串"、imbue locale及禁用stdio同步；跨平台应避免依赖Windows特有API。
Windows 控制台默认编码不是 UTF-8
直接用 std::cout 输出中文，在 VS 或 CMD 里大概率是乱码——不是代码写错了，是控制台根本没准备好读 UTF-8。Windows 控制台默认用的是 GBK（CP936），而现代 C++ 源文件通常保存为 UTF-8，两者不匹配就崩。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 在程序开头加
SetConsoleOutputCP(CP_UTF8)（需#include），强制控制台用 UTF-8 解码输出 - 源文件必须存为「UTF-8 无 BOM」，否则 MSVC 可能按系统编码读取，导致字符串字面量本身已错
- VS 项目属性里把「字符集」设为「使用 Unicode 字符集」，避免
TCHAR相关隐式转换干扰
std::wcout 输出中文更可靠但要配齐三件套
用宽字符流 std::wcout 是更正统的解法，但它不像 std::cout 那样“开箱即用”，漏掉任意一环都会静默失败（比如什么也不输出、或只输出问号）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 字符串字面量必须写成
L"你好"，否则std::wcout会尝试把窄字符串当宽字符解释，结果不可控 - 调用
std::wcout.imbue(std::locale(""))，让宽流绑定系统本地 locale（Windows 下即Chinese_China.936或Chinese_China.65001） - 必须在首次使用前调用
std::ios_base::sync_with_stdio(false)，否则std::cout和std::wcout缓冲冲突，输出顺序错乱甚至卡死
跨平台输出中文别硬刚控制台编码
Linux/macOS 终端默认支持 UTF-8，std::cout 通常直接能用；但 Windows 上强求统一逻辑，反而容易在不同环境行为不一致。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 如果目标是日志文件或管道输出，直接用 UTF-8 +
std::ofstream（打开时加std::ios::binary，写入前手动写 BOM 或不写，视下游工具而定） - 避免在跨平台项目里依赖
SetConsoleOutputCP，它在非 Windows 下编译不过；可用#ifdef _WIN32包裹 - Qt、wxWidgets 等 GUI 框架自有文本渲染路径，完全绕过控制台编码问题，有 GUI 需求时优先走框架 API（如
QTextStream）
std::string 构造含中文的 JSON 或 HTTP body 时别被编码坑
很多人以为控制台能显示中文，字符串内容就“没问题”，结果发 HTTP 请求或写 JSON 时后端收不到正确中文——因为 std::string 里存的是 UTF-8 字节，但若你误用 .c_str() 后又被某些旧 API 当作 GBK 处理，就会二次转码出错。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 确认所有中间环节（curl、nlohmann::json、boost::beast）都明确声明输入是 UTF-8，不依赖 locale 自动推断
- 调试时用十六进制打印字符串前几个字节（如
for (auto b : s) printf("%02x ", (unsigned char)b);），验证 “你好” 是否真的是e4 bd,a0 e5,a5 bd（UTF-8 编码），而不是c4 e3 bac3（GBK） - 第三方库若要求传入
const char*且文档未说明编码，默认按 UTF-8 处理；若它内部调用MultiByteToWideChar，务必传CP_UTF8而非CP_ACP
