windows 下用 isuseranadmin() 判断是否以管理员身份运行，linux/macos 下用 geteuid() == 0 判断是否为 root；二者均为各平台最直接、权威的运行时权限判定方式，不可混用或替代。
Windows 下用 IsUserAnAdmin() 判断管理员权限
Windows 没有“特权等级”这种抽象概念，只有“是否拥有管理员令牌”的明确判定。最直接、最可靠的方式是调用 IsUserAnAdmin() —— 它不查用户组、不解析 SID，只检查当前进程的访问令牌是否包含管理员 SID 且处于启用状态。
- 必须链接
shell32.lib（MSVC）或添加-lshell32（MinGW） - 该函数返回
TRUE仅当进程以管理员身份运行（UAC 提权后），而非“属于 Administrators 组但未提权” - 它不抛异常、不依赖 COM、不需 manifest 文件，适合快速判断
- 示例：
#include <shellapi.h> bool is_admin = IsUserAnAdmin() != FALSE;</shellapi.h>
Linux/macOS 下检查有效 UID 是否为 0
Unix-like 系统用有效用户 ID（EUID）决定权限边界。geteuid() 返回当前进程的有效 UID，值为 0 即代表 root 权限——这是唯一权威依据，getuid()（真实 UID）或 getgid() 都不能替代。
-
geteuid()是 POSIX 标准函数，头文件为<unistd.h></unistd.h> - 注意：即使程序由 root 启动后降权（如 drop privileges），
geteuid()仍反映当前实际权限 - 不要用
system("id -u")或读取/proc/self/status—— 开销大、不可靠、可能被容器环境屏蔽 - 示例：
#include <unistd.h> bool is_root = geteuid() == 0;</unistd.h>
跨平台封装时避免常见误判
写一个 is_privileged() 函数时，最容易错的是混用判断逻辑或忽略平台差异。
- Windows 上绝不能用
geteuid()（未定义）；Linux/macOS 上调用IsUserAnAdmin()会链接失败 - 不要检查用户是否在 “admin” 或 “wheel” 组——这只能说明“可能能提权”，不代表当前进程已拥有权限
- UAC 虚拟化（如文件/注册表重定向）会让非管理员进程看似能写系统路径，但实际权限仍是受限的，必须以运行时 EUID 或令牌状态为准
- 容器环境（如 Docker）中 UID=0 不等于宿主机 root，但对容器内进程而言，
geteuid()==0依然表示最高权限
为什么不用 CheckTokenMembership() 或 getgroups()
这些 API 表面更“精确”，实则引入不必要复杂性和误判风险。
-
CheckTokenMembership()需要先获取进程令牌、查找管理员 SID、再判断成员关系——步骤多、易出错，且 Windows 10+ 对某些虚拟账户处理不稳定 -
getgroups()在 Linux 上返回的是补充组列表，但管理员权限不由组决定，而由 EUID 决定；且某些发行版（如 Alpine）默认禁用 group DB 查询 - 所有绕过
geteuid()或IsUserAnAdmin()的方案，本质上都在模拟权限检查，而不是反映真实执行上下文
CreateProcessAsUser）；Linux 下 fork 后的子进程 EUID 不变，但 execve 可能重置——这些边界情况比判断本身更值得盯紧。**C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
