最可靠方式是Windows调用CheckTokenMembership检查进程令牌是否含Administrators组SID，Linux/macOS用geteuid()==0判断root权限；需注意UAC令牌分离和WSL权限隔离等平台差异。
Windows下用CheckTokenMembership判断是否以管理员身份运行
直接调用CheckTokenMembership是最可靠的方式，它能准确识别当前进程是否拥有SE_PRIVILEGE_ENABLED状态的SeDebugPrivilege或更关键的Administrators组成员资格。别信IsUserAnAdmin()——它在UAC启用时可能返回假阳性（比如标准用户提权后运行的进程仍被误判为admin）。
实操要点：
- 必须先用
OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &hToken)获取当前进程令牌 - 调用
LookupAccountName(NULL, L"Administrators", ...)拿到本地管理员组的SID，不能硬编码 -
CheckTokenMembership(hToken, AdministratorsSid, &bIsAdmin)返回非零才表示真正具备管理员特权 - 记得
FreeSid(AdministratorsSid)和CloseHandle(hToken)，否则泄漏句柄
Linux/macOS用geteuid()和getegid()判断有效UID/GID
Unix-like系统不叫“管理员”，而是看有效用户/组ID是否为0。但注意：getuid()返回真实UID（启动时的），geteuid()才是当前权限上下文的关键——setuid程序靠它降权或提权。
常见误区：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 只查
geteuid() == 0不够：某些场景（如sudo执行）可能geteuid() == 0但getegid() != 0，需同时检查getegid() - 不要依赖
/etc/sudoers或groups命令输出——它们反映的是登录会话，不是当前进程的实际权限 - 容器环境（如Docker）中
geteuid()可能为0，但实际被cgroup限制，此时需额外检查/proc/self/status里的CapEff:字段
跨平台封装时避免std::system("whoami /groups")这类陷阱
调用shell命令看似简单，但问题一堆：Windows上whoami /groups输出格式随语言版本变化；Linux上id -Gn可能因locale导致中文分组名乱码；所有方案都受PATH、权限、子进程阻塞影响。
真正稳健的做法：
- Windows走WinAPI路径（前两节所述）
- Unix走
geteuid()/getegid()+getgrouplist()查是否在wheel/admin组 - 若必须跨平台抽象，定义统一返回枚举：
PrivilegeLevel::User、PrivilegeLevel::Elevated、PrivilegeLevel::Unknown，绝不返回布尔值 - 缓存结果——权限不会在进程生命周期内动态变更，查一次就够了
调试时遇到ERROR_ACCESS_DENIED或EPERM别急着改权限
很多开发者看到权限错误第一反应是“提权重跑”，但真正原因常是：令牌被继承自父进程（如IDE启动的调试器）、服务进程未配置AllowServiceLogon、或Linux上文件caps（getcap ./myapp）覆盖了UID判断。
排查顺序建议：
- Windows：用
Process Explorer右键进程→Properties→Security→Permissions，看Effective Access里是否有Full Control - Linux：运行
cat /proc/self/status | grep -E '^(Uid|Gid|CapEff)'，比id命令更准 - 确认目标操作是否真需要特权——比如读取
/proc/[pid]/mem要ptrace能力，而非root本身
真正的难点不在检测逻辑，而在理解“特权”是分层的：Windows有完整性级别（Medium vs High），Linux有capabilities和ambient set，单纯区分User/Admin掩盖了大量细节。
