whoami 返回的是当前进程的有效用户id（euid）对应用户名，而非登录用户；权限检查只认euid/egid，故显示root却无/root访问权是因euid为0但实际未获完整root上下文。
whoami 为什么有时返回 root，但实际不是 root？
因为 whoami 只读取当前进程的有效用户 ID（EUID），不关心你是不是用 sudo 临时提权、或者从 root 切换过来的。比如你执行了 sudo su -，再运行 whoami，它就返回 root——哪怕你原本是普通用户。
常见错误现象：whoami 显示 root，但 ls /root 报 Permission denied；或者写脚本时误以为“是 root 就能删系统文件”，结果权限校验失败。
- 真正想确认“登录时用的谁”，该用
logname（它读取 utmp，更贴近登录身份） - 想查“当前 shell 进程的真正发起者”，用
id -un $PPID（查父进程 UID 对应用户名） -
whoami适合快速判断 EUID，比如在部署脚本开头加[ $(whoami) != "root" ] && echo "请用 root 运行" && exit 1，但要注意这仅校验 EUID，不是登录身份
id 命令输出里 uid/gid/euid/egid 到底哪个管权限？
Linux 权限检查只看 **EUID（有效用户 ID）和 EGID（有效组 ID）**，不是 UID/GID。也就是说，id 输出中带 e 的那两行才决定你能不能读文件、杀进程、绑定端口。
使用场景：调试权限问题时，别光扫一眼 uid=1000(john) 就以为“我是 john”，得重点看 euid=0(root) —— 这才是你此刻的真实权限身份。
-
id -u返回 UID（真实用户 ID），id -ru才返回 EUID -
id -G列出所有附加组（含主组），id -g是 GID，id -rg是 EGID - 普通用户执行
sudo ls时，EUID=0，但 UID 仍是 1000；某些安全敏感程序（如sshd）会主动降权，把 EUID 改回 UID，这时id -ru和id -u就一致了
脚本里该用 whoami 还是 id -un？
取决于你要什么：“当前有效身份”还是“原始登录名”。90% 的运维脚本其实想要后者——比如日志打标、家目录路径拼接、配置文件属主判断。
容易踩的坑：whoami 在容器或 systemd 服务里可能返回 nobody 或空，因为没设置 LOGNAME 环境变量；而 id -un 更稳定，只要 UID 存在就能查到对应用户名（除非 /etc/passwd 被删）。
- 要兼容性高、不依赖环境变量 → 用
id -un - 要严格匹配当前 EUID 用户名（比如 sudo 后立刻验证权限）→ 用
whoami - 避免用
$USER环境变量，它可能被手动改写，不可信 - 示例：生成临时文件路径
/tmp/$(id -un)-report.txt比/tmp/$USER-report.txt更可靠
非交互式环境（cron、systemd）下身份识别失效怎么办？
crond 默认不加载用户 shell 环境，whoami 可能报错或返回 root；systemd 服务若没设 User=，默认以 root 启动，但 id -un 仍可能因 /etc/passwd 缺失条目而失败。
根本原因不是命令本身问题，而是这些环境里缺少完整的登录上下文（utmp 记录、HOME、SHELL 等）。这时候硬靠 whoami 或 id 都不准。
- 在 cron 中明确指定用户：用
sudo -u john whoami或直接写USER=john在 crontab 头部 - systemd 服务必须显式声明
User=john，否则id -un返回root是正常行为 - 容器内优先读
/proc/1/environ或检查getent passwd $(id -u)是否有输出，比依赖命令更底层可靠
最麻烦的情况是：你在一个没有 /etc/passwd 的精简镜像里跑脚本，id -un 会失败，whoami 直接报 command not found。这时候只能退回到 echo $UID + 手动映射，或者干脆放弃用户名，用 UID 做逻辑分支。
