最简方式是直接运行 groups 命令，输出当前用户所有组名（空格分隔）；它读取 /etc/group 匹配 GID，不显示数字 ID，适合快速确认权限上下文。
查看当前用户所属组的最简方式
直接运行 groups 命令就能输出当前用户的全部组名，空格分隔，结果清晰、无冗余。它本质是读取 /etc/group 并匹配当前用户的 GID 和附加组，不显示数字 ID，适合快速确认权限上下文。
常见错误：在脚本里用 groups | cut -d' ' -f1 提取第一个组——这取到的是主组名，但主组未必是登录时的默认组（取决于 /etc/passwd 第四字段），更稳妥的方式是结合 id -gn。
- 只输入
groups，不加参数、不加用户名，就是查当前用户 - 加用户名如
groups www-data可查其他用户，但需有读取/etc/group权限 - 输出为空？说明该用户仅属于其私有同名组（即
id -g对应的那个组），且未被加入任何附加组
id 命令比 groups 多出哪些关键信息
id 不只是看组，它把用户身份全貌一次性打出来：UID、GID、主组名、所有附加组及其 GID。对调试权限问题特别有用——比如 docker 命令报 “permission denied”，光看组名不够，得确认当前 shell 是否真的拿到了 docker 组的 GID。
典型误用：id -G 输出纯数字 GID 列表，而 id -g 只返回主组 GID（不是名称）。如果脚本里需要组名，必须用 id -gn 或 id -Gn，否则后续 grep 或判断会失败。
-
id（无参数）：显示 UID、GID、主组名、全部附加组名 -
id -u/id -g：只输出数字 UID/GID，适合条件判断 -
id -Gn：输出所有组名（含主组），空格分隔，和groups输出格式一致但更可靠 -
id -G：输出所有 GID，不含主组 GID？错——它包含主组 GID，但顺序不固定，不能假设第一个是主组
为什么 groups 和 id 有时显示不一致
这不是 bug，而是缓存或会话状态导致的。最常见场景：你刚用 usermod -aG docker $USER 加了组，但没重新登录或没启动新 shell，此时 groups 还是旧列表，而 id 在某些系统（如较新 glibc）下可能已反映变更——其实两者都依赖内核的 credentials 缓存，真正生效要等进程继承新凭证。
另一个原因：groups 默认只查当前进程的组列表，而 id 在加 -r 参数（id -r）时会强制重读 /etc/group，绕过缓存。但这不解决根本问题——新组权限仍需新登录会话。
- 执行
newgrp docker可临时切换主组并刷新组列表（但会启新 shell） - 图形界面用户常忽略：即使终端重启，桌面会话仍用旧凭证，需完全登出再登录
- 容器内执行
groups看不到宿主机新增的组，因为容器用户 namespace 是隔离的
脚本中安全获取主组名和判断是否在某组
别用字符串匹配 groups 输出来判断权限，容易因空格、换行或组名含空格（虽罕见但合法）出错。优先用 id -Gn 配合 grep -qw，或直接用 id -nG | grep -q '^docker$' 锚定整行匹配。
获取主组名务必用 id -gn，而不是 groups | awk '{print $1}'——后者在用户被移除所有附加组后才等于主组名，不可靠。
- 判断是否在
sudo组：id -Gn | grep -qw sudo - 获取主组名：
id -gn（唯一正确方式） - 导出所有组名为数组（Bash）：
read -ra GROUPS ，之后可用 <code>${GROUPS[@]} - 注意
id -Gn在最小化系统（如 Alpine）中可能不可用，需装coreutils
