不能直接用string构造wstring，因二者是不同编码的字节序列与宽字符序列；windows下推荐multibytetowidechar，跨平台可用std::codecvt_utf8（c++17弃用但实用）或icu等第三方库。
直接结论：不能用简单强制转换或构造函数，必须经过编码转换；Windows 下优先用 MultiByteToWideChar，跨平台推荐 std::codecvt_utf8<wchar_t></wchar_t>（C++17 起已弃用，但仍有实际价值）或第三方库如 ICU / std::text（C++23）。
为什么 string 不能直接构造 wstring
因为 std::string 是字节序列，std::wstring 是宽字符序列，二者无隐式映射关系。直接写 std::wstring ws(s.begin(), s.end()) 只是把每个 char 当作低字节塞进 wchar_t，在 UTF-8 下完全错误，在 GBK 下也大概率乱码。
常见错误现象：
- 中文显示为方块、问号或一堆乱码
- 调用
MessageBoxW或CreateFileW时路径无效 - 日志里出现
\uFFFD（Unicode 替换字符）
Windows 平台推荐：用 MultiByteToWideChar
这是 Win32 API 中最可靠、性能好、支持多种代码页（如 CP_UTF8、CP_ACP、CP_OEMCP）的方案，且能处理错误和截断。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 明确源编码：UTF-8 用
CP_UTF8；系统默认 ANSI（如简体中文 Win10 默认 GBK）用CP_ACP - 先调用一次获取所需缓冲区大小（传
nullptr和0），再分配wchar_t数组 - 检查返回值是否为
0，失败时用GetLastError()排查（如ERROR_INSUFFICIENT_BUFFER或ERROR_NO_UNICODE_TRANSLATION）
示例（UTF-8 → wstring）：
std::string s = "你好，世界";
int len = MultiByteToWideChar(CP_UTF8, 0, s.c_str(), -1, nullptr, 0);
if (len == 0) { /* error */ }
std::vector<wchar_t> buf(len);
MultiByteToWideChar(CP_UTF8, 0, s.c_str(), -1, buf.data(), len);
std::wstring ws(buf.data());跨平台可移植方案：std::wstring_convert（C++11–C++17）与替代思路
std::wstring_convert<:codecvt_utf8>></:codecvt_utf8> 曾是标准库唯一“开箱即用”的 UTF-8 ↔ wstring 转换器，但 C++17 起被标记为弃用，主因是 std::codecvt 设计僵硬、不支持状态、难以扩展。不过只要你不升级到严格 C++20 模式，它仍在多数编译器中可用。
更现实的选择：
- 若仅需 UTF-8 ↔ UTF-16/32（即
std::u16string/std::u32string），用std::from_chars/std::to_chars不适用，改用std::mbrtoc16/c16rtomb等 C11 函数（注意：glibc 实现不完整，macOS 支持较好） - 生产环境建议引入轻量封装，比如用
iconv（POSIX）或utf8cpp（header-only，仅 UTF-8 处理） - C++23 起可关注
<text></text>头文件中的std::text::encode/decode，但目前主流编译器尚未实现
容易被忽略的关键点
宽字符不是“万能 Unicode 容器”：Windows 上 wchar_t 是 UTF-16（可能含代理对），Linux/macOS 上通常是 UTF-32 —— 同一段 std::wstring 在不同平台含义不同。不要假设 ws.size() 等于字符数（遇到代理对时会是 2）。
真正麻烦的从来不是转换函数本身，而是编码源头是否可信：读文件没指定 std::ios::binary + BOM 判断？HTTP 响应头 Content-Type: text/plain; charset=gb2312 被当成 UTF-8 解析？这些比选哪个 API 更容易导致崩溃或静默错误。
