usermod -g 会覆盖而非追加附加组，必须加 -a 参数才能追加；修改 /etc/group 后需重新登录生效；组权限生效还需匹配文件属组及对应权限位。
usermod -G 会覆盖原有附加组，不是追加
直接执行 usermod -G groupname username 会导致用户**丢失所有旧的附加组**，只保留在命令中显式列出的组。这是最常踩的坑——你以为是“加组”，实际是“重置附加组列表”。
正确做法必须带上 -a（append）参数：usermod -a -G groupname username。不加 -a，-G 的行为就是清空再写入。
- 查当前用户所有组：运行
id username，看groups=...后面的列表 - 想加多个组：一次写全，比如
usermod -a -G dev,ops,backup alice - 不能分多次执行
-a -G：每次都要包含全部目标附加组，否则漏掉的就没了
/etc/group 文件修改后需重新登录才生效
手动编辑 /etc/group 虽然能改组成员，但 shell 会话不会自动刷新组信息。用户当前登录 session 仍沿用登录时读取的组快照，哪怕 id 命令在新终端里显示已更新，老终端里 groups 还是旧的。
临时验证可用 newgrp groupname 切换当前会话的主组（仅对当前 shell 有效），但附加组仍不生效；真正生效必须退出并重新登录，或用 su - username 模拟全新登录。
- SSH 登录用户：关掉当前连接，重连
- 图形界面用户：注销再登录，或重启终端模拟器
-
sudo su - username可快速测试新组权限，无需登出
组权限生效依赖文件/目录的属组和权限位
把用户加进组只是第一步。该组要真正起作用，还得看目标文件或目录的属组（group ownership）是否匹配，并且对应权限位（group rwx）是否打开。
例如用户 bob 已加入 webdev 组，但 /var/www/html 属组是 root、权限是 755，那 bob 依然只能读，不能写——因为 group 权限针对的是 root 组，不是 webdev 组。
- 改属组：用
chgrp webdev /var/www/html或chown :webdev /var/www/html - 开 group 写权限：用
chmod g+w /var/www/html（注意别误开 world-writable） - 递归设置（如需）：
chgrp -R webdev /var/www/html && chmod -R g+rw /var/www/html
sudo 权限和组权限是两套机制，别混用
把用户加到 wheel 组（usermod -a -G wheel username）只是启用 sudo 的前提，不代表用户自动获得 root 级文件操作权。sudo 执行命令时以 root 身份运行，绕过了常规文件权限检查；而普通 shell 操作仍受属组 + 权限位约束。
常见误解：以为“加了 wheel 组就能直接 vim /etc/nginx/nginx.conf”，其实不行——vim 仍以用户身份打开文件，没写权限就会提示 readonly。正确做法是 sudo vim /etc/nginx/nginx.conf，或先改文件属组+权限。
- 确认 sudo 开关已启用：检查
/etc/sudoers中是否有%wheel ALL=(ALL) ALL且未被注释 - 组权限用于服务进程访问控制（如 nginx worker 进程属
nginx组，静态文件需属同组可读） - sudo 权限用于运维操作，不应替代合理的文件属组设计
真实场景里，组权限策略失效往往卡在“改了用户组但忘了同步改文件属组”，或者“用了 -G 没加 -a 导致其他组权限意外丢失”。这两点比语法本身更值得盯紧。
