不能直接用std::string(ws.begin(), ws.end())，因为该写法将每个wchar_t（Windows为UTF-16、Linux/macOS为UTF-32）的二进制值逐字节截断转为char，而std::string仅为字节序列、不携带编码信息，导致乱码或崩溃；正确做法需明确目标编码（如UTF-8），Windows下推荐WideCharToMultiByte(CP_UTF8)，跨平台建议用utf8cpp或ICU。
为什么不能直接用 std::string(ws.begin(), ws.end())
这种写法看似简洁，但实际会把每个 wchar_t 的二进制值（通常是 2 或 4 字节）逐字节截断塞进 char，导致乱码或崩溃。Windows 上 wchar_t 是 UTF-16，Linux/macOS 通常是 UTF-32，而 std::string 本身不携带编码信息——它只是 char 序列，你得明确告诉系统“你想转成哪种编码的字节流”。
Windows 下推荐用 WideCharToMultiByte
这是 Windows API 中最可靠、性能好、支持指定目标编码的方式。关键点不是“能不能转”，而是“转成什么编码”：多数场景你需要 UTF-8（跨平台兼容），而不是系统默认的 ANSI 代码页。
- 目标编码用
CP_UTF8，不是0或CP_ACP - 先调用一次获取缓冲区大小（
0作为lpMultiByteStr），再分配内存并第二次调用 - 必须检查返回值：为
0表示失败，可用GetLastError()查原因（如无效代理对）
std::string wstring_to_utf8(const std::wstring& ws) {
if (ws.empty()) return {};
int size = WideCharToMultiByte(CP_UTF8, 0, ws.c_str(), -1, nullptr, 0, nullptr, nullptr);
if (size == 0) return {};
std::string s(size, '\0');
WideCharToMultiByte(CP_UTF8, 0, ws.c_str(), -1, &s[0], size, nullptr, nullptr);
s.pop_back(); // 去掉末尾的 '\0'
return s;
}
跨平台方案：用 std::codecvt_utf8<wchar_t></wchar_t>（C++11–17，已弃用但仍广泛可用）
标准库曾提供这个 facet，但它在 C++20 中被移除，且 MSVC 和 libstdc++ 实现不一致（GCC 默认禁用，Clang 可能崩溃）。仅建议临时过渡或构建环境可控时使用。
- 必须通过
std::wstring_convert包装，不能直接调用 facet - 注意 locale 构造：传空字符串可能绑定到系统 locale，导致非 UTF-8 行为
- 遇到无法转换的宽字符（如某些 emoji 的 surrogate pair 处理异常）可能抛
std::range_error
std::string wstring_to_utf8_std(const std::wstring& ws) {
try {
static std::wstring_convert<std::codecvt_utf8<wchar_t>> conv;
return conv.to_bytes(ws);
} catch (...) { return {}; }
}
真正安全的跨平台做法：用 ICU 或 utf8cpp
如果项目允许引入第三方依赖，utf8cpp（头文件库）或 ICU 是更健壮的选择。它们明确定义了 UTF-16 ↔ UTF-8 转换规则，正确处理 surrogate pairs、BOM、非法序列等边界情况。
立即学习“C++免费学习笔记（深入）”；
-
utf8cpp示例：用utf8::utf16to8(ws.begin(), ws.end(), back_inserter(s)) - ICU 示例：用
icu::UnicodeString中转，再调用toUTF8String() - 避免自己手写 UTF-16 解码逻辑——代理对判断、高位低位顺序、错误恢复都容易出错
很多开发者卡在“为什么我的中文变问号”，其实问题不在转换函数本身，而在没意识到 std::string 不是“字符串”，只是字节容器；你得清楚每一处 char 对应的是 UTF-8 还是 GBK 还是 Latin-1，否则后续写入文件、发 HTTP、传给 Python 都会出问题。
