阿丁的猫如果你刚装好一台 Linux 虚拟机，或者刚接手一台跑着 Linux 的服务器，我建议第一件事别急着装软件，而是先把用户体系理清楚。新建一个平时干活用的普通用户，把密码和 SSH 配好，再想清楚哪些命令需要临时用 sudo 执行。这样后面做权限管理、日志查看、服务排障都会顺很多。老实说，我早几年也喜欢一登录就切 root，觉得省了 sudo 那一堆字。直到有一次删日志时少打了一个路径，把正在运行的应用目录一起清掉才彻底明白，Linux 的用户体系不是摆设，它真是一道保命的安全边界。
这篇内容主要围绕 Linux 用户与系统基础操作展开：为什么要区分用户、Linux 新建用户和用户组怎么弄、文件权限和普通用户到底什么关系、拿到新机器后用哪些 Linux 常用命令做基础检查，以及我实际踩过的坑。适合刚准备转向 Linux 的开发者、运维新手，也适合团队内部做 Linux 入门分享时直接拿去做参考。整篇没有太晦涩的内核源码，所有命令我都会尽量说清楚每一段是干嘛的、为什么这么写。
1. 用户管理没搞懂，Linux 越用心越虚
1.1 为什么 Linux 非要区分 root 和普通用户
Linux 从内核层面就设计成多用户操作系统。所谓多用户，不只是说系统里可以放多个不重名的账号，而是每个账号都有自己独立的 UID、家目录和权限边界。root 的 UID 固定是 0，它启动的所有进程在内核里都带着“特权通行证”；普通用户的 UID 一般是 1000 以上，某些系统服务账户则用小于 1000 的 UID，比如 nginx 用户经常是 999，sshd 用户也可能是 103。只要你不是以 root 身份执行，写文件时就会先被内核检查权限，越界操作会被直接拒绝。
这个机制最大的价值在于“最小影响”。日常操作你只能用普通用户身份读自己的家目录、启动自己的进程，系统级配置文件仍然归 root 管，即便命令写错，也不会瞬间把 /etc 目录弄乱。判断当前身份最可靠的方式不是看命令提示符里的 $ 或 #，而是执行 id，观察 UID 是不是 0。所以我后来写脚本判断权限时，也养成了检查 UID 的习惯，而不是单纯看用户名。用户名只是给人看的标签，内核真正认的是 UID。
但服务器总有需要装软件、改配置、重启服务的时候，所以才有 sudo 机制：普通用户通过授权，可以临时以 root 身份执行指定命令。这套“平时用普通用户，必要时 sudo”的组合，就是 Linux 系统基础操作里最需要建立的意识。后面的 useradd、passwd、chmod、usermod，全都围绕这套体系运行。
1.2 用户、进程和文件之间的权限链路
把前面说得稍微“底层”一点，其实就一条链路：用户登录后，shell 进程会带着该用户的 UID/GID 启动；以后从 shell 里执行的每一条命令、每一个程序，都是该用户的子进程，继续继承这个 UID/GID。内核判断某件事能不能做，看的不是“你这个人熟不熟”，而是当前进程的 UID/GID 与操作对象上的权限标记是否匹配。
所以，一个用户能不能删除某个文件，至少要看两层：对文件本身有没有写权限，同时对文件所在目录有没有写权限。遇到 Permission denied 时别慌，最常用的做法是把 id 的输出和 ls -l 的结果摆在一起对比，十有八九能定位到是用户不对、目录属主不对，还是权限位缺了。理解这条链路后，再看用户管理、目录权限、sudo，就不会觉得它们是零散命令，而是一套联动的安全模型。多台机器管理起来，基础越牢越省力。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Linux 新建用户和用户组，这样实操最稳妥
2.1 创建用户前，先想清楚 shell、家目录和附加组
Linux 新建用户不是敲一条 useradd 就完事，提前回答三个问题更稳妥：这个用户需不需要交互式登录？要不要单独建家目录？除了默认组，还要加入哪些附加组？
普通运维或开发账号一般要登录操作，可以用 /bin/bash，并创建 /home/用户名 作为家目录。程序运行账户，比如用来跑 nginx 的 nginx 用户，通常不需要登录 shell，也不推荐给它建家目录，可以用 /usr/sbin/nologin 禁止登录。临时外包人员或客户账号，建议设置账号过期时间，到期自动失效或强制改密。
这几个参数不提前想清楚，后面容易出现“新用户登录后没有 home”“服务账号被人拿去执行命令”的情况。我自己的习惯是，只有长期有人使用的账号才给 bash 和家目录，纯服务账号一律 nologin。前期多想一分钟，后面能省不少排查时间。
2.2 用 useradd 和 passwd 创建一个标准用户
不同发行版对 useradd 的封装不一样。Debian/Ubuntu 里还有一个 adduser 命令，本质是个交互式 Perl 脚本，会自动创建家目录并询问密码，对新手非常友好。useradd 则是更底层的命令，不带参数时可能只加一个账号，连 home 目录和密码都不帮你处理。所以我在脚本里常用 useradd，手动创建账号也偏爱它，但一定会把必要参数写全。
创建一个普通运维用户 deploy，常见命令是这样：
bash复制sudo useradd -m -s /bin/bash -G devops deploy
sudo passwd deploy
参数含义：-m 创建并初始化家目录 /home/deploy，同时会继承 /etc/skel 里的默认文件；-s /bin/bash 指定登录 shell；-G devops 把用户加入名为 devops 的附加组。如果不管主组，系统会自动创建一个与用户名同名的组，并把该组设为主组。可以观察一下：不同发行版下，useradd 对“是否默认创建家目录”处理并不完全一致，想稳定创建，就永远别漏掉 -m。
创建成功后建议顺手验证三件事：
bash复制id deploy
ls -ld /home/deploy
sudo -u deploy id
第一行看用户 UID、GID 和附加组；第二行看家目录权限和属主；第三行用 deploy 身份执行命令，确认它不是“只能登录但什么都跑不了”的僵尸账号。如果没有创建家目录，可以补：sudo mkdir -p /home/deploy && sudo chown deploy:deploy /home/deploy，再用同样代码验证。
2.3 认识 /etc/passwd、/etc/shadow 和 /etc/skel
Linux 的用户信息不是存在某个复杂数据库里，而是分布在几个关键文件中。/etc/passwd 每一行代表一个用户，例如：
code复制deploy:x:1001:1001::/home/deploy:/bin/bash
从左到右分别是用户名、密码占位符 x、UID、GID、注释字段、家目录、登录 shell。这里的 x 说明真实密码哈希存在 /etc/shadow 中，这个文件普通用户不可读，只有 root 和 shadow 组能读。日常不建议手动编辑 /etc/passwd，所有变更都用 useradd、usermod、userdel 等命令完成。
/etc/skel 则是非常实用的模板目录。当你用 useradd -m 新建用户时，命令会把 /etc/skel 下的所有文件复制到新用户家目录。所以如果希望每个新用户默认带上调优过的 .bashrc、.vimrc，或者统一预置一个 .ssh 目录，就可以提前放进 /etc/skel。批量开通账号时，这个技巧能省下大量重复配置时间。
配置公钥登录模板时特别注意权限：.ssh 目录权限必须是 700，authorized_keys 文件权限必须是 600，否则 sshd 会出于安全考虑拒绝使用。曾经我图省事直接创建 755 的 .ssh，结果新用户始终无法免密登录，查日志才发现是权限太宽松。所以模板做成：
bash复制sudo install -d -m 700 /etc/skel/.ssh
sudo install -m 600 /path/to/authorized_keys /etc/skel/.ssh/authorized_keys
以后再 useradd -m 新用户，他们天然就带着公钥登录能力。
2.4 用户组的创建、加入和删除细节
用户组主要用来共享文件权限。比如搭建一个项目共享目录，把参与项目的几个账号都加入 dev 组，然后目录属组设为 dev，组内用户就有权读写。最常用的命令是：
bash复制sudo groupadd dev
sudo usermod -aG dev alice
sudo gpasswd -a bob dev
查看用户当前所属组，执行 id alice 或 groups alice。加入组的场景里有个很容易翻车的点：usermod -aG 中的 -a 一定不能漏。如果你写成了 sudo usermod -G docker deploy，系统会把 deploy 从现有所有附加组中移出去，只保留 docker 组。如果 deploy 原来是通过 sudo 或 wheel 组获得管理员权限的，这一下就会让账号失去 sudo 能力，而且通常要等到执行管理员命令时才傻眼。
删除组 sudo groupdel dev 前也要先确认：这台机器上有没有用户把这个组当主组。如果有，groupdel 会报错。更安全的做法是先看哪些用户的主组是它，再决定是否改主组或删账号。删除组不像删除普通文件那么随意，它关联着目录权限里的 GID。
2.5 修改、锁定和删除用户的安全姿势
常见修改动作包括禁用 shell、设置密码过期、锁定密码。逐个看：
bash复制sudo usermod -s /usr/sbin/nologin alice # 禁止交互式登录
sudo chage -E 2024-12-31 alice # 账号过期时间
sudo passwd -l alice # 锁定密码
sudo usermod -U alice # 解锁密码
注意，passwd -l 只锁定密码登录。如果用户配置了 SSH 公钥，仍然可能通过公钥登录系统，所以真要封禁账号，最好同时把 shell 改成 nologin，或者干脆设置账号过期。删除用户时使用：
bash复制sudo userdel -r alice
-r 会同时删除用户家目录和邮件池，这个操作不可逆。删除之前先执行 pgrep -u alice 确认没有该用户启动的进程，否则容易出现“账号没了，进程还在跑，文件变孤儿”的状态。处理离职员工的账号，我建议先锁定，再检查数据是否备份，最后过一段时间再删除。别一上来就 userdel -r，万一里面有项目数据没同步，找回成本会非常高。
3. 文件权限与 sudo：搞不清这两个，系统迟早出乱子
3.1 rwx 和数字权限：为什么你在目录里写不进文件
用 ls -l 查看文件或目录时，第一段信息类似 drwxr-xr-x。第一个字符表示类型，d 是目录，- 是普通文件。后面 9 个字符分成三组：属主权限、属组权限、其他用户权限。每组按顺序是读 r、写 w、执行 x。没有对应权限就是 -。
权限落在文件和目录上，含义差别很大，这个很多人会混淆。整理成表会更清楚：
| 权限 | 对文件的作用 | 对目录的作用 |
|---|---|---|
| r | 读取文件内容 | 列出目录里有哪些文件名 |
| w | 修改文件内容 | 在目录里创建、删除文件或子目录 |
| x | 执行该文件（如果是脚本或程序） | 进入目录，访问目录内的文件和子目录 |
所以“删除某个文件”这个动作，真正起决定作用的可能是父目录的写权限，而不是文件本身的写权限。对目录没有 x 权限，哪怕你对里面的文件有 r 权限，也很难正常访问到文件内容，因为操作系统需要先“穿过”目录路径。
数字权限本质是二进制组合，r 计 4，w 计 2，x 计 1。常见值对应关系：7=rwx，6=rw-，5=r-x，4=r--。所以 chmod 755 script.sh 表示属主可读可写可执行，属组和其他人只能读和执行。日常服务器上的目录常设 755，普通文件常设 644，脚本要可执行才设 755。
3.2 chown 与 chmod 的经典场景：改错属主比改错权限更隐蔽
遇到新部署的应用写不了日志，常见操作是看日志目录属主是谁。比如 nginx 的日志目录一般属于 www-data 或 nginx 用户，你把文件复制过去后如果属主还是 root，服务进程就没法写文件。此时需要：
bash复制sudo chown -R www-data:www-data /var/log/nginx
sudo chmod -R 755 /var/log/nginx
如果目录需要被多个用户共同编辑，最好设置一个共享组。先把目录属组改成指定组，然后给组加读写权限：
bash复制sudo chgrp -R dev /srv/project
sudo chmod -R g+rwX /srv/project
sudo chmod g+s /srv/project
第三条 chmod g+s 给目录设置 setgid 位。效果是：在目录里新建文件时，文件的属组会自动继承目录的属组，而不是创建者自己的主组。这是很多人忽略的小细节。没有 setgid 时，团队成员 A 创建的文件属组是 A 自己的组，B 可能没有权限编辑，导致共享目录越用越乱。
还有 /tmp 目录的权限通常是 drwxrwxrwt，末尾的 t 是 sticky bit。它保证任何用户都能在 /tmp 里创建文件，但不能随意删别人创建的文件。这个机制对多用户临时目录非常关键，别把 /tmp 随手改成 777 或 733。
3.3 sudo 到底是什么，以及怎么给最小授权
sudo 不是简单地把普通用户“变成 root”，而是让当前用户以自己的密码通过授权校验后，临时以 root 身份执行某条命令。需要注意，su - root 要输入 root 密码，而 sudo 通常输入当前用户自己的密码，这在家里单机环境可能没区别，但在团队服务器上差别很大：root 密码知道的人越少越好。
用户能不能用 sudo，取决于 /etc/sudoers 或 /etc/sudoers.d/ 目录下的配置。最常规的做法是把用户加入系统管理员组，Debian/Ubuntu 上通常是 sudo 组，RHEL/CentOS/Rocky 上是 wheel 组：
bash复制sudo usermod -aG sudo alice
执行后退出当前登录，重新登录，再 sudo -l 查看自己有权执行的命令。如果配置正常，会看到一堆 sudoers 内容；如果提示不在 sudoers 文件中，就需要让 root 或其他具备 sudo 权限的用户帮处理。
给应用账号最小权限时，可以在 /etc/sudoers.d/deploy 里写：
code复制deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx
这行的意思是：deploy 可以在任何主机上，以 root 身份免密执行 systemctl restart nginx 这一条命令。修改 sudoers 必须使用 visudo，因为它会做语法校验，防止你写错导致整个 sudo 不可用。我见过有人直接 vim /etc/sudoers，写错一个符号后所有用户都没法 sudo，最后只能进单用户模式修复，实在不值得。
3.4 用 sudo 排错时容易忽略的环境变量差异
有个非常经典的报错：普通用户执行 sudo pm2 list，系统提示 sudo: pm2: command not found，但你自己直接执行 pm2 list 又完全正常。原因是 sudo 默认使用 secure_path，这个环境变量里的 PATH 不一定包含用户安装软件的目录，比如 ~/.nvm/versions/node/.../bin 或 ~/.local/bin。
解决办法不是直接给 sudoers 配一个超宽的 PATH，而是用 which pm2 查出绝对路径，再用绝对路径执行：
bash复制sudo /root/.nvm/versions/node/v20.11.0/bin/pm2 list
如果这条命令确实经常要执行，可以在 /etc/sudoers 里适当调整 secure_path，但尽量精确，别把用户目录随意塞进去。还有一个很实用的调试命令：sudo -u 用户名 命令，这可以模拟指定用户身份执行命令。比如排查 web 目录写入权限时，我会执行：
bash复制sudo -u www-data touch /var/www/html/test.txt
如果成功，说明 www-data 对目录有写权限；如果失败，就把 id www-data 和 ls -ld /var/www/html 的输出拿来做对比，很快能定位问题。
4. 新机器“第一轮体检”：Linux 常用命令搭配用户操作
4.1 先确认你是谁，再看系统是什么
拿到新服务器或新虚拟机，第一步不是急着装环境，而是确认登录身份和系统版本。最基本的命令组合：
bash复制whoami
id
cat /etc/os-release
uname -a
hostnamectl
whoami 和 id 让你知道当前是什么用户、UID 和加入的组。如果显示 uid=0(root)，后面所有操作都要格外小心；如果显示普通用户，则需要 sudo 时再提权。cat /etc/os-release 能告诉你发行版名称和版本号，比如 Ubuntu 22.04.3 LTS 还是 CentOS Stream 9，这直接影响后面用 apt 还是 dnf 装软件。uname -a 则用来确认 CPU 架构，比如 x86_64 还是 aarch64，排查镜像下载和二进制兼容性问题时会用到。
我习惯把这些输出先存到终端日志里，后面装软件时对照架构和发行版。很多时候“为什么这个包装不上”的答案，其实在 os-release 和 uname 里就已经写得很明确了。
4.2 检查 CPU、内存、磁盘和文件占用
基础体检第二个组合拳是看资源和磁盘：
bash复制uptime
free -h
df -hT
du -sh /home/* 2>/dev/null
uptime 看系统负载；free -h 看内存和 swap；df -hT 看磁盘使用率。如果发现根分区接近 100%，需要进一步用 du -sh /var/log/* 之类命令定位大目录。找出某个目录下最大文件的命令：
bash复制du -ah /var 2>/dev/null | sort -rh | head -20
这条命令在排查磁盘告警时非常常用。要注意，普通用户能执行 du 的范围有限，遇到 Permission denied 就加 sudo。服务器磁盘满通常不会立刻报警，但会导致日志写不进、临时文件创建失败，程序表现千奇百怪，体检时提前看磁盘是很有必要的。
4.3 查看进程和服务状态，别只会 top
最常用的进程查看命令是 top，但非交互环境下用 ps 更灵活。查占用内存最多的进程：
bash复制ps aux --sort=-%mem | head -10
另一个常用组合是 systemd 服务相关：
bash复制systemctl status nginx
systemctl list-units --type=service --state=running
journalctl -u nginx -n 50 --no-pager
systemctl status 看服务状态，list-units 看当前有哪些服务在跑，journalctl -u 看某个服务的最近日志。开机自启配置用 systemctl enable nginx，只临时启动用 systemctl start nginx。服务崩了之后，很多新手只知道重启，却不看日志，最后陷入“重启、崩溃、再重启”的循环。养成先看 journalctl 的习惯，能把排查时间压缩一大截。
4.4 网络端口和连接状态快速检查
新机器上排查端口冲突时，可以用 ss 替代老旧的 netstat：
bash复制ss -tlnp
-t 只看 TCP，-l 只看监听，-n 不反解域名，-p 显示进程号。不过普通用户执行 -p 时未必能看到别人进程，系统会出于保护隐藏 PID 对应关系，所以需要加 sudo 才能看到完整信息。如果想测试某个本地端口是否通：
bash复制curl -I http://127.0.0.1:8080
这条命令我常用于确认 nginx 或后端服务是否真的在监听。如果 curl 一直卡住没响应，优先看防火墙和服务日志，再回头看 ss -tlnp 的输出，比在浏览器里反复刷更高效。
4.5 软件包管理：为什么你必须用 sudo 装软件
Linux 装软件最常用的是发行版包管理器。Debian/Ubuntu 系的安装流程：
bash复制sudo apt update
sudo apt install -y nginx
RHEL 系对应：
bash复制sudo dnf check-update
sudo dnf install -y nginx
包管理器在系统级目录写入文件，普通用户没有权限，所以必须用 sudo。如果普通用户