groups 用户名命令普通用户只能查自己，查他人需读取/etc/passwd和/etc/group权限；输出反映当前会话组缓存，非实时，刚加组需重新登录才生效；id -Gn 用户名更可靠，强制重读配置。
直接运行 groups 用户名 查指定用户所属组
普通用户能查自己，但查别人需要读取 /etc/passwd 和 /etc/group 的权限——通常得是 root 或在 shadow 组里。执行 groups alice 后若报 groups: cannot find name for group ID 或无输出，大概率是权限不够，不是用户不存在。
注意：groups 用户名 读的是进程缓存的组信息，不是实时生效状态。比如刚用 usermod -aG docker alice 加了组，立刻跑这个命令，仍可能不显示 docker——因为 alice 当前所有 shell 还没重载凭证。
- 只对已登录用户有效；如果 alice 此刻没任何活跃会话，结果反映的是上次登录时的组快照
- 图形界面用户常误以为“重启终端”就够了，其实得完全登出桌面环境再登录
- 输出格式是
alice : group1 group2 group3，冒号前是用户名，后面空格分隔组名
id -Gn 用户名 比 groups 用户名 更可靠
id -Gn 会强制重读 /etc/group（尤其在较新 glibc 系统上），绕过部分缓存逻辑，更适合脚本或调试场景。它和 groups 用户名 输出格式一致（空格分隔组名），但更可能反映出刚添加的附加组。
对比差异：
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
groups alice：轻量、快，但依赖当前进程的 credentials 缓存 -
id -Gn alice：稍慢一点，但更贴近系统当前配置的真实视图 -
id alice：带 UID/GID 数字，适合人工排查，但不适合管道取值（比如grep docker）
脚本里判断用户是否在某组，优先用 id -Gn 用户名 | grep -qw docker，别用 groups 用户名 | grep。
查不到用户？先确认用户名是否存在
groups 用户名 报错或静默失败，不一定是权限问题，也可能是用户名根本不存在。先跑 getent passwd 用户名 或 id 用户名 看是否返回结果。
-
getent passwd 用户名走 NSS 框架，能穿透 LDAP/NIS，比cat /etc/passwd更全面 - 如果
id 用户名都报no such user，那groups 用户名必然失败 - 某些加固系统把
/etc/passwd权限设为640，非 root 用户连是否存在都查不到
为什么 groups 用户名 和 getent group 组名 显示不一致
groups 用户名 列的是该用户“当前会话拥有的组”，而 getent group docker 查的是“docker 组里显式列出的成员”。这两者本就不等价：
- 用户可以属于某个组作为主组（记录在
/etc/passwd第四字段），但不会出现在/etc/group对应行的成员列表里 -
getent group sudo永远不会列出root，因为 root 是靠 UID=0 特权绕过检查，不是靠组成员身份 - 容器内执行
groups 用户名看不到宿主机新加的组——用户 namespace 隔离导致凭证无法穿透
真正要验证权限是否生效，唯一办法是让目标用户启一个新登录会话（su - 用户名 或重新 ssh 登录），再跑 id -Gn。
