Windows下UTF-8↔GBK转换必须经UTF-16中间层，用CP_UTF8和代码页936（非CP_ACP）；Linux/macOS用iconv时优先试CP936，需处理非法序列与缓冲区管理，跨平台应显式传编码参数而非依赖系统locale。
Windows下用MultiByteToWideChar和WideCharToMultiByte做UTF-8 ↔ GBK转换
Windows API 是最稳定、无需第三方依赖的方案，但必须走 Unicode 中间层（UTF-16），不能直接 UTF-8 ↔ GBK。常见错误是传错CP_UTF8或CP_ACP——后者在中文系统默认是 GBK，但不等于“GBK 编码”，它受系统区域设置影响，严格应改用936（GBK 的代码页编号）。
实操要点：
-
MultiByteToWideChar(CP_UTF8, 0, utf8_str, -1, nullptr, 0)先算出所需宽字符数，再分配wchar_t缓冲区 - 第二步调用
WideCharToMultiByte(936, 0, wstr, -1, nullptr, 0, nullptr, nullptr)转 GBK；注意936比CP_ACP更可靠 - 若输入含非法 UTF-8 字节序列（如
\xc0\x80），MultiByteToWideChar返回 0，需检查GetLastError()是否为ERROR_NO_UNICODE_TRANSLATION - 输出缓冲区长度必须包含结尾
\0，否则WideCharToMultiByte可能截断
Linux/macOS 下用iconv库处理 UTF-8 ↔ GBK
iconv是 POSIX 标准接口，但 GNU libc 和 macOS 的libiconv行为略有差异：macOS 默认不支持GBK别名，得用CP936或GB2312（后者不支持扩展汉字，慎用）。
关键步骤：
立即学习“C++免费学习笔记（深入）”；
- 调用
iconv_open("GBK", "UTF-8")前，先试iconv_open("CP936", "UTF-8")——在 macOS 上更稳妥 -
iconv()函数会修改inbuf和outbuf指针，必须用局部变量保存原始地址，否则无法计算实际写入字节数 - 转换失败时
iconv()返回(size_t)-1，且errno可能是EILSEQ（非法序列）或EINVAL（不完整字符），需分别处理 - 务必调用
iconv_close()释放资源，多次复用同一iconv_t句柄比反复open/close快
跨平台项目中避免硬编码代码页
直接写936或"GBK"会让代码在非中文环境失效。比如某 Linux 服务器 locale 是en_US.UTF-8，但业务数据仍是 GBK 编码，此时依赖setlocale(LC_ALL, "")获取当前编码毫无意义。
更健壮的做法：
- 明确区分「源编码」和「目标编码」，作为函数参数传入，而不是从系统推断
- 对 Windows，封装一层判断：
if (is_windows) use_cp936_else_cp1252，但CP1252和 GBK 完全无关，别混淆 - 若用 C++20
std::text_encoding（尚未广泛实现），目前只能观望；别依赖std::codecvt_utf8_utf16，它已被弃用且不支持 GBK - 测试时必须覆盖边界情况：纯 ASCII、带 emoji 的 UTF-8、GBK 中的“〇”（U+3007）、以及乱码字节如
\xff\xff
性能敏感场景下减少内存拷贝
高频转换（如日志解析、网络包解码）中，两次中间转换（UTF-8 → UTF-16 → GBK）或iconv内部缓冲导致额外拷贝，容易成为瓶颈。
可优化点：
- Windows 下预分配足够大的
wchar_t缓冲区（按 UTF-8 字节数 × 2 估算），避免重复调用获取长度 -
iconv使用ICONV_SET_TRANSLITERATE标志能将无法映射字符转成?，比默认失败返回更快，但会丢失信息 - 不要为每次转换都 new/delete 缓冲区；用对象池或栈数组（
wchar_t buf[4096]）更高效 - GB2312 是 GBK 的子集，若确定输入不含 GBK 扩展区（如“镕”“珮”），可用
GB2312代替GBK提升iconv查找速度
