直接运行groups命令即可查看当前用户所有组名，空格分隔，不显示数字id，适合快速确认权限上下文；但其输出顺序不保证主组在前，且依赖进程缓存，新组需重新登录才生效，而id命令可提供uid、gid及全部组的数字与名称信息。
直接运行 groups 就能看当前用户所有组
不用加参数、不用 sudo、不用指定用户名——敲完回车，输出就是你当前 shell 会话实际生效的全部组名，空格分隔。它不显示数字 ID，只列名称，适合快速确认权限上下文。比如输出 users docker www-data，说明你此刻能以这三个组身份访问资源。
常见错误：脚本里写 groups | cut -d' ' -f1 提取第一个组，以为那是“主组”。但 groups 输出顺序不保证主组在前；更稳妥的方式是用 id -gn 获取主组名，或 id -g 获取主组 GID。
groups 查其他用户要权限，且结果可能不准
想查别人，比如 groups www-data，必须有读取 /etc/passwd 和 /etc/group 的权限（通常需 root）。但要注意：这个命令查的是静态文件快照，不是实时凭证。如果你刚用 usermod -aG docker alice 加了组，但 alice 没重新登录，groups alice 仍不会显示 docker——因为进程没继承新组信息。
- 普通用户只能查自己，查别人会报
groups: cannot find name for group ID或直接无输出 - 输出为空？说明该用户只属于其私有同名组（即
id -g对应的那个），没被加入任何附加组 - 别依赖
groups username判断权限是否已生效，真要验证，得让目标用户开新 shell 再跑一次
和 id 命令比，groups 少了什么关键信息
groups 只给组名，id 才给出全貌：UID、主组 GID、所有附加组及其 GID。调试权限问题时，光看组名不够——比如 docker 命令报 permission denied，你得确认当前 shell 是否真的拿到了 docker 组的 GID，而不仅是名字匹配。
容易踩的坑：
-
id -G输出纯数字 GID 列表（含主组），但顺序不固定，不能假设第一个是主组 -
id -g只返回主组 GID（数字），不是名称；需要名称请用id -gn -
id -Gn输出所有组名（含主组），格式和groups一致，但更可靠——它绕过某些缓存逻辑，尤其在 glibc 较新系统上
为什么有时 groups 和 id 显示不一致
这不是 bug，而是内核 credentials 缓存机制导致的。最常见场景：你刚执行 usermod -aG docker $USER，立刻跑 groups 还是旧列表，但 id 在部分系统上可能已显示新组——因为 id 默认会重读 /etc/group，而 groups 更倾向用进程已缓存的凭证。
真正生效的唯一方式是启动新登录会话（logout/login 或 su - $USER）。临时测试可用 newgrp docker 切换当前 shell 的主组，但它不添加附加组，且会启新子 shell。
复杂点在于：组权限不是“写入配置就立刻可用”，它绑定到进程生命周期。哪怕 /etc/group 文件改了，老进程依然用旧凭证——这点常被忽略，却直接决定权限是否起作用。
