应使用 geteuid() == 0 判断，因其反映进程当前实际权限；getuid() 仅表示启动用户，setuid 程序中二者可能不同，误用会导致权限误判。
Linux/macOS 下，C++ 程序不能直接“检查是否是 root 用户”，而应检查是否拥有目标操作所需的权限——最常用、最可靠的判断依据是 geteuid() 是否为 0。
为什么用 geteuid() 而不是 getuid()
真实用户 ID（getuid()）反映的是启动进程的用户，而有效用户 ID（geteuid()）决定当前进程实际拥有的权限。当程序被 setuid（如 sudo 或 chown root:root xxx; chmod u+s xxx）后，geteuid() 会变成 0，但 getuid() 仍是普通用户 ID。权限检查必须基于 geteuid()，否则会误判。
-
sudo ./myapp→geteuid() == 0，可执行特权操作 -
./myapp普通运行 →geteuid() == getuid() != 0 - 即使二进制文件属主是 root 但没设
setuid，geteuid()仍为非零
如何在 C++ 中安全调用并判断
需要包含 <unistd.h></unistd.h> 和 <sys></sys>；注意：Windows 不支持这些接口，该方案仅适用于 POSIX 系统。
- 不要依赖
getenv("USER")或解析/proc/self/status—— 可被伪造或不可靠 - 避免硬编码字符串比较（如
"root"），因为用户名可被修改，UID 0 才是 root 的本质标识 - 示例代码片段：
#include <unistd.h>
#include <sys>
bool is_root() {
return geteuid() == 0;
}
</sys></unistd.h>
返回 true 即表示当前进程拥有 root 级权限（能通过内核权限检查），不保证是交互式 root 用户，但足够支撑大多数特权操作判断。
常见误判场景和兼容性提醒
某些容器环境（如 Docker 默认非特权容器）或被 seccomp/SELinux 限制时，即使 geteuid() == 0，具体系统调用仍可能被拒绝——权限检查只是第一道门，不是万能通行证。
- macOS 上
geteuid()行为与 Linux 一致，但部分系统调用（如绑定低端口）还需额外 entitlements 配置 - 使用
cap_net_bind_service能力替代全量 root 时，geteuid()仍为非零，但可绑定 1–1023 端口——此时应改用capget()检查能力，而非 UID - 在 systemd user session 或 flatpak/snap 沙箱中，
/proc可能被挂载受限，geteuid()仍是唯一可信入口
真正关键的不是“是不是 root”，而是“能不能做某件事”；geteuid() == 0 是最轻量、最广泛兼容的代理指标，但任何涉及敏感资源的操作，都应在实际调用前捕获 EPERM 并降级处理——毕竟权限模型本身就在演进，硬编码信任比检查更危险。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
