groups命令直接显示当前会话生效的组名（空格分隔），但不保证主组在首；主组应使用id -gn获取，新增组需重新登录才能生效，缓存导致groups/id可能滞后。
直接运行 groups 就能看到当前用户所有组名
敲下 groups 回车，输出就是当前 shell 会话实际生效的全部组名，空格分隔。它不显示数字 ID，只列名称，适合快速确认权限上下文——比如输出 users docker www-data，说明你此刻能以这三个组身份访问资源。
常见错误：脚本里写 groups | cut -d' ' -f1 提取第一个组，以为那是“主组”。但 groups 输出顺序不保证主组在前；更稳妥的方式是用 id -gn 获取主组名。
- 普通用户只能查自己，加用户名（如
groups alice）需 root 权限，且结果可能滞后——刚用usermod -aG docker alice加完组，不重新登录就查，仍看不到docker - 输出为空？说明该用户只属于其私有同名组（即
id -g对应的那个），没被加入任何附加组 -
groups依赖进程已缓存的凭证，不是实时重读/etc/group；图形界面用户常忽略：即使终端重启，桌面会话仍用旧凭证，需完全登出再登录
id 比 groups 多出 UID/GID 和组权限全貌
id 不只是看组，它把用户身份一次性打出来：uid、gid、主组名、所有附加组及其 GID。调试权限问题时特别有用——比如 docker 命令报 permission denied，光看组名不够，得确认当前 shell 是否真的拿到了 docker 组的 GID。
-
id -Gn输出所有组名（含主组），格式和groups一致但更可靠，尤其在较新 glibc 系统上 -
id -G输出纯数字 GID 列表（含主组），但顺序不固定，不能假设第一个是主组 -
id -g只返回主组 GID（数字），不是名称；需要名称请用id -gn - 执行
id -r可强制重读/etc/group，绕过部分缓存逻辑，但不解决根本问题——新组权限仍需新登录会话
查系统所有本地组别，别只靠 cat /etc/group
cat /etc/group 能看到所有本地定义的组，但注意：成员字段只列附加用户，不包含主组用户（例如用户 alice 的主组是 alice，但 alice 组那一行的成员字段通常为空）。所以单靠 grep alice /etc/group 可能漏掉主组关系。
- 只看组名：用
cut -d: -f1 /etc/group - 查某组是否存在（避免误匹配注释或子串）：用
getent group 组名，比grep更准确 - 如果系统启用了 LDAP/SSSD（看
/etc/nsswitch.conf），/etc/group只反映本地部分；此时应改用getent group查所有组（含网络组） - 仅查本地源、排除网络结果：用
getent files group
验证权限是否真生效，不能只信命令输出
刚加完组后，groups 和 id 显示不一致不是 bug，而是内核 credentials 缓存机制导致的。最可靠验证方式是启动新登录会话（logout/login 或 su - $USER），而不是反复跑命令等刷新。
- 容器内执行
groups看不到宿主机新增的组，因为用户 namespace 是隔离的 - 脚本中安全获取主组名：别用字符串匹配
groups输出，改用id -gn - 判断是否在某组：用
id -Gn | grep -qw 组名，比groups | grep -qw更稳，因前者绕过部分缓存
真正生效的唯一方式是让进程继承新凭证——这意味着新 shell、新登录、或至少 newgrp docker（但它会启新子 shell）。别在旧会话里死磕输出。
