Windows下GBK↔UTF-8转换必须经UTF-16中转，用MultiByteToWideChar/WideCharToMultiByte并注意CP_ACP与CP_UTF8；Linux/macOS用iconv，注意编码名兼容性及双指针用法；禁用已弃用的std::codecvt；处理GBK含\0时须用显式长度而非strlen。
Windows 下用 MultiByteToWideChar 和 WideCharToMultiByte 转 GBK ↔ UTF-8
Windows API 是最稳妥的本地方案，不依赖第三方库，但必须走宽字符中转（wchar_t）。UTF-8 和 GBK 都是多字节编码，不能直接互转，中间必须经过 UTF-16（即 Windows 的 wchar_t 表示形式）。
常见错误现象：MultiByteToWideChar 返回 0 且 GetLastError() 是 123（ERROR_INVALID_NAME），通常是输入指针为空、长度传错，或源编码标识（CP_UTF8 / CP_ACP）写反了。
-
CP_ACP对应系统默认 ANSI 代码页，在简体中文 Windows 上就是 GBK；别硬写936，可读性差还容易误用 - 调用前务必检查返回值，失败时用
GetLastError()定位；尤其注意目标缓冲区大小——WideCharToMultiByte传0可先获取所需字节数，避免截断 - 输入字符串必须以
\0结尾，或显式传入正确长度（不含结束符）；否则可能读越界或提前截断
Linux/macOS 下用 iconv 处理 UTF-8 ↔ GBK 转换
iconv 是 POSIX 标准方案，跨平台兼容性好，但 C++ 中需手动管理句柄和内存。它不走宽字符，直接在字节流间转换，效率略高，但错误处理更“静默”——比如遇到非法序列，默认跳过，不报错。
使用场景：读取用户提交的 GBK 编码日志文件，转成 UTF-8 后交由 Qt 或 std::filesystem 处理。
立即学习“C++免费学习笔记（深入）”；
- 初始化用
iconv_open("UTF-8", "GBK")，注意参数顺序：目标编码在前，源编码在后；反了会得到乱码而非报错 -
iconv()的*inbuf和*outbuf是**双指针**，函数内部会移动它们；别传入栈变量地址再反复用，容易崩 - 某些旧版 glibc 对
"GBK"支持不稳定，可试"CP936"；macOS 的iconv不认"GBK"，必须用"CP936"
std::codecvt 已被弃用，别在新项目里用
C++11 引入的 std::codecvt_utf8 看起来很美，但实际几乎不可靠：VS 2015+ 默认禁用，Clang/GCC 早已标记为 deprecated，C++20 直接移除。试图用它转 GBK 更是徒劳——标准库根本不提供 codecvt_byname 对 GBK 的实现。
常见错误现象：编译通过，运行时 std::use_facet<:codecvt_utf8>>(loc)</:codecvt_utf8> 抛 std::runtime_error，提示 facet not supported。
- 即使在支持的旧编译器上，
std::codecvt对非 UTF 系列编码（如 GBK）无标准化支持，各实现行为不一致 - 不要为了“标准库原生”硬套，它不是设计来干这个的；真要标准方案，就用 C++23 的
<text_encoding></text_encoding>（尚未普及） - 已有老代码在用？尽快迁移到
iconv或平台 API，别等升级编译器时突然炸开
GBK 字符串含 \0 时，strlen 会误判长度
GBK 编码里，汉字常以两个字节表示，其中第二个字节可能是 0x00；而 strlen 遇到第一个 \0 就停，导致后续内容被截断。这不是转换逻辑的问题，而是后续处理时的低级但高频陷阱。
使用场景：从文件读入一段 GBK 编码的二进制数据，用 strlen 算长度后再传给 MultiByteToWideChar ——结果只转了半句话。
- 读文件后，别用
strlen，直接用std::vector<char>::size()</char>或fread返回的实际字节数 - 如果必须用 C 风格字符串，确保源数据本身不含
\0；否则统一改用带长度参数的接口（如MultiByteToWideChar(..., src, len, ...)） - 调试时用十六进制查看器确认真实字节流，比看终端输出更可靠——终端自己也会做编码猜测
真正麻烦的从来不是“怎么转”，而是转完之后没人检查中间是否混入了替换字符（）、是否因长度误判丢字节、或者把 CP936 当成 UTF-8 去解析。这些点不卡在文档里，只卡在你跑通第一行日志之前。
