王少冬这次咱们聊 Linux 基础指令第二篇。上一篇我重点讲了 ls、cd、cp、mv、rm 这些刚上手 Linux 一定会碰到的文件操作，算是解决了"怎么在目录里走动、怎么复制删除文件"的问题。这一篇就不一样了，是往深处再走一步：你会创建用户、管权限、翻日志、查进程、传文件、打压缩包，甚至能自己装软件。说直白点，第一篇让你能在 Linux 里活下来，这一篇让你开始像个能用命令行干活的人。
内容我按实际工作中碰到的频率来排，不搞教科书那种枯燥罗列。每个指令我都会说清楚"什么时候用""为什么要这么写""踩过哪些坑"，而不是丢给你一张命令大全然后让你自己背。适合的人群大概是两类：一是刚学完基础操作、想进一步系统掌握运维和开发常用指令的人；二是准备 Linux 面试，发现面试题里总是绕不开用户权限、进程管理、文本处理这些考点的同学。看完这篇，至少再看到 chmod 755、grep -rn、tar -czvf 这种写法，你不会心里发怵。
1. 用户与权限：从建账号到真正看懂 chmod 的数字
1.1 新建用户的完整链路：useradd、usermod、passwd
linux新建用户 这个词能上热搜，说明这是一个高频操作，但很多人卡在第一步：useradd 建完用户之后，发现切不过去，或者没家目录、没 shell，一脸懵。
这里我直接给出一个新手友好、生产环境也能用的建用户套路：
code复制sudo useradd -m -s /bin/bash deploy
sudo passwd deploy
-m 的意思是同时创建家目录（/home/deploy），-s /bin/bash 是指定登录 shell。缺了这两个参数，你建出来的用户可能没有可用的家目录，甚至登录之后直接落到一个奇怪的 shell 里。很多云服务器上默认的 /bin/sh 用起来极不舒服，连命令行补全都没有，别问我是怎么知道的。
建完用户之后，usermod 用来做属性修改。最常见的两个诉求是加用户组和改 shell：
code复制sudo usermod -aG sudo deploy # 将 deploy 加入 sudo 组（不同发行版组名可能不同）
sudo usermod -s /bin/bash deploy
注意 -aG 里的 -a 一定要带。-G 是追加组列表，如果少了 -a，系统会把用户从原有附属组里踢出去，只保留你指定的这个组。我见过有人执行 usermod -G docker 之后，用户突然失去很多权限，排查了半天才发现是 -a 丢了。
passwd 就是设密码。如果你用 su - deploy 切换过去发现输密码老不对，看看是不是之前压根没给这个用户设密码。
1.2 权限三元组：为什么目录默认是 755，文件默认是 644
权限是 Linux 新手最容易绕晕的地方，但理解了就非常简单。一个文件或目录的权限分成三组：属主（u）、属组（g）、其他人（o），每组有读（r=4）、写（w=2）、执行（x=1）三个位。数字相加就得到权限值。
我之前在群里看到有人问，"为什么我 chmod 777 了，网页还是打不开？" 先不说 777 这个权限本身合不合理，他完全没搞明白一个问题：对于目录来说，r 决定能不能列出目录里的文件名，x 决定能不能进入这个目录，w 决定能不能在目录里新建/删除文件。所以如果你只想让别人能进目录看文件，至少需要 r-x，也就是 5，而不是只给一个 r。
我用一张表把常用权限组合记一下：
| 数字 | 权限组合 | 针对文件 | 针对目录 |
|---|---|---|---|
| 4 | r-- | 可读内容 | 仅可列出文件名 |
| 5 | r-x | 可读可执行 | 可进目录可列名 |
| 6 | rw- | 可读可写 | 可改名可增删文件（但没有进入和列出的配合会很怪） |
| 7 | rwx | 完全控制 | 完全控制 |
系统默认不让普通用户建出来的文件带执行权限，所以默认文件是 644，目录是 755。这个逻辑是：文件默认要能被读，但不要莫名其妙能被执行；目录要开放进入和列出，否则没法用。
1.3 chown 与 chmod 的配合：把网站目录交给指定用户
真实场景里，你不可能永远用 root 跑所有服务。更常见的做法是：建一个专门用户，把某个目录的属主改成它，然后再调权限。
比如我现在要把 /var/www/html 交给 deploy 用户管理：
code复制sudo chown -R deploy:deploy /var/www/html
sudo chmod -R 755 /var/www/html
-R 表示递归。注意 chown 这里同时改了属主和属组，中间是冒号分隔，写作 deploy:deploy。有些老教程用点 . 分隔，在多数 Linux 发行版里也能识别，但我还是建议用冒号，兼容性更好。
一个经常被忽略的细节：权限设置不能只看当前用户有没有权限，还要看这个用户能不能"走到"目录的每一级路径。比如 /home/deploy/project，deploy 用户要访问 project，前提是他能进入 /home（一般是 755）、能进入 /home/deploy（也是 755），否则里面东西设成 777 都没用。这个"路径穿透"概念，排查权限问题时特别重要。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 文件搜索与文本处理：日志排障时最顶用的组合拳
2.1 find：为什么它比文件管理器里翻快一百倍
find 是服务器上找文件的终极工具。它的基本语法是 find 路径 条件，听起来简单，但条件组合起来非常强大。
我平时用得最多的几种写法：
code复制find /var/log -name "*.log" -mtime -7 # 找 7 天内改过的日志
find /etc -type f -name "*.conf" # 找 /etc 下所有 .conf 文件
find / -type d -name "nginx" 2>/dev/null # 全盘找 nginx 目录，错误信息丢到黑洞
-mtime -7 表示修改时间在 7 天以内；+7 表示 7 天之前。这个符号有时候会搞混，我自己的记忆方式是：- 表示"小于"，+ 表示"大于"，时间单位是天。
再说一个生产环境很实用的组合：找到文件之后立刻删除或执行命令。常见做法是配合 -exec，但很多人不注意写法：
code复制find /tmp -name "*.tmp" -exec rm {} \;
末尾的 {} 是当前找到的文件名，\; 表示命令结束。每次看到这个反斜杠分号我都会强调：千万别漏了。漏了之后 find 会继续把后面的内容当成更多条件，报错倒是小事，删文件没删全才是麻烦。
我在实际项目里其实更习惯用 find ... | xargs ... 的方式，比如：
code复制find /tmp -name "*.tmp" | xargs rm -f
xargs 会把前一条命令的输出按行转成后一条命令的参数。两者区别在于：-exec 每查到一个文件就执行一次，慢且损耗大；xargs 是攒一批参数一次执行，效率高很多。不过 xargs 对文件名里带空格的情况处理不太友好，需要配合 -print0 和 xargs -0 来用，这就属于进阶细节了，日常处理服务器日志文件，默认的 xargs 够用。
2.2 grep：从几千行日志里捞出你要的那一行
grep 是文本检索的瑞士军刀。基础用法是 grep 关键词 文件，但真正干活时你会发现远远不够。
先说最刚需的递归搜索。你想在项目代码里找某个函数在哪里被调用过：
code复制grep -rn "getUserInfo" /home/deploy/project/src
-r 是递归，-n 是显示行号。用 --include 可以只搜特定类型文件：
code复制grep -rn --include="*.js" --include="*.ts" "getUserInfo" src/
排查日志的时候，-v 排除干扰项也极其常用。比如你看 nginx 报错日志，想排除健康检查的请求：
code复制grep -v "healthcheck" /var/log/nginx/error.log
再加一个 -i 忽略大小写，grep -iv "healthcheck" 连 HEALTHCHECK 这种写法也一起排掉。
还有一个我踩过的坑，在部署脚本里判断上一条命令是否成功，经常会用：
code复制if echo "$output" | grep -q "success"; then
echo "部署成功"
fi
-q 是 quiet 模式，不输出匹配内容，只返回退出码。这个模式在脚本里特别关键，因为如果你不写 -q，grep 找到的内容会全部打印，打日志的时候容易被刷屏。而在 if 条件里，grep 没有匹配返回非 0 退出码，if 判断为假，这个逻辑也要熟。
2.3 sed 和 awk：改文件、抽列，不用写脚本也能批量处理
sed 是一个流编辑器，在不打开文件的情况下做文本替换。最常用的替换命令：
code复制sed -i 's/old_string/new_string/g' config.txt
-i 表示直接修改原文件，g 是全局替换。很多新手第一次执行不加 -i，看完发现文件没变，还以为 sed 没用，其实是没写 -i。
但是 -i 也有风险，我自己的习惯是替换前先备份：
code复制sed -i.bak 's/old/new/g' config.txt
这样改错了还能从 config.txt.bak 恢复。这个习惯在线上环境救过我一次，当时把数据库配置里的 host 写错了，执行完发现连不上，还好有 .bak 文件，一条 cp 命令就还原了。
awk 的强大之处在于按列处理。最经典的是配合 ps 或 df 取特定列：
code复制ps aux | awk '{print $2}' # 提取 PID 这一列
df -h | awk 'NR>1 {print $5}' # 跳过第一行表头，提取磁盘使用率
$2 表示第 2 列，$0 表示整行。-F 参数可以指定分隔符，比如处理以冒号分隔的 /etc/passwd：
code复制awk -F: '{print $1}' /etc/passwd # 取出所有用户名
awk 真的是一门小型编程语言，日常工作中不需要你精通全部语法，但掌握列提取、条件和简单统计，已经能让效率翻倍。比如统计日志里某个接口被调用了多少次：
code复制grep "api/order/list" access.log | awk '{print $1}' | sort | uniq -c
这就是一个典型的组合命令，把日志里所有调用该接口的 IP 拿出来，排序后按 IP 统计次数。sort | uniq -c 这两个配套命令是统计场景的神器，uniq -c 在去重的同时还能加计数，但前提是必须先用 sort 排序，否则重复项不相邻，计数就不准。这个坑我也踩过。
3. 进程与系统资源：服务器变慢时我在敲什么
3.1 top、free、df：先看清系统到底发生了什么
服务器卡了，第一反应不是重启，而是先看状态。top 是最直观的监控命令，打开之后是一个实时刷新的进程列表，按 M 键可以按内存排序，按 P 键按 CPU 排序，q 退出。
很多人看 top 只看 CPU 百分比，这是不够的。你要重点关注三行信息：
load average后面的三个数字，分别是 1 分钟、5 分钟、15 分钟的负载。如果 1 分钟负载明显高于 15 分钟，说明系统刚刚开始变忙。%Cpu(s)里的us（用户态 CPU）和sy（系统态 CPU）占用比例。如果sy特别高，可能是频繁的系统调用，或者有进程在疯狂读写。- 进程列表里
RES列是进程实际占用的物理内存，不是VIRT那个虚拟内存。我看到过有人把 VIRT 几百 GB 当成内存泄漏，其实虚拟内存包含共享库映射，不代表真实的物理占用。
内存看 free -h，重点看 available 那一列，它比 free 列更能反映真实可用内存，因为 available 考虑了缓存可以回收的部分。
磁盘看 df -h，如果有分区使用率到 90% 以上，基本就要注意了。日志爆盘是导致系统异常最常见的原因之一。
3.2 杀进程的正确姿势：kill -15 还是 kill -9
杀进程是很多人不敢碰的操作，特别是生产环境。但只要你理解了信号机制，就知道什么时候能用什么。
kill 默认发的是 SIGTERM（15），这是"请正常退出"的意思。进程收到后可以做清理工作，比如释放端口、保存状态。kill -9 发的是 SIGKILL，内核直接强制终止，进程没有机会做任何善后。
我的建议是：优先 kill 不带参数，实在不行再 kill -9。比如你启动了一个 java 服务，直接 kill -9 可能把当前正在写入的数据弄丢，或者留下一些垃圾临时文件。
查看进程 PID 最常用的命令是 ps aux | grep 关键词，看到 PID 之后再用 kill。还有一个更省事的写法：
code复制pkill -f nginx.conf
pkill -f 匹配完整命令行，可以精准杀掉带有特定参数的进程。这个指令方便但也要小心，关键字写宽了容易误杀其他进程。比如你在服务器上执行 pkill -f tmp，可能把所有命令行里带 tmp 的进程全杀了。
补充一个经常被面试官问的信号知识：kill -l 可以列出所有信号，常用的除了 15 和 9，还有一个 SIGHUP（1），很多服务（比如 nginx）收到它之后会重新加载配置文件而不停止服务，也就是 kill -HUP $(cat /var/run/nginx.pid) 这种写法会触发 reload。但现在我们一般用 nginx -s reload，更可控。
3.3 systemctl 与 journalctl：现代服务管理的基本盘
现在的主流发行版都用 systemd 管理服务，所以 systemctl 成了服务管理最重要的命令。
code复制systemctl start nginx # 启动服务
systemctl stop nginx # 停止服务
systemctl restart nginx # 重启服务
systemctl enable nginx # 设置开机自启
systemctl status nginx # 查看状态
这里要特别提醒：enable 和 start 是两码事，很多人混着用。start 是立即启动，enable 是设置开机启动。如果只是 start 没 enable，机器重启后服务就没了。反过来，enable 只改了开机配置，如果当前服务没跑起来，你还需要手动 start。
看服务日志的指令是 journalctl：
code复制journalctl -u nginx -f # 跟踪 nginx 服务的实时日志
journalctl -u nginx --since "1 hour ago" # 查看最近一小时的日志
-f 是 follow 模式，跟 tail -f 一个效果。排查启动失败的时候，systemctl status 只显示最后几行日志，很多时候不能定位问题，你必须用 journalctl 看完整日志。就像你看到一个服务一直处于 failed 状态，光看 status 是发现不了端口被占用这种问题的，journalctl -u 服务名 里才会直接提示 Address already in use。
4. 网络与文件传输：连接不畅和跨机器传文件的基本解决路径
4.1 端口和连接状态：ss、netstat 该用哪个
排查网络问题，第一步先是确认端口有没有监听、连接建立没建立。老一代的命令是 netstat，新一代是 ss，但很多系统默认可能没有装 netstat，所以我建议你直接习惯用 ss。
code复制ss -tlnp
这个命令的参数含义：-t 只显示 TCP，-l 只看监听状态的端口，-n 不做域名解析（显示 IP 而不是主机名，速度快很多），-p 显示对应的进程 PID 和名称。这四条组合起来，就是"看哪个端口被哪个进程占着"。
我在部署服务时最常见的报错就是端口被占用，用这条命令可以直接找到元凶：
code复制ss -tlnp | grep 8080
结果里会显示 users:(("java",pid=12345,fd=101)) 这种格式，说明 PID 12345 的 java 进程占用了 8080。知道 PID 之后，你可以用 ps aux | grep 12345 或者 ls -l /proc/12345/cwd 去看这个进程是从哪个目录启动的，非常有用。
如果你只是想看这台机器对外建立了多少连接，可以用 ss -s，它会输出一个汇总，包括 total、established、time_wait 等统计。这个命令在排查连接数打满的问题时很直观。
4.2 scp 和 rsync：文件传输的两种思路
跨机器传文件是运维和开发都躲不开的需求。我的选择很简单：文件小、一次性传，用 scp；文件多、频繁同步、需要增量，用 rsync。
scp 的用法和 cp 很像，只是目标变成了远程地址：
code复制scp ./app.jar deploy@192.168.1.10:/home/deploy/app/
scp -r ./config/ deploy@192.168.1.10:/home/deploy/config/
-r 表示传目录。如果你改了 ssh 默认端口（比如 2222），需要用 -P 2222，注意是大写的 P，小写 -p 在 scp 里是保留时间戳的意思，两个搞混了会报错，这也是一个常见坑。
scp 是完整复制，每次都要传全部文件。如果你的项目有大量静态资源只是小改动，继续用 scp 效率就很低。rsync 可以只传变化的部分：
code复制rsync -avzP ./dist/ deploy@192.168.1.10:/home/deploy/www/
参数说明：-a 归档模式，保留权限、时间戳等元信息；-v 显示过程；-z 传输时压缩；-P 是 --partial --progress 的组合，支持断点续传同时显示进度。这个组合基本是 rsync 传文件的标准姿势。
-P 的断点续传能力在弱网环境特别有用。传一个大文件传到一半断了，重新执行同一条命令，rsync 会自动从断点继续，而 scp 会从头再来。另外，rsync 在目录尾部斜杠的处理上也有讲究：rsync -av dir/ target/ 和 rsync -av dir target/ 结果不一样，前者是同步 dir 里的内容到 target，后者是同步 dir 目录本身。我建议新手每次写 rsync 命令前先想清楚目录层级，否则很容易把文件传到多一层目录里去。
4.3 接口调试与下载：curl 和 wget 各有所长
wget 和 curl 都能做下载，但 curl 在接口调试上更灵活，wget 在批量下载和递归抓取上更强。日常我用 curl 更多。
code复制curl -I https://example.com # 只查看响应头
curl -X POST -H "Content-Type: application/json" \
-d '{"key":"value"}' https://example.com/api
curl -o /dev/null -s -w "%{http_code}\n" https://example.com # 只输出状态码
-I 发 HEAD 请求，拿响应头，常用于确认服务有没有正常响应。-X POST 指定方法，-d 传请求体，-H 指定请求头，这是后端联调最常用的组合。最后一个写法很实用，只输出 HTTP 状态码，脚本里做健康检查会用到。
wget 最常用的场景是下载安装包：
code复制wget -c https://example.com/large-file.tar.gz
-c 是断点续传。如果你在下载大文件时网络断了，重新执行一次会从断点继续，不用重来。下载时如果目标是 https 且有证书问题，可以用 --no-check-certificate 临时忽略证书校验，但要注意这会让连接的安全性降级，只建议在测试环境用。
这里还要提一个非常常见的排查场景：服务器访问外网超时。很多人上来就 ping，但 ping 走的是 ICMP 协议，很多云厂商默认禁 ping。更靠谱的联通性测试是 curl -I 一个已知站点，看能不能拿到响应。如果 curl 都超时，再查 DNS、查路由、查防火墙，一步步缩小范围。
5. 压缩归档与软件安装：让环境“搬得走、装得快”
5.1 tar 的常用组合与解压避坑
tar 最初是"磁带归档"的缩写，现在成了 Linux 上打包压缩的标准工具。它的参数组合很固定，我每次看到那些一长串 tar -czvf 就头大，但拆开来看其实很简单：
code复制tar -czvf app.tar.gz ./app/
tar -xzvf app.tar.gz
c创建归档（create）x解压提取（extract）z使用 gzip 压缩（如果是 .tar.gz 文件必须带，.tar 文件不带）v显示过程（verbose），不想刷屏可以去掉f后面跟文件名，-f必须是最后一个参数，因为它后面要直接接文件名
所以 -czvf 就是一个"使用 gzip 压缩、显示过程、创建归档文件"的组合。解压时把 c 换成 x，就是 -xzvf。
解压前想先看看里面有什么，不实际解开，用：
code复制tar -tzvf app.tar.gz
-t 是列出内容列表。这个习惯非常有用，我见过有人解压之后发现把一堆文件全部散落在当前目录，而不是在一个统一目录下，清理起来很痛苦。先看列表确认是有一个顶层目录还是散装文件，再决定在当前目录直接解压还是新建目录解压。
还有一个很经典的坑：.tar.gz 解压出来如果是相对路径，比如 ./etc/nginx.conf，它会直接覆盖你当前目录下的 etc/nginx/nginx.conf。这种带着相对路径的压缩包在解压时要特别小心。稳妥做法是解压到一个空目录里，先观察内容，再决定怎么处理。
5.2 包管理器：apt、yum、dnf 的差别和使用习惯
Linux 下装软件最省事的方式是走包管理器，它类似手机上的应用商店，会自动处理依赖关系。
Debian/Ubuntu 系列用 apt，RedHat/CentOS 系列以前用 yum，现在新版用 dnf。它们的核心用法几乎一致：
code复制sudo apt update # 更新软件源索引，不是升级软件
sudo apt install nginx # 安装软件
sudo apt remove nginx # 卸载软件
sudo apt upgrade # 升级所有可升级的软件包
这里我想强调一个高频误区：update 不等于 upgrade。update 只是把软件源里的索引列表拉到本机，它不会动你系统里任何已安装的软件。真正的升级是 upgrade。有些人安装软件之前不执行 update，结果报"找不到软件包"，大概率就是本地索引太旧，不知道源里已经有这个新版本了。
包管理器最怕的是依赖冲突。你手动下载了一个 .deb 或 .rpm 包，安装时提示缺少这个东西那个东西，这种被称为"依赖地狱"。应对方式一个是尽量用官方源，少从乱七八糟的网站下载手动包；另一个是如果必须手动装，先检查装上之后缺哪些依赖，单独补装，再回来装主包。
软件源配置也是一个重点。国内服务器访问官方源常常很慢，解决办法是换成国内镜像源。这个操作分布在 /etc/apt/sources.list 或 /etc/yum.repos.d/ 目录里，换源以后一定记得重新执行 update 让索引生效。
5.3 软链接和硬链接：看似简单但经常有人搞混
ln 是创建链接的命令。软链接（符号链接）类似 Windows 的快捷方式，硬链接则是对文件数据本身的另一个引用。这个区别面试经常问，实际操作中也经常遇到。
code复制ln -s /usr/local/nginx/conf/nginx.conf /etc/nginx.conf # 软链接
ln /usr/local/nginx/conf/nginx.conf /etc/nginx.conf.bak # 硬链接
软链接带 -s，更常用。它跨文件系统、跨目录都能建，删除原文件后，软链接就变成"悬空"状态，指向一个不存在的路径。
硬链接不带 -s，本质是同一个文件数据的多个名字。硬链接有几个限制：不能跨文件系统，不能对目录创建（一般不允许），删除其中一个链接不会影响另一个，因为引用计数还在。
实际排障中，有一个和软链接相关的经典坑：nginx 配置改了，reload 之后不生效。排查半天发现 /etc/nginx/nginx.conf 是软链接，vi 保存的时候由于编辑器的工作方式，把软链接删掉重建了一个普通文件，新的内容写到了新文件里，而 nginx 实际读取的还是原文件。所以修改软链接指向的文件时，要么用 sed -i，要么用 vim 的时候留意保存方式，别把软链接本身覆盖掉。
6. 内容再进阶一步：alias、history、man 三件套，日常效率翻倍
写到这里，基础指令的主体已经覆盖得差不多了，但我想额外补充几个不太起眼、却能极大提升命令行使用体验的"习惯性指令"。它们不属于某一类操作，而是贯穿在所有指令使用过程中的小工具。
6.1 alias：把长命令变成短口令
alias 是给命令起别名的功能。我每上新环境必配两个：
code复制alias ll='ls -alF'
alias grep='grep --color=auto'
ll 不是 Linux 原生自带的命令，它其实是很多发行版默认配置好的 alias。如果你换到一个精简环境发现 ll 报 command not found，不用慌，就是这个原因。grep --color=auto 会把匹配到的关键字标红，看大日志的时候非常提神。
想让 alias 永久生效，写进 ~/.bashrc 文件，然后执行 source ~/.bashrc 让它立刻生效。
我建议每个人都把自己的高频长命令做成 alias。比如我最常用的部署命令是 rsync 同步代码，我配了一个：
code复制alias dep='rsync -avzP --delete ./dist/ deploy@192.168.1.10:/home/deploy/www/'
--delete 会删除目标目录里多余的文件，让两边完全一致。日常使用 alias 的本质是减少重复劳动，但这个操作也有风险——--delete 配错源目录和目标目录后果很严重，所以 alias 里的命令一定要反复确认，尤其是涉及删除操作的。
6.2 history：找回你刚才到底执行了什么
history 列出当前 shell 的历史命令。排查问题的时候经常会碰到"我刚才到底执行了什么指令导致现在这么奇怪"的窘境，这时候 history 能救你。
更高效的是 Ctrl + R 反向搜索历史命令。按下 Ctrl + R，输入关键字，shell 会从最近的历史命令里往回匹配。匹配到之后按回车直接执行，按 Ctrl + R 继续往上翻。这个快捷键用熟了之后，几乎不会再重复敲很长很长的命令。
history 和 grep 配合还可以做审计：
code复制history | grep "rm -rf"
看看你哪天执行过删除操作，在多人共用的服务器上也能辅助定位问题。
6.3 man：每个指令的官方说明书
man 是 manual 的缩写，查看命令的帮助文档。man ls、man tar，进去之后是完整的手册，按 q 退出，按 / 搜索关键字。
很多新手一看到 man 出来的英文文档就头大，宁愿去百度查。但我的真实经验是，man 是准确性最高的信息来源，网上很多教程是互相抄的，抄着抄着就错了。比如某个参数在发行版 A 和发行版 B 上的行为不一样，网上教程不会帮你区分，man 会。
如果 man 的内容太多看不进去，我的建议是先记 --help：
code复制tar --help
几乎所有 GNU 工具都支持 --help，输出的是精简版参数说明。这种"先 --help 再 man"的路径，帮你快速定位参数，又不至于被长篇大论淹没。
7. 写在最后：请你务必动手，而不是只看
我一直觉得 Linux 指令这种东西，"看过"和"会了"之间差着十万八千里。你可以在虚拟机里开一个 Ubuntu，把上面这些命令挨个敲一遍，不需要刻意去背，只要每个命令你都亲手试过一次、看过它的输出、故意制造过一次报错并解决了它，你就已经比很多纸上谈兵的教程党强了。
这里再分享一个我的排查习惯：任何命令在执行之前，如果它带了删除、覆盖、修改权限这类"不可逆操作"，我都会先把命令写出来，自己盯三秒，确认路径没错、参数没错、作用对象没错，再按回车。在 root 下操作尤其如此。这个习惯帮我避免了至少三次灾难性的 rm -rf 误删。
还有一个小贴士：尽量不要自己在多个环境里用不同的命令习惯，而是统一一套。比如在所有服务器上，我都会优先用 ss 而不是 netstat，优先用 rsync 而不是 scp，因为统一能让你的肌肉记忆更可靠，排查问题时会条件反射般敲出正确命令。Linux 的世界不是比谁背的命令多，而是比谁在关键时刻能找到对的那一条，并且用得足够稳。