必须在打开UTF-16LE文件前对std::wifstream调用imbue()并设置支持UTF-16的locale，否则默认按本地多字节编码解析会导致乱码；同时wcout需用相同locale并配合SetConsoleOutputCP或转UTF-8输出。
用 std::wifstream 读 UTF-16LE 文件前必须 imbue()
不设 locale，std::wifstream 默认按本地多字节编码（如 GBK 或 Latin-1）解析字节，哪怕文件是 UTF-16LE，也会把每个 2 字节当一个 wchar_t 生硬拆开——结果是满屏乱码或截断。Windows 上 wchar_t 是 2 字节，恰好和 UTF-16LE 单个码元对齐，但 C++ 标准库不自动识别 BOM，也不默认按 UTF-16 解码。
实操建议：
- 必须在打开文件前调用
imbue()，且 locale 需含 UTF-16 编码支持 - 推荐用
std::locale(std::locale(), new std::codecvt_utf16<wchar_t std::little_endian>)</wchar_t>（C++11/14） - 注意：
std::codecvt_utf16在 C++17 被标记为 deprecated，但目前仍是 Windows 下最稳的方案；GCC/libstdc++ 对它的支持较弱，Clang/libc++ 更可靠 - 文件开头若有 BOM（
0xFF 0xFE），codecvt_utf16会跳过它；没 BOM 也能读，但必须确保字节序一致
为什么不能只靠 open("file.txt", std::ios::binary) + 手动转码
二进制模式读出 raw bytes 后再用 std::wstring_convert 或手写转换，看似可控，实际容易踩三个坑：
- BOM 处理易出错：UTF-16LE 的 BOM 是
0xFF 0xFE，但若文件末尾有填充字节、或跨平台传输时换行符混入，手动切分wchar_t边界极易偏移 -
std::wstring_convert在 C++17 被移除，且其底层依赖std::codecvt，与imbue()方案本质重复，还多一层对象管理开销 - Windows 控制台默认不支持直接输出 UTF-16
wstring—— 即使读对了，wcout不设 locale 仍会乱码，形成“读对了却看不见”的假失败
wcout 输出 UTF-16 std::wstring 前要同步 imbue
输入输出流 locale 必须匹配，否则 wifstream 读出的 wstring 到 wcout 会二次解码失败。Windows 控制台默认代码页是 936（GBK）或 437，不认 UTF-16。
立即学习“C++免费学习笔记（深入）”；
- 务必对
std::wcout单独imbue()，且用和输入流**相同**的 locale 实例 - 还需调用
SetConsoleOutputCP(CP_UTF8)（Windows API），否则控制台底层不接受 UTF-8/UTF-16 输出 - 更稳妥做法：读完后用
WideCharToMultiByte(CP_UTF8, ...)转成std::string，再用普通cout输出 —— 避开wcout的 locale 状态污染问题
C++20 std::filesystem 和 UTF-16 路径名无关
别被名字误导：std::filesystem::path 构造函数接受 std::wstring，但它只是把宽字符序列原样存下来，并不触发任何编码转换。Windows API 内部用 UTF-16，所以传 wstring 能正确调用 CreateFileW；但文件内容编码仍是另一回事。
-
std::filesystem::path(L"中文.txt")没问题，但用它打开的std::wifstream仍需imbue()才能正确读内容 - 路径含 Unicode 只解决“找得到文件”，不解决“读得懂内容”
- 如果路径本身来自用户输入（比如命令行参数），Windows 下
GetCommandLineW()或wmain()入口才能拿到真正的 UTF-16 路径 ——argv是窄字符串，已损毁
wcout 的 locale 同步——这三处不显眼，但任一遗漏都会让整个流程静默失败。 
