最可靠方式是Windows调用CheckTokenMembership检查进程令牌是否含Administrators组SID，Linux/macOS用geteuid()==0判断root权限；需注意UAC令牌分离和WSL权限隔离等平台差异。
Windows 下用 CheckTokenMembership 判断是否为管理员
Windows 没有“特权等级”这个统一概念，实际要看进程是否拥有 SeDebugPrivilege 或更关键的——是否属于 Administrators 组。直接查令牌成员资格最可靠：CheckTokenMembership 是微软推荐方式，比解析 SID 或检查 UAC 提权状态更准确。
- 必须先用
OpenProcessToken获取当前进程的访问令牌（参数用TOKEN_QUERY） - 调用
AllocateAndInitializeSid构造BuiltinAdministratorsSid，不能硬编码 SID 字符串 - 返回非零值表示是管理员；返回 0 不代表一定是普通用户——可能因权限不足无法查询，需配合
GetLastError()判断是否为ERROR_ACCESS_DENIED - 注意：即使程序以“管理员身份运行”，若用户账户控制（UAC）启用，其令牌仍是“过滤后”的，
CheckTokenMembership仍能正确识别
Linux/macOS 下用 geteuid() 和 getegid() 判断是否为 root
Unix-like 系统靠有效 UID/GID 决定特权：UID 0 = root，GID 0 = root 组。但仅看 UID 不够——有些服务以非 root 用户启动，但通过 setuid 获得临时特权，此时 getuid()（真实 UID）和 geteuid()（有效 UID）不同。
- 判断 root 权限应优先用
geteuid() == 0，而非getuid() == 0 - 若需确认是否属于 root 组，再加判
getegid() == 0；但多数场景只关心执行权限，geteuid()足够 - 不要依赖
/proc/self/status解析，它在容器或某些嵌入式系统中可能不可靠或缺失 - POSIX 兼容性没问题，
geteuid()在 macOS、glibc、musl 下行为一致
跨平台封装时别混淆“提权状态”和“权限能力”
很多人误以为“是管理员/root”就等于“能做任何事”，其实不是。比如 Windows 上管理员进程默认仍受 UAC 限制，对 %SystemRoot% 下某些路径写入仍会失败；Linux 上即使 UID=0，若被 seccomp 或 capabilities 限制（如 Docker 容器），mount 或 net_admin 依然不可用。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 检测结果只能说明“理论上具备高权限”，不能替代具体操作前的错误检查（如 open() 失败后查
errno == EACCES） - 避免在初始化阶段就缓存检测结果——Linux 下可能通过
sudo -u切换用户，Windows 下可能被父进程降权 - 若逻辑依赖特权（如监听低端口），建议把检测逻辑放在真正需要特权的操作前，而不是启动时一次性断言
常见误判：UAC 弹窗 ≠ 管理员权限
Windows 上常有人用 IsUserAnAdmin()，但它在 UAC 启用时几乎总返回 false——因为普通用户令牌里没有管理员组，只有提升后的令牌才有。而 IsUserAnAdmin() 查的是当前令牌，不是“能否提升”。
立即学习“C++免费学习笔记（深入）”；
-
IsUserAnAdmin()已被微软标记为不推荐，文档明确说它“不反映当前进程的实际权限” - 不要用
ShellExecute带"runas"参数是否成功反推权限——那只是启动新进程，和当前进程无关 - 如果必须兼容旧代码，至少加上注释：
// WARNING: IsUserAnAdmin() returns false even for elevated processes in UAC-aware apps
geteuid() 和 getuid() 的区别。真要跑通，这两处细节比选哪个 API 更关键。 
