最可靠方法是调用CheckTokenMembership检查当前进程令牌中Administrators组SID是否启用，而非查用户名或UAC状态；需用AllocateAndInitializeSid构造SID、传nullptr使用当前令牌、结果取输出参数、调用后FreeSid防泄漏。
Windows下用 CheckTokenMembership 判断是否为管理员
直接查进程令牌的组成员关系最可靠，比检查用户名或UAC虚拟化状态更准确。关键不是“当前用户是不是管理员”，而是“当前进程是否以管理员权限运行”——后者取决于令牌中的 Administrators 组SID是否被启用。
实操步骤：
- 调用
OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &hToken)获取当前进程令牌 - 用
AllocateAndInitializeSid构造BuiltinAdministratorsSid - 传给
CheckTokenMembership(NULL, sid, &isMember)；注意第一个参数为NULL表示使用当前进程令牌 - 别忘了
FreeSid和CloseHandle
常见错误：跳过 CheckTokenMembership 直接比对用户名（如硬编码 "Administrator"），在域环境或重命名账户时失效；或忽略令牌中该组SID的启用状态（Disabled 时返回 FALSE）。
Linux/macOS用 geteuid() 和 getegid() 判断实际有效UID/GID
Unix系不叫“管理员”，而看进程的有效用户/组ID是否为0。但要注意：getuid() 返回真实UID（启动时的用户），geteuid() 才是决定权限的实际ID——比如通过 sudo 或 setuid 程序提升后，geteuid() 是0，getuid() 可能仍是普通用户ID。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 只依赖
geteuid() == 0作为“有root权限”的判断依据 - 如果还需确认是否属于特定组（如
wheel或sudo），再调用getgrouplist()或解析/etc/group - 避免仅靠
getuid() == 0判断——它无法识别sudo ./a.out这类场景
性能无影响，但跨平台代码里容易混淆 uid 和 euid，导致误判。
跨平台封装时别碰 IsUserAnAdmin()
Windows的 IsUserAnAdmin() 是旧API，已废弃。它不检查当前令牌，而是查用户是否属于Administrators组——哪怕进程是以标准用户身份运行，只要该用户账号本身在组里，就返回 TRUE。这和“程序是否有特权”完全不是一回事。
替代方案：
- Windows坚持用
CheckTokenMembership（如前所述） - Linux/macOS 坚持用
geteuid() - 不要写宏如
#ifdef _WIN32 ... #else ... #endif把两种逻辑混在同一函数里——权限模型本质不同，强行统一抽象反而埋坑
很多跨平台库在这里翻车，表面封装了“is_admin()”，实际在Windows上返回的是账户能力而非运行态权限。
UAC虚化（Virtualization）会让 CheckTokenMembership 仍返回真，但文件操作失败
这是最容易被忽略的点：即使 CheckTokenMembership 确认你有管理员令牌，若程序未声明 requireAdministrator 清单，Windows可能启用文件/注册表虚拟化。此时你看似有权限，实际写入的是 %LOCALAPPDATA%\VirtualStore 而非 C:\Windows。
验证方法：
- 用
Process Explorer查看进程属性 → “Security”页签，确认“Integrity Level”是High（而非Medium） - 检查程序 manifest 是否含
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"/> - 虚拟化开启时，对受保护路径的写操作不会报错，但数据没去到预期位置
所以“有管理员令牌”不等于“能成功执行特权操作”——清单声明、完整性级别、虚拟化开关，三者必须同时满足。
