Windows下最可靠方式是GetUserNameEx配合NameSamCompatible格式，Linux/macOS应优先用getpwuid(getuid())并检查返回指针有效性，均需处理缓冲区大小与错误码，避免依赖环境变量。
Windows 下用 GetUserNameEx 获取登录用户名最可靠
直接调用 GetUserNameEx 是 Windows 平台最稳妥的方式，它能正确返回域用户（如 DOMAIN\user）或本地用户（如 DESKTOP-ABC\user），避免 GetUserName 只返回短用户名、丢失上下文的问题。
需要包含头文件：#include <windows.h></windows.h> 和 #include <lmcons.h></lmcons.h>；链接 Advapi32.lib（MSVC 默认链接，MinGW 需加 -ladvapi32）。
- 推荐使用
NameSamCompatible格式（值为 2），输出形如DOMAIN\user，兼容性好，权限检查逻辑清晰 - 缓冲区必须足够大：建议至少
UNLEN + DNLEN + 2字节（UNLEN=256,DNLEN=15），但实际分配 512 字节更安全 - 必须检查返回值：返回
FALSE时调用GetLastError()判断是否是ERROR_BUFFER_OVERFLOW，否则可能是权限或策略限制（如某些服务账户无法获取）
Linux/macOS 下用 getpwuid + getuid 是标准做法
getpwuid(getuid()) 组合是 POSIX 兼容的通用方案，它读取当前真实用户 ID 对应的 /etc/passwd 条目，返回 struct passwd* 中的 pw_name 字段。
注意这不是“登录会话名”，而是 UID 映射的用户名——对绝大多数交互式终端和 SSH 登录场景，这和用户预期一致；但对 sudo、容器或 root 启动的进程，它返回的是实际 UID 的用户名，不是原始登录者。
立即学习“C++免费学习笔记（深入）”；
- 必须检查指针是否为
nullptr：getpwuid失败时返回空指针（例如 UID 不存在或 NSS 模块异常） - 不要直接用
getlogin()：它依赖终端控制链，SSH 连接断开、重定向或 systemd 服务中常返回nullptr或错误值 - 结果内存由 libc 管理，不应
free；如需长期持有，应strdup拷贝pw_name
跨平台封装要注意环境差异和 fallback 逻辑
没有一行代码通吃所有系统。简单封装时，优先走原生 API，失败后再尝试降级路径（比如 Windows 下 GetUserNameEx 失败，可试 GetUserName；Linux 下 getpwuid 失败，再查 LOGNAME 环境变量）。
但环境变量不可信：LOGNAME 和 USER 可被任意修改，USERNAME 在 Windows 命令行里可能被覆盖，仅作最后手段。
- Windows 上不推荐解析
USERDOMAIN+USERNAME拼接，因为组策略可能禁用USERNAME导出，且无法反映当前登录会话的实际身份上下文 - macOS 注意：
getpwuid在启用了 Directory Services（如绑定 AD）时仍有效，但若用户未缓存，首次调用可能延迟明显 - 所有路径都要考虑线程安全：
getpwuid在部分旧 libc 中是非重入的，应改用getpwuid_r（需提供缓冲区）
常见错误：把进程所有者当成登录用户
很多代码误用 geteuid 或检查 /proc/self/status（Linux）里的 Uid: 行，这拿到的是有效 UID，不是登录会话所属用户。例如 sudo -u otheruser ./a.out 中，geteuid 是 otheruser，但登录用户仍是执行 sudo 的那个人。
真正需要“谁在键盘前”的场景（审计、日志归属、UI 显示），必须依赖系统级会话信息：Windows 的 WTSQuerySessionInformation（配合 WTS_CURRENT_SESSION）或 Linux 的 logind D-Bus 接口（org.freedesktop.login1），但这已超出纯 C++ 标准库能力，需额外集成。
多数应用其实只需要“当前有效用户身份”，这时候 getpwuid(getuid()) 或 GetUserNameEx 就够用——但得清楚自己究竟要解决什么问题，而不是只看函数能不能跑通。
