Windows下UTF-8转GBK必须经UTF-16中转：先用MultiByteToWideChar(CP_UTF8)转为wchar_t，再用WideCharToMultiByte(936)转为GBK字节流，两步均需检查返回值并用GetLastError()定位错误。
Windows 下用 MultiByteToWideChar + WideCharToMultiByte 转 UTF-8 到 GBK 是最稳的路径
直接调用系统 API 比依赖第三方库更可控，尤其在无 C++20 或未启用 std::text_encoding 的项目里。关键不是“能不能转”，而是“中间宽字符用什么编码”——必须用 UTF-16（WCHAR），不能跳过这一步。
常见错误是把 UTF-8 字节流当 ANSI 直接喂给 WideCharToMultiByte(CP_ACP, ...)，结果仍是乱码。GBK 是 Windows 的 CP936，不是 CP_ACP（后者随系统区域设置漂移）。
-
MultiByteToWideChar(CP_UTF8, ...)把 UTF-8 转成wchar_t[]（UTF-16LE） -
WideCharToMultiByte(936, ...)把wchar_t[]转成 GBK 字节流（char[]） - 两步都需检查返回值：0 表示失败，
GetLastError()可查具体原因（如输入含非法 UTF-8 序列）
Linux/macOS 下没有原生 GBK 支持，得靠 iconv
POSIX 系统不提供类似 Windows 的代码页概念，iconv 是事实标准。但注意：iconv 的编码名是 GBK，不是 CP936 或 GB2312（后者不兼容 GBK 全字符集）。
容易踩的坑是忘记初始化 iconv_t 句柄或重复使用已关闭的句柄，导致段错误。转换失败时 iconv() 返回 (size_t)-1，且 errno 会被设为 E2BIG（输出缓冲区不够）、EILSEQ（输入非法）等。
立即学习“C++免费学习笔记（深入）”；
- 调用
iconv_open("GBK", "UTF-8")获取转换器，成功后必须配对iconv_close() - 输出缓冲区大小要预留余量（GBK 单字最多 2 字节，UTF-8 单字符最多 4 字节，但实际长度非线性）
- 若需零拷贝或流式转换，别一次性传整个字符串，改用循环处理并检查
inbytesleft/outbytesleft
std::wstring_convert 已被 C++17 废弃，别再用
很多老教程还在教用 std::wstring_convert<:codecvt_utf8>></:codecvt_utf8> 中转，但该方案在 GCC 7+、Clang 5+ 编译会报错，MSVC 也标记为 deprecated。根本原因是 std::codecvt 系列模板无法正确处理 UTF-16 surrogate pairs 和部分 GBK 扩展区字符，且线程不安全。
替代思路只有两个：Windows 用上述 WinAPI，跨平台项目引入轻量级库（如 utf8cpp 配合 iconv 封装），或者升级到 C++20 并确认编译器支持 std::text_encoding（目前仅 MSVC 2022 17.5+ 有实验性实现，GCC/Clang 尚未跟进）。
- 用
std::wstring_convert在 VS2019 编译可能通过，但运行时遇到「?」这类 Unicode 辅助平面字符会静默截断 - CMake 中检测 C++ 标准时，别只写
set(CMAKE_CXX_STANDARD 17)，要加set(CMAKE_CXX_STANDARD_REQUIRED ON)防降级
GBK 输出到文件或控制台前，必须确认目标环境支持
乱码常发生在“转对了但显示错了”。例如 Linux 终端默认 UTF-8，直接写入 GBK 字节会显示为 ；Windows 控制台默认活动代码页是 936，但若用户改过 chcp 65001，GBK 字符就无法渲染。
文件场景更隐蔽：用 Notepad 打开 GBK 文件，若未勾选“以 GBK 编码打开”，会当成 UTF-8 解析，首字节 0xC4 被误读为 UTF-8 多字节起始，后续全乱。VS Code 默认按 BOM 判断编码，但 GBK 文件无 BOM，需手动点击右下角编码选择并“Save with Encoding”。
- 写文件时，可在开头写入 GBK 的伪 BOM（
0xFF 0xFE是 UTF-16LE BOM，GBK 不适用；GBK 无标准 BOM，别硬加） - 调试时用
xxd或hexdump -C直接看二进制，比肉眼读字符串更可靠 - 终端输出前，先用
setlocale(LC_ALL, "")同步系统区域设置，但注意这影响全局，多线程下慎用
真正麻烦的从来不是转换函数怎么写，而是你得同时盯住三处：输入字节是否合法 UTF-8、目标环境是否真能渲染 GBK、中间宽字符是否被截断或符号扩展。少验一处，乱码就藏在看似成功的日志里。
