Windows控制台中文显示为问号或方块，根本原因是ANSI代码页（如GBK）与UTF-8源文件字节流不匹配；需统一编码链：源码存UTF-8无BOM、SetConsoleOutputCP(CP_UTF8)、chcp 65001，并用MultiByteToWideChar正确转换。
Windows 控制台输出中文显示为问号或方块
根本原因是 std::cout 默认使用系统 ANSI 代码页（如 GBK），而源文件若以 UTF-8 编码保存，就会字节流不匹配。Visual Studio 新建项目默认用 UTF-8 with BOM，但控制台启动时仍按活动代码页（chcp 查看，通常是 936）解码。
解决方法不是“统一改成 UTF-8”，而是让输入、编译、运行三者对齐：
- 源文件保存为
UTF-8 without BOM（VS 中“另存为 → 编码 → UTF-8”） - 在
main()开头添加：SetConsoleOutputCP(CP_UTF8);
（需#include <windows.h>） - 确保终端支持 UTF-8：运行
chcp 65001，或在 Windows 10/11 设置中启用“Beta: 使用 Unicode UTF-8 提供全球语言支持”（重启生效）
std::string 含 UTF-8 字节串，想转成宽字符 std::wstring
不能直接 reinterpret_cast 或逐字节赋值——UTF-8 是变长编码，一个汉字占 3 字节，wchar_t 在 Windows 是 UTF-16，需真正转换。
推荐用 Windows API MultiByteToWideChar：
立即学习“C++免费学习笔记（深入）”；
std::string utf8_str = "你好"; int wlen = MultiByteToWideChar(CP_UTF8, 0, utf8_str.c_str(), -1, nullptr, 0); std::wstring wstr(wlen, L'\0'); MultiByteToWideChar(CP_UTF8, 0, utf8_str.c_str(), -1, &wstr[0], wlen);
注意：-1 表示包含末尾 <p>注意：<code>-1 表示包含末尾 \0；wstr 长度要预留终止符空间；Linux/macOS 应改用 iconv 或 std::codecvt_utf8_utf16（C++17 已弃用，慎用）。
wstr 长度要预留终止符空间；Linux/macOS 应改用 iconv 或 std::codecvt_utf8_utf16（C++17 已弃用，慎用）。
读写中文路径或文件内容时出错（std::ifstream 打不开含中文的路径）
std::ifstream 构造函数只接受 const char*，无法传入 UTF-8 路径（Windows API 内部按 UTF-16 处理）。直接传中文路径会因编码截断失败。
正确做法是绕过标准库文件流，用 Windows 原生 API：
- 用
CreateFileW（带W后缀）打开文件，传L"中文路径.txt" - 或先用
MultiByteToWideChar将 UTF-8 路径转为std::wstring，再调用_wfopen（fopen的宽字符版） - 若坚持用
std::ifstream，C++17 起可尝试std::filesystem::path构造后隐式转换，但实际兼容性差，不建议生产环境依赖
跨平台项目里硬编码中文字符串导致 Linux 下崩溃
Linux 终端默认 UTF-8，但 wchar_t 在 GCC 是 4 字节（UTF-32），而 Windows 是 2 字节（UTF-16）。同一段 L"中文" 在两边二进制布局不同，std::wcout 行为不可移植。
更稳妥的做法是：
- 源文件统一存为 UTF-8（无 BOM）
- 所有用户可见字符串保持
std::string+ UTF-8 编码 - 仅在调用系统 API（如 Windows GUI 函数、Linux
setlocale(LC_ALL, "")后的printf）前做一次转换 - 避免
std::wstring跨平台传递——它本质是平台绑定类型，不是“通用宽字符”
真正难的不是转换函数怎么写，而是得清楚每一处字符串的生命周期：它从哪来（源码？网络？文件？）、到哪去（控制台？GUI控件？日志文件？）、中间是否被第三方库截断或重编码。漏掉一环，乱码就回来。
