最可靠方式是按平台分治：windows 用 getuserdefaultlocalename 获取 "zh-cn"，posix 系统按 lc_all→lc_messages→lang 顺序读取并标准化为 bcp 47 标签，均需 fallback 且不可依赖 std::locale("")。
Windows 上用 GetUserDefaultLocaleName 最可靠
Windows 不认 POSIX 的 setlocale(LC_ALL, "") 返回值，它常固定返回 "C"，哪怕系统设的是简体中文。真正反映用户区域偏好的是 WinAPI 的 GetUserDefaultLocaleName，它返回形如 "zh-CN" 的 BCP 47 标签。
实操建议：
- 包含
<windows.h></windows.h>和<string></string> - 用
wchar_t buffer[LOCALE_NAME_MAX_LENGTH]接收，调用后转成 UTF-8std::string（别直接 reinterpret_cast） - 失败时回退到
GetThreadLocale()或环境变量LANG（但 Windows 下通常为空） - 注意：
GetUserDefaultLocaleName是 Vista+ 才有，XP 需用GetSystemDefaultLangID+ 映射表
Linux/macOS 优先读 LC_ALL、LC_MESSAGES、LANG 环境变量
POSIX 系统不提供统一 API 获取“用户首选语言”，setlocale(LC_MESSAGES, "") 只影响 C 运行时行为，不保证返回真实设置。实际应按优先级检查环境变量。
常见错误现象：setlocale(LC_ALL, "") 返回 "en_US.UTF-8"，但用户在 GNOME 设置里选的是中文——因为桌面环境可能只改了 LC_MESSAGES，而没动 LC_ALL。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 按顺序查
getenv("LC_ALL")→getenv("LC_MESSAGES")→getenv("LANG") - 值形如
"zh_CN.UTF-8"或"ja_JP"，需提取前缀（zh_CN→"zh-CN"）用于后续匹配 - 不要依赖
nl_langinfo(CODESET)判断语言，它只返回编码，不是语言标识 - macOS 的
LANG可能是"en_US"（无 .UTF-8），要兼容无编码后缀的情况
std::locale("") 在各平台表现不一致，慎用
写 std::locale("") 看似跨平台，实际行为割裂：Linux/macOS 下通常解析环境变量，Windows 下却常 fallback 到 "C" locale，且无法提取语言标签（name() 返回 "C" 或空字符串）。
性能与兼容性影响：
- 构造
std::locale有开销，尤其在频繁调用场景（如日志模块初始化） - 无法从
std::locale安全反推出zh-CN这类 IETF 语言标签，name()返回格式无标准保证 - 某些嵌入式 libc（如 musl）对空字符串构造支持不全，可能抛
std::runtime_error
推荐封装一个轻量函数，按平台分治
硬塞进一个跨平台接口反而容易出错。不如用预处理器分发，保持逻辑清晰。
示例骨架：
#ifdef _WIN32
std::string get_system_locale() {
wchar_t buf[LOCALE_NAME_MAX_LENGTH];
if (GetUserDefaultLocaleName(buf, LOCALE_NAME_MAX_LENGTH)) {
return utf16_to_utf8(buf); // 自行实现或用 WideCharToMultiByte
}
return "en-US";
}
#elif defined(__linux__) || defined(__APPLE__)
std::string get_system_locale() {
for (const char* var : {"LC_ALL", "LC_MESSAGES", "LANG"}) {
if (const char* val = getenv(var)) {
return normalize_locale_name(val); // 如 "zh_CN.UTF-8" → "zh-CN"
}
}
return "en-US";
}
#endif
关键点在于：不试图抽象掉平台差异，而是把差异控制在最小范围；normalize_locale_name 要处理下划线/横线、大小写、编码后缀；所有路径都必须有明确 fallback，不能假设环境变量一定存在。
最容易被忽略的是：iOS 和 Android NDK 不走标准 POSIX 环境变量路径，前者要用 NSLocale Objective-C API，后者得通过 JNI 调 java.util.Locale.getDefault()——如果你的代码要跑在这两个平台，上面的 __linux__ 分支根本不会触发。
