wchar_t大小因平台而异：Windows为2字节（UTF-16），Linux/macOS通常为4字节（UTF-32）；L""与""类型不兼容，混用导致乱码或编译错误；需整套切换宽字符函数、流和容器；wchar_t不等价于Unicode安全，推荐UTF-8或ICU库。
宽字符 wchar_t 和普通字符 char 的内存大小不同
同一个变量声明，sizeof(char) 几乎总是 1，而 sizeof(wchar_t) 在 Windows 上是 2，在 Linux/macOS 上通常是 4。这不是标准强制规定的，而是平台 ABI 决定的：Windows 用 UTF-16 编码，所以 wchar_t 设为 2 字节；glibc 默认用 UTF-32，所以设为 4 字节。这意味着你不能假设 wchar_t 是“统一的宽类型”——跨平台代码里直接用 sizeof(wchar_t) 做缓冲区计算很容易溢出或浪费空间。
L"" 字面量和普通字符串字面量不能混用
写 "hello" 得到的是 const char*，写 L"hello" 得到的是 const wchar_t*。这两者类型不兼容，强行转换（比如 (const wchar_t*)"hello"）不会做编码转换，只是把字节 reinterpret 一遍，结果是乱码。常见错误包括：
- 把
L"中文"传给只接受const char*的函数（如fopen），在 Windows 上可能意外成功（因为 ANSI 代码页碰巧能 decode），但在 Linux 上大概率失败 - 用
std::string接收L"abc"，编译不过：error: no viable conversion - 调用
wprintf(L"%s", "abc")—— 这里"abc"是窄字符串，但%s在宽流中实际期待wchar_t*，行为未定义
对应的标准库函数和流对象完全不同
没有“自动适配”的中间层。你选了 wchar_t，就得整套切换：
- 字符串容器要用
std::wstring，不是std::string - 输入输出用
std::wcout/std::wcin，不是std::cout/std::cin - 字符串操作函数是
wcscpy、wcslen、swprintf，不是strcpy、strlen、sprintf - 文件操作若涉及宽路径（如 Windows 的
L"C:\用户\张三"），必须用_wfopen或 C++17 的std::filesystem::path，而非fopen
漏掉任意一环，轻则编译失败，重则运行时崩溃或静默截断。
立即学习“C++免费学习笔记（深入）”；
Unicode 支持不等于“用了 wchar_t 就万事大吉”
wchar_t 只是存储单元，它本身不带编码语义。Windows 上 L'€' 是一个 wchar_t（U+20AC → 0x20AC），但在 UTF-16 中，这个码点刚好落在 BMP 区，没问题；而像 ?（U+1F30D）这种辅助平面字符，在 UTF-16 中需要两个 wchar_t（代理对），此时 wcslen(L"?") 返回 2，但逻辑字符数是 1。Linux 上用 UTF-32 则每个 Unicode 码点占一个 wchar_t，看似简单，但 wchar_t 占 4 字节也意味着内存开销翻倍。真正跨平台处理 Unicode，建议绕过 wchar_t，直接用 char8_t + UTF-8 编码（C++20 起）或成熟的库如 ICU、utf8cpp。
