最安全通用的做法是用 usermod -ag sudo username 赋权，需重登录生效，验证用 sudo -l 和 sudo whoami；老系统用 wheel 组；严禁直接 echo 写 /etc/sudoers，必须用 sudo visudo；删用户务必加 -r 参数并清理 sudoers 中残留条目。
直接给结论：用 useradd 或 adduser 创建用户后，必须用 usermod -aG sudo（Debian/Ubuntu）或 usermod -aG wheel（RHEL/CentOS 8+）加组，再重新登录才真正生效——光加了组但没重登，sudo 一定失败。
useradd 和 adduser 到底该选哪个
两者都能创建用户，但行为差异直接影响后续是否要手动补步骤：
-
useradd是底层命令，不带交互，-m要显式加才能建家目录，-s /bin/bash要显式指定 shell，且**完全不设密码**——你得立刻跟一句passwd username，否则用户根本登不上 -
adduser是封装脚本，自动建家目录、复制/etc/skel文件、交互式设密码，适合手动操作；但它在某些最小化系统（如 Alpine 或某些容器镜像）里可能压根没装 - 自动化脚本里一律用
useradd，因为可控；临时建个测试账号，adduser更省心
为什么 usermod 必须带 -aG，而不是 -G
usermod -G sudo username 看似简洁，但这是高危操作：
-
-G会**覆盖**用户当前所属的所有附加组，比如原本在docker、plugdev组里的权限全丢 -
-aG的-a表示 “append”，只追加不覆盖，这才是安全做法 - 执行完
usermod -aG sudo username后，groups username输出里能看到sudo，但这只是“组成员身份已登记”，不代表sudo功能立刻可用
sudo 权限为什么加了组还提示 not in sudoers file
常见于三种情况，按优先级排查：
- 没重登录：SSH 会话或终端不会自动继承新组，必须断开重连，或运行
newgrp sudo（仅对当前 shell 有效） - 发行版不认
sudo组：CentOS 7 及更老版本默认注释掉了%sudo规则，得用wheel组；先查grep '^%sudo\|^%wheel' /etc/sudoers，确认哪行没被#注释 - 手改
/etc/sudoers出错：严禁用echo ... >> /etc/sudoers或直接vi /etc/sudoers；必须用sudo visudo，它会在保存前校验语法，写错一个字符就拒绝写入
验证 sudo 是否真生效，别只看 groups
groups username 返回有 sudo，只是第一步。必须实测两个命令：
-
sudo -l：输出应包含(ALL : ALL) ALL，如果为空或报错not in sudoers file，说明策略没加载或规则被注释 -
sudo whoami：输入密码后应返回root；如果卡住不动，去翻/var/log/auth.log，常是 PAM 模块或 SSH 配置限制了认证流程
最易忽略的一点：很多教程漏提——usermod -aG 改的是组数据库，但当前登录会话的组信息是在登录时从 /etc/group 读取并缓存的，不会动态刷新。不重登，一切验证都是假象。
