std::codecvt 因 C++17 弃用、C++20 移除且跨平台支持差（GCC/Clang 崩溃、MSVC 依赖系统 locale）而不可用；推荐 iconv（跨平台稳定）或 Windows 原生 API（MultiByteToWideChar + WideCharToMultiByte），禁用 wstring_convert 和自制查表法。
为什么 std::codecvt 在 C++17 被弃用还总被推荐？
因为它是标准库中唯一曾原生支持 UTF-8 ↔ GBK 转换的机制，但实际项目中基本不能用：std::codecvt_utf8_utf16 只处理 UTF-16，std::codecvt_byname("zh_CN.GB18030") 在 GCC/Clang 上常崩溃或返回空结果，MSVC 虽部分支持却要求系统 locale 已安装 GBK 区域设置（Linux/macOS 通常不满足）。更关键的是——C++17 明确标记其为 deprecated，C++20 彻底移除。别再试了。
用 iconv 是最稳的跨平台方案
Linux/macOS 自带，Windows 可通过 win-iconv 或 MSYS2 的 libiconv 支持。核心是三步：初始化、转换、清理。注意 iconv() 修改输入/输出指针，必须用临时变量保存原始地址。
常见错误现象：iconv() 返回 -1 且 errno == EILSEQ —— 输入含非法 UTF-8 字节序列；errno == EINVAL —— 输入未完整字符结尾（如截断的 UTF-8）；errno == E2BIG —— 输出缓冲区不够（需扩容重试）。
实操建议：
立即学习“C++免费学习笔记（深入）”；
-
iconv_open("GBK", "UTF-8")必须检查返回值是否为(iconv_t)(-1)，失败时直接 return - 输出缓冲大小建议按输入字节数 × 2 预估（GBK 单字符最多 2 字节，UTF-8 最多 4 字节，但中文通常 1:1 或 1:2）
- 转换后记得
iconv_close()，否则内存泄漏 - Windows 下若用 MinGW 编译，链接加
-liconv；VS 用户需额外配置头文件与 .lib
Windows 平台可直接用 MultiByteToWideChar + WideCharToMultiByte
绕过第三方依赖，纯 Win32 API。先 UTF-8 → UTF-16（用 CP_UTF8），再 UTF-16 → GBK（用 CP_ACP 或显式 936）。注意：CP_ACP 依赖系统默认 ANSI 代码页，中文 Windows 默认是 GBK（即 CP936），但非中文系统会出错，所以硬编码 936 更可靠。
关键细节：
-
MultiByteToWideChar(CP_UTF8, ...)第二个参数若传MB_ERR_INVALID_CHARS，遇到非法 UTF-8 会失败；不传则静默跳过（慎用） - 两次调用都需先传
NULL获取目标缓冲长度，再分配内存，避免栈溢出 - 返回的 GBK 字节数不含终止
\0，如需 C 字符串要手动补 - 该方法在 Wine 或非 Windows 环境完全不可用，勿写成跨平台假象
别碰 std::wstring_convert 和自制查表法
std::wstring_convert 依赖已废弃的 std::codecvt，GCC 7+ 编译直接报错；自制 UTF-8 解码 + GBK 编码查表看似可控，但 GBK 不是简单映射——它包含区位码、造字区、兼容 ASCII 等复杂规则，且微软 GBK（CP936）和国标 GB18030 子集有细微差异。已有成熟库，重复造轮子只会引入乱码、越界、安全漏洞。
真正要注意的其实是边界：输入是否以 BOM 开头（UTF-8 BOM 是可选的 \xEF\xBB\xBF，GBK 无 BOM）、是否含控制字符、是否混用半宽/全宽标点。这些不会在转换函数里报错，但会导致下游解析失败——得在转换前做清洗或转换后校验字节数与原始长度比。
