1. 为什么用户与用户组这块总要补一刀Linux 的用户和用户组入门时看起来就三条命令的事useradd、passwd、usermod做完就能登录。但真正在生产环境里泡过一段时间就会发现账号管理是个典型的入门一天、精通三年的领域。它不像装个软件那样有明确的装完即止而是随着人员流动、项目更替、权限审计一路演进每次演进都会留下一点历史包袱。我这篇算是之前那篇用户与用户组基础操作的补充专门讲那些第一遍学不会、第二遍踩坑才记住的东西。先说三个我亲身遇到的场景你就知道为什么这块值得单独拿出来补。第一个场景某台业务机上跑着一个三年前的部署脚本脚本里写死了deploy用户的 UID 是 1001。后来运维同事清理账号时把deploy删了过两个月新建了一个实习生账号系统自动分配了 1001。结果这个实习生的账号一夜之间拥有了/data/app下所有历史文件的读写权限因为 Linux 只认 UID不认用户名。第二个场景团队共享目录/srv/share权限设成 2775看着没问题但新建文件的属组老是不对后来发现是用户的主组和附加组没区分清楚。第三个场景离职同事的账号忘了锁半年后 ssh 登录日志里还能翻到异常尝试。这三个坑的共同点是命令你都会但你没有把背后那套编号规则、组归属规则、身份切换规则串起来。串不起来就只能靠试错而试错的成本在服务器上是真金白银。1.1 五个核心文件各管一摊事很多人学用户管理时最大的困惑是为什么改个用户名要动好几个文件因为 Linux 把用户信息拆成了给人看的和给系统算的两套前者明文可读后者加密保护。你要建立一个清晰的心智模型账号信息是分层的每一层有自己的职责和访问权限。文件存什么权限谁能读/etc/passwd用户名、UID、GID、注释、家目录、登录 shell644所有人/etc/shadow密码哈希、密码有效期、账号失效日640 或 000仅 root/etc/group组名、GID、成员列表644所有人/etc/gshadow组密码、组管理员640仅 root/etc/login.defsUID/GID 分配范围、密码策略默认值644所有人这里有个特别容易被忽略的细节/etc/passwd的第二个字段现在几乎都是x它是个占位符真正的内容被搬到了/etc/shadow。早年间密码哈希就是直接写在/etc/passwd里的但那个文件所有人可读任何本地用户都能把哈希拖走离线爆破所以才有了 shadow 机制。理解这段历史你就明白为什么改密码必须用passwd而不是直接编辑文件。另一个细节/etc/group里只记录附加组成员不记录主组成员。这是新手最容易懵的地方。假设alice的主组是alice附加组是devs那么她在/etc/group里只会出现在devs那一行alice组那一行是空的。想看一个用户到底属于哪些组别去 grep 文件直接用id alice它会把主组和附加组一次列全。1.2 UID 是真正的身份证用户名只是标签再强调一遍这个核心观念因为它决定了后面所有操作的思路内核在处理文件权限时比较的是 UID 和 GID 这两个数字跟用户名一点关系都没有。用户名只是给人看的可读标签你把alice改名成alice_new她名下所有文件的归属显示会自动跟着变因为 UID 没变系统只是换了个名字去查。反过来如果两个账号的 UID 相同那在内核眼里它们就是同一个人。这种情况下ls -l显示的是先被查到的那个名字会让人误以为文件归属搞错了。所以排查权限问题时第一步永远是ls -n用数字形式看 UID/GID而不是看名字。这个小技巧后面还会反复用到。理解了这两条我们再往下走就顺了。下面按建号前的准备 → 建号 → 组管理 → 密码与有效期 → 身份切换 → 权限设计 → 删除与批量 → 排查这条链路把每个环节补细。2. 建用户之前先把默认规则摸清楚useradd alice这条命令之所以能什么都不用给就建出一个可登录的账号是因为它背后有一堆默认值。默认值不对后面就得靠usermod一个个往回改很费劲。所以真正高效的做