最可靠方式是Linux/macOS用getpwuid(getuid())查pw_dir、Windows用SHGetKnownFolderPath(FOLDERID_Profile)；环境变量HOME/USERPROFILE易被篡改或缺失，不可靠。
Linux/macOS 下用 getpwuid 获取 Home 目录最可靠
直接读环境变量 HOME 看似简单，但不可靠：它可能被用户手动修改、在 setuid 程序中被清空，或在某些容器/沙箱环境中未设置。getpwuid(getuid()) 从系统密码数据库查当前 UID 对应的 pw_dir 字段，才是 POSIX 标准做法。
- 必须包含头文件：
#include <pwd.h>、#include <unistd.h> -
getpwuid()返回的是静态缓冲区指针，多线程下不安全；如需线程安全，改用getpwuid_r()并传入自己的缓冲区 - 返回值为
nullptr表示查找失败（例如 UID 不存在），务必检查 - 示例片段：
struct passwd *pw = getpwuid(getuid()); if (pw && pw->pw_dir) { std::string home(pw->pw_dir); }
Windows 下优先用 SHGetKnownFolderPath
别用 GetEnvironmentVariable("USERPROFILE") —— 它在某些登录场景（如服务账户、远程桌面会话）下可能为空或指向错误位置。SHGetKnownFolderPath 是 Windows 推荐的现代 API，能正确处理漫游配置、重定向等策略。
- 需要链接
shell32.lib - 必须定义
INITGUID或显式#include <initguid.h>才能使用FOLDERID_Profile - 返回的路径是宽字符（
wchar_t*），转std::string需用WideCharToMultiByte或 C++11 的std::wstring_convert（后者已弃用，建议用前者） - 失败时返回非
S_OK值，不能只判指针是否为空
跨平台封装要注意的三个坑
写一个统一接口时，最容易在边界上出错：
- 路径末尾是否带斜杠？
getpwuid和SHGetKnownFolderPath返回的都不含尾部/或\，后续拼接子路径时得自己加 - 编码问题：Linux/macOS 是 UTF-8，Windows 是 UTF-16；若路径含中文，直接转
std::string会乱码，必须做正确编码转换 - 权限问题：Home 目录本身可能不可读（比如被 chmod 000），获取路径成功 ≠ 能访问，后续
opendir或fopen仍需检查 errno
为什么 std::filesystem::home_directory() 不能直接用
C++17 的 std::filesystem::home_directory() 看起来完美，但它在实际工程中存在严重限制：
立即学习“C++免费学习笔记（深入）”；
- GCC 11 之前版本（包括常用 Ubuntu 20.04 默认的 GCC 9）该函数始终返回空路径 —— 因为 libstdc++ 未实现，只抛
std::filesystem::filesystem_error - MSVC 2019 16.10+ 才开始稳定支持，旧版同样 fallback 到环境变量，不可信
- Clang/libc++ 实现依赖底层 OS API，但部分嵌入式或精简系统（如 musl）缺乏对应支持，行为不确定
真正要落地，还是得自己封装 getpwuid + SHGetKnownFolderPath，并做好降级逻辑。
