永远雪山前两天有个新同事问我：Linux 命令到底应该怎么学？他说自己从网上下了一份《Linux 命令大全》，几百条命令抄了两大页，可真上了服务器，还是搞不清磁盘空间被谁占了、服务为什么启动失败、远程传文件到底该用哪个参数。这个感觉我太熟了。刚入行那几年我也背过命令，后来才慢慢想明白一件事：真正重要的不是“记住多少条命令”，而是知道某类问题该找哪个工具、为什么要用它、出异常时怎么一步步查。这篇内容就按我自己的使用习惯，把 Linux 系统日常操作里最值得吃透的命令串一遍，重点覆盖文件定位、文件操作陷阱、用户与权限、远程网络传输、日志排查，以及拿到一台新机器后的体检方法。想认真做运维、开发，或者刚从 Windows 转 Linux 的朋友，都可以拿这篇当一条比较实在的实践路线。
1. 把“当前在哪、这里有什么”练成肌肉记忆：文件定位命令的使用逻辑
1.1 ls -l 列出的每一个字符，先搞懂再谈别的
很多人刚接触 Linux 时，习惯只敲 ls，看到一堆文件名就觉得完成了。但真正排查问题的时候，ls -l 才是最有用的姿势。它每一行的信息都非常固定：第一个字符表示文件类型，普通文件是 -，目录是 d，软链接是 l；之后每三个字符一组，分别代表所属用户、所属组和其他人的读、写、执行权限；接着是硬链接数量、属主、属组、文件大小和最后修改时间。
建议新人在第一周就养成一个习惯：想看目录内容，默认敲 ls -lh，看详细信息但把文件大小转成人类易读的 K、M、G；如果想看目录自身属性而不是目录里的内容，一定要敲 ls -ld 目录名。我见过很多人在脚本里写 ls -l /etc/nginx/，然后试图判断 nginx 配置目录本身的时间戳，结果看到的全是子文件的信息，这就是少了 -d 导致的。
还有一个小命令容易被忽略：stat。它能输出比 ls -l 更完整的 inode、修改时间、变更时间、访问时间。有时候你发现文件内容没变，但备份程序老认为它变了，这时候 stat 去看 Change 时间往往会发现问题，比如权限被改过、硬链接数变了，都会影响某些增量备份判断。file 命令也值得养习惯：看到一个没有后缀的文件，先 file 文件名 看一眼真实类型，再决定怎么处理。
1.2 你敲的路径真的对吗？用好 pwd、cd - 和通配符
路径问题是新手绕不开的坎。pwd 是最基础的命令，但有一个容易忽略的点：如果你通过软链接进入一个目录，pwd 默认显示的是逻辑路径，也就是你 cd 进去时用的那个软链路径；想看到真实物理路径，可以用 pwd -P。在处理 nginx、supervisor 这类带软链的安装目录时，这两个显示结果可能不一样，我在排查脚本时被这种“看起来在同一目录、实际却在另一个地方”的情况坑过。
cd - 是我每天都会用到的命令，它的作用是回到上一个所在目录。别看它简单，在两个项目目录之间反复切换时，比打一长串绝对路径高效得多。也可以在 Shell 里用 pushd 和 popd 维护一个目录栈，但它对大多数人来说不如 cd - 直觉。
通配符也是提高定位效率的关键。* 匹配任意多个字符，? 只匹配一个字符，[abc] 匹配方括号里的任意一个字符。这里有个多数人不知道的细节：通配符是在 Shell 展开后才把结果传给命令的，所以在执行前可以先敲 echo /etc/nginx/*.conf，看看 Shell 到底会把哪些文件传给后续命令。这种“先展开、再执行”的验证习惯，能避免很多误操作。举个例子，rm /tmp/data/*.log 如果前面的目录是空的，Shell 会原样把字符串传给 rm，rm 就会报“没有那个文件或目录”，而不是安静地什么都不做。
1.3 磁盘快满时：从 df 到 du 再到 lsof 的定位顺序
磁盘告警是 Linux 操作里最高频的故障之一，处理顺序基本是固定的。先敲 df -h 看整体分区使用率，确认到底是哪个挂载点满了；如果发现某个分区满了，再用 du -sh /路径/* 2>/dev/null 去逐层找大文件。du 的常见参数各有用途：-s 只给汇总，-h 显示人类可读单位，--max-depth=1 可以控制递归深度，防止它把整个文件系统扫一遍。
但这里有个经典坑：df 显示分区满了，du 却怎么都找不到大文件。我遇到过好几次这种情况，最后发现是有进程正在写日志，后来日志被删除或轮转掉了，但那个进程仍然持有已经删除的文件句柄，空间自然不会被释放。处理方法是执行 lsof +L1，它会列出所有被删除但仍被进程打开的文件，然后你就能看到是哪个进程占着那个文件。直接重启对应进程，或者 /usr/sbin/nginx -s reopen 这种方式让服务重新打开日志文件，空间才能真正回来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 删不掉、移错、链错：文件与目录操作里的三个高发事故
2.1 想删文件夹，先想清楚 rm -r 和 rm -rf 之间差在哪
“Linux 删除文件夹命令”一直是搜索量很大的词，我猜大部分人是奔着 rm -rf 去的。这个命令本身没有问题，问题出在不加区分地使用它。rm -r 表示递归删除目录及内容，-f 表示不提示、忽略不存在的文件。两者合在一起，就成了一个“不管目标是否存在、里面有什么、是否只读，都直接清掉”的强命令。
我的建议是：删除重要目录前，先敲一遍 ls -ld /目标路径 确认路径没写错；如果目录很大，可以考虑先 mv /目标路径 /tmp/待删除_时间戳，观察几天确认没有程序依赖它，再真正删除。这么做成本很低，却能在手滑时给你留一条后悔路。实际删除时，我习惯先 rm -r /tmp/xxx，不带 f，让系统对只读文件或子目录继续追问，多一道确认；如果是在脚本里需要静默删除，才用 rm -rf，而且变量必须写成绝对路径，避免路径变量为空时变成 rm -rf /。
还有一个容易忽略的东西：隐藏文件。ls 默认看不到以点开头的文件，rm -rf /tmp/目录 会把里面的隐藏文件一并删掉，但很多人只是在屏幕上没看见，就以为目录里没有东西。
2.2 cp 拷贝目录时，源路径末尾的“/”不是小事
很多人第一次用 cp -r 拷贝目录时，会惊讶地发现目标目录结构与预期不一致。关键就在源路径末尾是否带斜杠。cp -r /a /b/ 的结果是生成 /b/a；而 cp -r /a/ /b/ 是把 a 目录里的内容复制到 b 里，不会生成 a 这一层。这个差别在 rsync 里同样存在，而且后果更隐蔽。用 rsync 同步目录时，我个人的习惯是源路径尽量保留 /，目标路径也以 / 结束，比如 rsync -av /data/project/ /backup/project/。这样语义明确：同步的是内容，而不是再多包一层同名目录。
mv 也有一个值得记住的底层差别：同一分区里移动文件，只是修改目录项，速度极快；跨分区移动时，系统实际在做“复制到目标 + 删除源文件”，所以大文件会表现为一个漫长的复制过程。如果你要移动的文件非常大，比如几十 GB 的日志或镜像，建议先 df -h 看源和目标是否在同一个挂载点内，如果不在，优先用 rsync 同步到目标，确认无误后再删除源，避免 mv 中途失败导致数据不一致。
2.3 软链接和硬链接：一条快捷方式和一个“第二名字”
ln -s 创建软链接，也就是大家熟悉的快捷方式；不带 -s 的 ln 创建硬链接。软链接是一个独立的文件，它保存了指向目标路径的信息，如果目标被移走或删除，这个链接就断了。硬链接本质上不是一种新文件，它只是给同一个 inode 多起了一个名字。硬链接有几个生活中很实用的限制：不能跨文件系统创建；不能对目录创建；删除其中一个名字，原文件内容仍保留，因为 inode 的链接数还有剩余。
在日常操作里，我用到软链接的场景更多，比如用 /usr/bin/python3 软链到某个版本解释器、把项目日志目录软链到数据盘。但用 rm 删除软链接时要注意：如果你写的是 rm -rf 软链接路径/，shell 可能会把它当成目录处理，导致删除行为不符合预期。清理软链接时直接 rm 软链接路径 就好，不要画蛇添足加斜杠。判断一个文件是软链还是真实文件，用前面说的 ls -l 第一列 l 就能一眼看出来。
3. 新建用户不等于发了一个账号：用户、权限与进程状态的一条线
3.1 useradd -m 与 passwd：新建用户的两件套
很多发行版里单独执行 useradd username 并不会创建对应的家目录，也不会给你设置任何可以登录取巧的东西。这里最稳妥的建用户方式是 useradd -m -s /bin/bash username。-m 表示创建家目录，-s /bin/bash 是把默认 Shell 指定成 bash。不同发行版之间确实存在默认行为差异，比如 Debian/Ubuntu 系的 useradd 通常会自动创建家目录，而 RHEL/CentOS 系默认不会，所以养成显式带参的习惯，能少踩很多坑。
建完用户后再执行 passwd username 设置密码，然后可以用 id username 查看用户的 UID、GID 和所属组，确认是否成功。如果后续还要让这个用户有管理员权限，需要把它加进 wheel 组或 sudo 组，不同发行版组名不同，执行 usermod -aG wheel username，然后让用户用 sudo -l 验证自己是否有权限。这里我可以多说一句：-aG 的 -a 必须带着，它是追加的意思，如果不带，会把用户从原来所有附属组里移除，只保留你写的这个组，这是新手经常会犯的一个“看起来成功、实际把用户踢走”的错误。
删除用户时用 userdel username 只会删账号，配合 -r 才会把家目录和邮件目录一起清掉。清之前一定要确认这个用户的数据没有保留价值，因为 -r 没有回收站。
3.2 目录的 x 权限为什么总被忽略
Linux 权限是很多刚入门同学觉得最难懂的部分，因为日常处理文件时，大家习惯把注意力放在 r 和 w 上，但目录的 x 权限才是最容易出问题的。目录的 r 权限只代表“能列出目录里的文件名”；目录的 x 权限代表“能不能进入这个目录、能不能访问里面文件的元数据”。一个 644 权限的文件，你理论上有读权限，但如果它所在的目录链路上某一层缺少 x 权限，你依然无法读取。这也是为什么你有时会发现：把文件 chmod 成 777，别人还是访问不了，原因通常出在前面路径上某个目录权限不对。
如果只想让一个文件能被指定用户读取，比较简洁的授权逻辑是：文件本身给 644，目录链路给 755。在多人合作的服务器里，尽量不要用 chmod -R 777 去解决问题，这是把整个安全边界都拆了。正确做法应该是先 chown -R user:group /目标目录 明确归属，再按实际需求给 750 或 755。遇到复杂协作需求，可以考虑 ACL，用 setfacl -m u:someone:rx /目录 精确给某人权限，后续用 getfacl 查看。这个工具前期可以不用，但遇到共享开发机时能省很多事。
3.3 进程是不是真的活着：ps、top 与状态字段
用户建好了、权限也理顺了，接下来日常打交道最多的对象就是进程。看进程最常用的命令是 ps -ef，它会把所有进程都以完整格式列出来，第一列是 UID，第二列是 PID，第三列是 PPID。新手遇到“服务好像没起来”的第一反应是去看端口或日志，但其实 ps -ef | grep 服务名 是最快的定性手段。
top 能显示实时状态，但很多人只盯着 CPU 使用率，忽略了第二、三行的 load average 和进程状态列。进程状态里 D 表示不可中断睡眠，Z 表示僵尸态，R 表示运行中，S 表示睡眠。看到 D 状态的大量进程，先别急着 kill，很可能是磁盘或网络 I/O 卡住了；看到 Z 状态说明子进程已结束但父进程还没回收它。排查僵尸进程时要找的是它的 PPID，不能直接 kill 僵尸进程本身，因为 kill 不掉。用 ps -o pid,ppid,stat,cmd -p 僵尸PID 查出父进程，再判断父进程是否需要重启。当年我第一次处理僵尸进程时一直 kill 子进程，完全没反应，折腾半天才明白方向反了。
4. 远程登录与文件传输：ssh/scp/rsync 的高频配合方式
4.1 ssh：连不上先加 -v，再检查端口与密钥权限
SSH 可能是服务器运维里使用频率最高的命令。最基本的用法是 ssh user@host，如果端口不是默认的 22，需要加 -p 端口号。很多人不知道的是：当我们用密钥登录时，私钥文件的权限必须是 600，即只有当前用户可读写。~/.ssh/id_rsa 权限太宽松的话，ssh 会直接拒绝使用这个密钥，我遇到过不少次“密钥明明没变，客户端却一直要求输密码”的情况，最后发现是复制文件后权限变成了 644。
如果 SSH 连不上，最有用的调试参数是 -v。执行 ssh -v user@host，它会把连接过程中的每一步都打印出来，比如尝试了哪些密钥、服务器返回什么错误、是否被拒绝。看输出会比瞎猜高效很多。登录后如果发现执行命令很卡，可以用 ssh -o ConnectTimeout=5 user@host 控制连接超时，避免长时间挂在等待上。日常如果频繁登录同一台机器，可以在 ~/.ssh/config 里写主机别名，但密码还是要老老实实输入或交给密钥验证。
4.2 scp：单文件快传没问题，批量与增量还是用 rsync
scp 是最直接的文件传输命令，本地传到服务器是 scp 本地文件 user@host:/目标路径/，从服务器拉下来是反过来写。有一个参数细节要注意，scp 指定端口时用的是大写 -P，而 ssh 是小写 -p。我见过很多老手在这两个命令之间切换时突然大意写错，然后报错后再反应一下才意识到大小写问题。
scp 适合小文件和一次性传输。如果文件数量多、体积大，或者希望断点续传，我更推荐 rsync。最常用的写法是 rsync -avz --progress 源路径 user@host:/目标路径/。这里的 -a 是归档模式，保留权限、属主、时间戳；-v 输出过程；-z 压缩传输，网络慢时特别有用；--progress 可以显示进度。如果目标是让两台机器目录完全一致，可以加 --delete，但删除模式非常危险，我建议第一次执行前先加 --dry-run 跑一遍，看看它会删除哪些文件。远程服务器上如果没装 rsync，一般用对应包管理命令装一下就行，源端和目标端都需要有 rsync，这是很多人刚开始没意识到的一点。
4.3 端口到底通没通：ss、curl 和 TCP 探测的组合
远程命令也经常用于排查端口问题。比如你部署了一个 Web 服务，想确认本机端口是否在监听，推荐优先用 ss -tlnp，它会显示监听状态的 TCP 端口和对应进程。老教程里常用 netstat，但不少新系统已经没有 netstat 了，需要额外安装 net-tools，而 ss 默认就有。注意 ss -tlnp 要查看进程名时可能需要 root 权限，所以看到某些进程名显示不出来，先加 sudo 试试。
本机端口确认在监听之后，再用 curl -v http://127.0.0.1:8080/ 验证本地是否能正常响应。curl -v 可以看到完整的 HTTP 请求响应过程，比只看状态码更容易定位问题。如果本机能通，但外部机器访问不通，那就按这个顺序查：先 ping 看网络通不通，再用 telnet 目标IP 端口 或 nc -vz 目标IP 端口 探测端口通不通，最后查防火墙和云平台安全组。这里有一个容易被忽略的点：有些云服务器即使本机防火墙没开，安全组层面也可能把端口挡掉了，这类问题在服务器上怎么敲命令都看不出来。
5. 接手一台新 Linux 机器后，我会先敲的几组体检命令
5.1 先认版本：cat /etc/os-release 比 uname -a 更能确认发型版
很多人拿到一台新机器后，第一件事就是 uname -a 看内核版本。这没问题，但内核版本和发行版是两回事。比如你要装软件，需要知道它是 Debian 系还是 RHEL 系，这时 cat /etc/os-release 是最直接的，它会清楚告诉你发行版名称、版本号和代码名称。uname -a 主要用来看内核版本和架构，比如 x86_64 还是 aarch64，这决定了你下载二进制包时选哪个版本。我犯过的错误就是只看 uname 显示的内核版本，以为系统是某个老版本，结果软件源配置一直不匹配，折腾一圈才发现发行版版本根本不是我以为的那个。
5.2 内存、磁盘、CPU、网卡：用系统自带命令快速摸清机器配置
新机器到手，我习惯按顺序跑几条命令，花几十秒建立一份没有额外安装任何工具的“体检报告”：
free -h：看内存总量和当前使用量，-h用 G/M 显示，比直接看字节友好。df -hT：看分区挂载情况和文件系统类型，一般会确认/分区余量是否充足。lsblk：看块设备、磁盘和分区树状关系，比fdisk -l直观得多。lscpu：查看 CPU 型号、核心数、架构，也能看到各级缓存大小。之前有人问我“Linux 查看 cache 版本”是不是指 CPU 缓存，如果是指硬件缓存信息，lscpu 里那个 Cache 字段就是。ip addr：查看网卡和 IP 地址。注意老系统的ifconfig已经不再是默认工具，建议直接养成用ip命令的习惯。
在这几项基础上，我还会看一眼系统开机时间和负载，命令是 uptime。它的输出很简单，但很有信息量：当前时间、已运行时间、登录用户数、1/5/15 分钟平均负载。刚接手一台机器时，如果 15 分钟负载很高，说明这台机器最近一直有压力，不能只凭当下 load average 低就判断它健康。
5.3 装软件前先分清 apt、dnf、yum：update 与 upgrade 别混着敲
新机器装软件是免不了的，但比“装什么软件”更先要搞清楚的是让哪个包管理器干活。Debian 系装 nginx 是 apt install nginx，RHEL/CentOS 系是 dnf install nginx，老一点可能是 yum install nginx。同一个软件在不同发行版的命令、仓库位置、配置文件路径可能都不一样。拿到机器后第一件事应该是确认发行版，然后再决定用哪套包管理器，这也是我把 cat /etc/os-release 放在体检第一项的原因。
这里特别想提醒刚入门的朋友：apt update 不等于升级软件，它的作用是更新本地的软件包索引，让系统知道仓库里现在有哪些新版本；真正执行版本升级的是 apt upgrade。我看到很多教程里让人“先执行 update 再 install”，真正的原因只是让本地索引是最新的，而不是在装软件前把整个系统升级了一遍。如果用了 dnf/yum，区别同样是 dnf check-update 和 dnf upgrade 要分清。在配置文件里设置 PATH 也常遇到。比如把某个软件装到 /opt/某目录/bin 后，直接执行程序名会提示 command not found，这时候要临时验证可以 export PATH=/opt/某目录/bin:$PATH，想永久生效就把这行写到 ~/.bashrc 文件末尾，再执行 source ~/.bashrc。不理解 PATH 的人会觉得“软件明明装了却不能用”，其实就是 shell 不知道去哪里找这个可执行文件。
6. 服务起不来别乱重启：一次真实的日志排查链路
6.1 先看 systemctl status，再看 journalctl
无论是自己用源码装的 nginx，还是通过包管理器装的服务，只要跑在 systemd 环境下，服务启动失败的排查就有固定套路。不要一上来就反复 systemctl restart，重启只能掩盖问题。正确的第一步是执行 systemctl status 服务名 -l，它会告诉你服务当前状态（active、failed、activating）、主进程 PID、最近一次日志。如果状态是 failed，系统一般会提示你用 journalctl -xe 查看详细错误。journalctl -u 服务名 -n 100 --no-pager 是看指定服务最近 100 行日志的命令，-u 指定 unit，-n 控制行数，--no-pager 避免日志太长进入交互式翻页状态。
我看到不少人一看到 status 里写着 failed，就直接去网上搜“服务 failed 怎么办”，结果浪费大量时间。实际上日志就在手边。比较合理的阅读顺序是：先看 systemctl status 中最底部那几条日志，如果不够清楚，再用 journalctl -u 服务名 -n 200 扩大范围；如果服务有独立的文件日志，比如 nginx 的 /var/log/nginx/error.log，那才是它真正详细记录问题的地方。
6.2 日志文件的“分工”：/var/log 目录里到底记录了什么
服务启动失败时，找日志文件也是一个需要熟悉 Linux 目录习惯的过程。大部分发行版把系统日志放在 /var/log 下，但它们各有分工：messages 或 syslog 记录系统整体消息，auth.log 或 secure 记录认证和登录相关日志，服务自己的日志往往在 /var/log/服务名/ 子目录下。nginx 的访问日志默认是 access.log，错误日志默认是 error.log。Apache 的习惯则可能是 access_log 和 error_log。这些路径在对应服务的配置文件里都可以重新指定，所以配置文件是最终标准，不要凭记忆死背路径。
日志名字里带日期也可能让人觉得混乱。比如某些网络服务会按天切分日志：error.log 是当前正在写的，error.log-20240601 是历史归档。排查问题时优先看当前日志，但如果当前日志一直没内容，有可能时间源不对或者日志轮转配置有问题，这时需要回头检查系统时间，date 命令的结果符不符合直觉。
6.3 一次 nginx 端口被占用问题的完整思考过程
举一个我在真实环境里处理过的问题来收尾。想在一台机器上启动新装的 nginx，执行 systemctl start nginx，结果返回失败。用 systemctl status nginx -l 查看，最下面一行写着：
code复制nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
这时我不应该盲目继续重启，而是先确认 80 端口到底被谁占了。执行 ss -tlnp | grep :80 或 lsof -i :80，看到了另一个服务或旧版 nginx 正在监听。实际情况是机器上原来有一套编译安装的 nginx，systemd 的 nginx 服务启动时当然绑定不到同一个 80 端口。于是我没有强制 kill，而是确认了旧进程的用途。如果旧 nginx 是历史遗留且已被新环境取代，就先把旧服务停止；如果新装的才是多余的那个，就解决新装的配置或端口，把服务的监听端口改成 8080。
这个案例看起来很简单，但代表了一种通用的排查路径：从服务管理工具的状态输出出发，找到具体错误行，再根据错误里的关键词去查相关端口或文件。整个过程其实只用了 systemctl status、journalctl、ss、grep 这几个命令。服务启动类的问题大多不需要重启十几次，真正关键的还是看懂那一条核心错误日志说的是什么。遇到 “Permission denied”，先检查文件所有者；遇到 “No such file or directory”，优先确认路径是否真实存在、是否因为软链失效导致；遇到 “Address already in use”，直接去查端口占用。命令只是工具，顺着日志给出来的方向往下走，排查效率才会真的上来。
根据我自己的经验，Linux 命令的学习最后拼的并不是记忆力，而是遇到错误时能不能把“状态查看、日志定位、进程和端口确认”这一步一步串起来。建议你在自己常用的系统里，把那几个基础命令每种变化都亲手跑一遍，尤其是权限、软链接、日志这些最容易形成肌肉记忆的部分，用熟了之后，服务器出问题的时候才不会慌。