最准方法是运行groups或id -Gn，二者均显示当前会话生效的全部组（主组+附加组）；usermod -aG添加组后需重新登录才生效，漏-a会覆盖原有附加组。
怎么确认当前用户属于哪些组
直接查 /etc/group 不但慢，还容易漏掉运行时切换的组（比如用 newgrp 临时加入的）。最准的方法是运行：
- groups —— 显示当前 shell 会话中生效的所有组（主组 + 附加组）
- id -Gn —— 功能等价，-G 取全部组 ID，-n 转成组名，语义更清晰
注意：用 usermod -aG 添加组后，必须新开终端或重新登录才生效；只改配置文件不刷新内核组缓存。
加组别一上来就覆盖原有组
常见错误：usermod -G docker alice 表面是加组，实际把 alice 的全部附加组清空，只剩 docker。原属的 sudo、plugdev 等全失效。
- 正确写法是 usermod -aG docker alice，-a 和 -G 必须同时出现才表示“追加”
- adduser 默认交互式添加，不会覆盖已有组，但不适合脚本批量操作
- 自动化场景一律优先用 usermod -aG
chgrp 之后还是不能读？缺了两个硬条件
改完文件属组（chgrp groupname file）不等于权限自动生效。必须同时满足：
- 目录要有执行（x）权限：组成员才能 cd 进入或 ls 列出内容——这点比文件本身权限更关键
- 新建文件的默认组权限受 umask 控制：例如 umask 0022 → 新建文件权限为 644（rw-r--r--），组用户只能读；要支持组写，需设 umask 0002 或对父目录设 setgid（chmod g+s dirname）
sudo 权限没反应？先看 sudo -l 输出
执行了 usermod -aG sudo alice 却仍提示“user not allowed to run sudo”，原因常不在命令本身：
- 发行版策略不同：Ubuntu/Debian 默认启用 %sudo，CentOS/RHEL 默认启用 %wheel，且 /etc/sudoers 中 %wheel 行常被注释
- 最快验证方式：sudo -l -U alice 直接列出该用户实际可执行的命令，比翻配置文件更可靠
- 若提示拒绝，先用 groups alice 确认是否真在目标组，再检查 /etc/sudoers 中对应组是否启用、有无 !sudo 类显式禁止
