C++17中std::wstring_convert和std::codecvt_utf8_utf16已被弃用，因可移植性差且代理对处理不一致，推荐手动实现UTF-16解码或使用utf8cpp等轻量库。
std::wstring_convert + std::codecvt_utf8_utf16 在 C++17 中已被弃用
别再用 std::wstring_convert 和 std::codecvt_utf8_utf16 —— 它们在 C++17 标准里被标记为 deprecated，GCC/Clang 新版本默认编译会报 warning，MSVC 也逐步收紧支持。强行用不仅代码可移植性差，还可能在不同平台行为不一致（比如对 surrogate pair 处理不一致）。
实际项目中更可靠的做法是：自己处理 UTF-16 解码逻辑，或引入轻量级第三方库（如 utf8cpp 或 iconv）。下面聚焦「手动实现」这一可控、无依赖的路径。
手动转换需先区分 UTF-16 编码单元是单个 char16_t 还是代理对（surrogate pair）
UTF-16 并非每个 char16_t 都对应一个 Unicode 码点：U+0000–U+D7FF 和 U+E000–U+FFFF 直接映射；而 U+10000–U+10FFFF 则用两个 char16_t 表示（高位代理 + 低位代理），即 surrogate pair。漏判代理对会导致乱码或越界读取。
- 高位代理范围：
0xD800≤ high ≤0xDBFF - 低位代理范围：
0xDC00≤ low ≤0xDFFF - 遇到
0xD800–0xDFFF之外的值，直接按 BMP 码点处理
示例片段（仅示意逻辑，不含边界检查）：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
uint32_t codepoint;
if (ch >= 0xD800 && ch <= 0xDFFF) {
// 是代理对开头，需读下一个 char16_t
auto next = *(++it);
codepoint = 0x10000 + ((ch & 0x3FF) << 10) + (next & 0x3FF);
} else {
codepoint = ch;
}
UTF-8 编码规则决定字节数和掩码模式
从 Unicode 码点生成 UTF-8 字节序列时，字节数由码点大小决定，不能硬编码 3 字节或 4 字节：
- U+0000–U+007F → 1 字节：
0xxxxxxx - U+0080–U+07FF → 2 字节：
110xxxxx 10xxxxxx - U+0800–U+FFFF → 3 字节：
1110xxxx 10xxxxxx 10xxxxxx - U+10000–U+10FFFF → 4 字节：
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
注意：C++ 标准库没有内置 UTF-8 编码函数，std::to_string 或 std::ostringstream 对 char16_t 不起作用；必须逐位移位 + 按位与构造字节。
实际转换中容易忽略 BOM 和字节序（endianness）
Windows API 返回的 std::u16string 通常是小端序（LE），但文件或网络协议可能带 UTF-16 BOM（0xFEFF）或大端序（BE）。如果输入含 BOM，得先跳过；若输入是 BE 数据，需对每个 char16_t 做 htons() 或手动字节交换。
- 检测 BOM：
if (str.size() >= 1 && str[0] == 0xFEFF)（LE BOM）或str[0] == 0xFFFE（BE BOM） - BE 转 LE：
auto le = (ch & 0xFF) > 8) - 多数现代系统（x86/x64）默认小端，但跨平台读文件时仍需校验
没处理 BOM 或字节序错配，会导致第一个字符变成  或彻底乱码，且后续所有解码偏移全错。
