1. 这份命令集合是怎么来的
用过几年 Linux 的朋友都会有这种感觉：真正让你记住一条命令的，不是翻手册背参数，而是某个深夜线上出问题、或者日常操作里反复踩坑之后，你把它记进了自己的小本子。我这份 Linux 常用命令集合就是这么积累起来的，从最初只会lscd的懵懂期，到后来能熟练处理权限、排查进程、分析日志，每一类命令背后都有具体的场景在推着我去学。
这份集合适合谁？我觉得是两类人。一类是刚接触 Linux 的初学者，你需要一份“能直接照着敲”的清单，而不是那种把几百个参数全列出来、看完更懵的文档；另一类是已经会用 Linux、但希望查漏补缺的开发者或运维，日常写脚本、排查服务器问题时，这份集合能帮你把高频操作沉淀成肌肉记忆。
我整理的原则也很简单：只收日常使用频率最高的命令，每个命令都配上我实际用过的场景，而不是把man手册搬过来。遇到参数记不清的，先看这篇，解决不了再查手册。文章会持续更新，我在实际工作中捡到好用的用法，就往上补。
2. 文件与目录操作：每天敲得最多的命令
2.1 ls、cd、pwd：看似简单，细节不少
ls大概是每个 Linux 用户敲的第一条命令，但很多人一直停留在ls和ls -l的水平上。我最常用的几个变体：
ls -lah # 列出所有文件（含隐藏文件），带单位显示大小 ls -lt # 按修改时间倒序排列，找最近改过的文件很好用 ls -l --time-style=+'%Y-%m-%d %H:%M:%S' # 让时间显示成人能看懂的样子-h这个参数我建议养成肌肉记忆，没有它你会看到一堆 4096、1048576 这种数字，得自己在脑子里除以 1024，纯属浪费精力。-t在排查“我刚改的文件去哪了”这种问题时特别有用，配合head使用：ls -lt | head -20，最新改动的 20 个文件一目了然。
cd也有几个容易被忽略的用法：
cd - # 回到上一次所在的目录 cd ~ # 回到用户主目录 cd ../.. # 向上跳两级cd -是个冷门但高效的操作，在两个目录之间来回切换时，省得一次次敲完整路径。pwd没有太多花样，唯一要留意的是pwd -P，在符号链接目录里它能显示真实物理路径，不会让你被软链接“骗”了。我曾经排查一个部署脚本问题，脚本里写的路径一直对不上，最后才发现是软链接导致的，pwd -P一下就看穿了。
2.2 cp、mv、rm：操作之前先想清楚
这三个命令是误操作重灾区，尤其rm。先说cp：
cp file1 file2 # 基本复制 cp -r dir1 dir2 # 递归复制目录 cp -a dir1 dir2 # 递归复制并保留权限、时间戳等属性 cp file{1,2,3}.txt dir/ # 一次复制多个文件-a这个参数我在备份目录时必用，它等于-dR --preserve=all，能把所有者、权限、时间戳、符号链接全部保留下来。你要是直接cp -r拷目录再拿去线上部署，很可能发现文件权限变了、程序跑不起来，那就是没加-a的锅。
mv有个坑很多人没意识到：跨文件系统移动文件时，它不是简单的“移动”，而是“复制+删除”，大文件会明显变慢。所以mv之前最好确认源和目标在不在同一个分区，用df看一眼挂载点就行。另外mv有个隐藏的“防覆盖”技巧：
mv -i source dest # 目标存在时询问是否覆盖 mv -n source dest # 目标存在时直接跳过这两个参数配在 alias 里很合适，能防止你稀里糊涂把同名文件覆盖了。
rm必须单独说。我见过太多人rm -rf酿成事故，甚至有人把系统目录删了直接重装。我的习惯是：
rm -i file # 删除前确认 rm -r dir # 删除目录，不加 -f能不加-f就不加，让系统给你一个确认的机会。真正到了必须rm -rf的场景，敲命令前先pwd确认自己在哪，再ls确认要删的东西存在、且路径没写错。如果你删的是大量历史文件，可以考虑先mv到一个临时目录，过几天确认没问题再真删除，给自己留条后路。
2.3 find 与 locate：找文件的两个思路
find是找文件的正统工具，功能强大但参数多，我只记几个高频用法：
find . -name "*.log" # 按名称查找 find /var/log -mtime -7 # 查找7天内修改过的文件 find . -size +100M # 查找大于100MB的文件 find . -type f -name "*.conf" -exec sed -i 's/old/new/g' {} \;最后这个-exec组合技非常实用，比如批量替换配置文件里的 IP 地址，find先筛出目标文件，sed再批量改内容，一条命令搞定原本要写循环的活儿。不过用-exec时千万注意{} \;这个格式，分号前必须加反斜杠转义，写错了命令直接报错或者行为诡异。
locate是另一种思路，基于数据库快速查找，比find快得多，但数据库不是实时更新的，刚创建的文件locate可能找不到。新装系统后要先updatedb建索引才能用。我的经验是：找已知文件名的历史文件用locate，找需要按条件筛选的文件用find，两者互补。
3. 文本处理三剑客：grep、sed、awk
3.1 grep：从日志里捞出关键信息
排查线上问题的时候，grep是第一个上场的。我最常用的组合：
grep "ERROR" app.log # 基础查找 grep -r "关键字" /opt/app/config/ # 递归查找目录下所有文件 grep -v "DEBUG" app.log # 反向匹配，过滤掉不想要的 grep -c "ERROR" app.log # 只统计行数 grep -n "ERROR" app.log # 显示行号 grep -E "ERROR|WARN" app.log # 扩展正则，匹配多个关键字日志分析时我特别推荐grep -C 5 "ERROR" app.log，-C 5表示同时显示匹配行的前后 5 行上下文。光看一行 ERROR 往往看不出问题，前后几行上下文能让你快速定位是哪个模块、什么条件下出的错，省得反复翻日志。
grep有个容易被忽略的细节是处理二进制文件。默认情况下 grep 遇到二进制文件会提示Binary file xxx matches，这时加-a参数把二进制文件当文本处理，能直接看到匹配内容。另外日常排查日志时建议加上--color=auto，匹配内容高亮显示，眼睛会轻松很多。
3.2 sed：流式编辑的实用场景
sed看起来语法别扭，但真正用熟之后效率极高。我不建议一开始就啃它的高级功能，先掌握三个场景就够用了：
sed -i 's/旧文本/新文本/g' file.txt # 全局替换 sed -i 's/192.168.1.100/192.168.1.200/g' config.conf sed -n '10,20p' file.txt # 只查看第10到20行 sed -i '/pattern/d' file.txt # 删除包含pattern的行-i是直接修改原文件，不加-i只是把结果输出到屏幕。这个参数我第一次用的时候吃过亏：写了个替换命令，结果屏幕上的输出是正确的，但文件根本没变，后来才反应过来忘了加-i。另外用-i之前建议先备份或者先在屏幕上预览一次结果，确认无误再真正落盘。
sed的查找替换功能在批量改配置文件时是救命的。比如几十个配置文件里都要换数据库地址，手改要半小时，sed -i一条命令几秒钟完成。它配合find一起用效果更佳，我前面提到的find -exec sed组合就是这个思路。
3.3 awk：列处理的灵魂工具
awk是文本处理三剑客里最强大的一个，它的核心思想是“按列处理文本”。最常用的场景：
awk '{print $1}' file.txt # 打印第一列 awk '{print $1, $3}' file.txt # 打印多列 awk -F: '{print $1}' /etc/passwd # 指定冒号作为分隔符 awk '{sum += $1} END {print sum}' numbers.txt # 对第一列求和-F指定分隔符是个关键参数。处理/etc/passwd这种用冒号分隔的配置文件时，默认空格分隔会完全失效，必须显式指定。默认分隔符是空格（连续多个空格会被当成一个），但如果是 Tab 分隔的文件，需要-F'\t'。
awk的$0表示整行，$1、$2表示第几列，NF表示当前行的列数，NR表示当前行号。这几个内置变量理解了，大部分统计需求都能解决。比如：
awk 'NR > 1 {print}' data.csv # 跳过表头，从第2行开始输出 awk '{print NF, $0}' file.txt # 每行前面打印列数我在统计访问日志时常用一个组合：awk '{print $9}' access.log | sort | uniq -c | sort -rn，这条管道能把日志里 HTTP 状态码的出现次数统计出来并按降序排列，快速判断有没有大量 5xx 错误。这其实也印证了文本处理命令的价值：单独的 grep、awk 各自能干活，但组合成管道才能真正发挥威力。
3.4 组合使用：管道链才是王道
单独用某个命令很简单，真正体现效率的是把它们串成管道。我实际工作中高频使用这几个组合：
history | grep "git" # 历史记录里找用过的命令 cat app.log | grep "ERROR" | awk '{print $2}' | sort | uniq -c tail -f app.log | grep "exception" # 实时跟踪日志并过滤关键字tail -f加grep这个组合是我定位线上问题的最爱。日志持续输出，我只想看包含关键字的行，一条命令就能实时过滤。需要注意管道符两边的命令都会开一个新的子进程，如果管道链中间某个命令崩了，整条链路可能异常退出。另外涉及编码时要注意，某些日志文件是 GBK 编码，管道处理前可能要先转码，不然中文全是乱码。
4. 权限与用户管理：别让服务器裸奔
4.1 chmod 与 chown：先搞懂权限的本质
Linux 权限体系说起来就三件事：读（r）、写（w）、执行（x），分别对应用户（u）、用户组（g）、其他人（o）。chmod有两种书写方式，我建议都掌握：
chmod 755 script.sh # 数字方式：rwxr-xr-x chmod u+x script.sh # 符号方式：给所有者增加执行权限 chmod -R 755 /opt/app/ # 递归修改目录下所有文件数字方式的基础是：r=4，w=2，x=1，三者相加得到一组的权限值。755 就是所有者 7（rwx）、组 5（r-x）、其他人 5（r-x）。这个转换要熟练，因为很多文档和教程里的权限都写成数字形式，你不能每次都在脑子里现算。
一个常被忽视的细节是目录的权限含义。目录的“执行权限”代表能否进入该目录，没有 x 权限的目录即使有 r 权限也进不去、列不出来。所以你会看到配置文件通常要求目录是 755、文件是 644，脚本是 755，这些都是实践中沉淀下来的安全默认值。
chown用来改文件的所有者和组：
chown user:group file.txt # 同时修改所有者和组 chown -R user:group /opt/app/ # 递归修改部署应用时最常见的错误就是文件所有者不对，导致程序写不了日志或者读不了配置。我每次把文件从开发机传到服务器后，都会顺手chown到应用运行账号，否则后面排查权限问题能折腾半小时。
4.2 useradd、passwd、usermod：用户管理的日常
新建用户的常规操作：
useradd -m -s /bin/bash newuser # 创建用户并建立主目录、指定shell passwd newuser # 设置密码 usermod -aG sudo newuser # 将用户加入sudo组（Debian系） userdel -r newuser # 删除用户并删除其主目录-m参数自动创建用户主目录，不加的话用户可能连cd ~都进不去。-G追加所属组时我习惯加-a参数，表示追加而不是覆盖，不加-a会把用户已有的其他组全部清掉，这个坑我踩过一次，当时差点把用户的权限搞乱。
Ubuntu 和 CentOS 还有一个差异：Ubuntu 里useradd和adduser是两个不同命令，前者是原生工具、后者是封装脚本；CentOS 里两者基本等价。初学者建议用adduser（交互式）一步步操作，不容易出错。用户创建完务必要passwd设置密码，否则账户处于锁定状态没法登录。
4.3 sudo 配置：给谁多少权限要算清楚
sudo的核心配置文件是/etc/sudoers，修改它必须通过visudo命令，因为visudo在保存前会做语法检查，防止你把文件改坏了导致sudo完全不可用。
# 给指定用户所有命令权限 username ALL=(ALL:ALL) ALL # 给指定用户组所有命令权限 %sudo ALL=(ALL:ALL) ALL # 允许用户无需密码执行sudo username ALL=(ALL) NOPASSWD: ALL最后这个NOPASSWD: ALL我建议谨慎使用。服务器上确实为了方便给过某些服务账号免密 sudo，但一旦账号被入侵，攻击者就能直接拿到 root 权限。折中的方案是只对特定命令免密，比如：
username ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx这样用户能免密重启 Nginx，但做不了别的管理员操作。日常工作里权限分配宁紧勿松，多花一分钟想清楚该给什么权限，比出事之后花一小时补救划算得多。
5. 进程与资源监控：排查问题的主战场
5.1 ps、top、htop：看进程的三种姿势
ps是静态快照，top是动态刷新，两者配合能解决大部分进程排查需求：
ps aux # 查看所有进程的完整信息 ps aux | grep "java" # 过滤特定进程 ps -ef --forest # 以树状结构显示父子进程关系 top # 实时刷新，按CPU使用率排序ps aux的输出列很多人记不住含义，关键几列是：USER（运行用户）、PID（进程号）、%CPU（CPU占用率）、%MEM（内存占用率）、STAT（进程状态）、COMMAND（启动命令）。STAT 里的R是运行中，S是睡眠（可中断），D是不可中断睡眠，Z是僵尸进程。看到Z就要注意了，说明父进程没回收子进程。
top进去之后有几个交互按键要记住：1看每个CPU核心的负载，M按内存排序，P按CPU排序，q退出。生产环境上我一般直接top -c，把完整的命令行显示出来，否则一堆进程编译成一行简写，根本分辨不出是哪个程序。
如果你有htop，体验会更好，彩色显示、可鼠标操作、树状视图更直观。大多数发行版需要自己装：apt install htop或yum install htop。个人经验：快速判断“机器是不是有问题”用top就够了，深入排查单个进程建议htop直接按 F6 筛选。
5.2 kill、pkill、killall：终止进程的完整方案
很多新手以为kill就是杀进程，实际上kill的本质是发送信号，默认发的是 SIGTERM（15），让进程自己清理退出。只有进程不响应时，才需要强制信号：
kill 1234 # 发送SIGTERM，礼貌地请进程退出 kill -9 1234 # 发送SIGKILL，强制杀死 kill -15 1234 # 明确发送SIGTERM pkill -f "process_name" # 按进程名匹配并终止 pkill -9 -f "java.*app" # 强制终止满足模式的进程kill -9是最后手段，因为它不给进程任何清理机会，日志没写全、临时文件没删、状态没保存都可能因此发生。正确的顺序是：先kill（SIGTERM）等几秒，观察进程是否退出，不行再kill -9。这条经验来自一次数据库故障：直接kill -9导致数据库崩溃恢复，重启扫描磁盘就花了大半天，从那以后我再也不敢第一个就上 9 号信号。
pkill -f能匹配完整命令行，比按进程名匹配更精确，但也要小心，正则写宽了可能误杀。我见过有人pkill -9 -f "app"把同一个目录下所有含 app 字样的进程全杀了，损失惨重。用之前先ps aux | grep 模式看看匹配范围，确认无误再动手。
5.3 网络排查：ss、netstat、curl、lsof
网络问题排查是最日常的工作之一。先看端口监听：
ss -tlnp # 查看所有TCP监听端口及对应进程 netstat -tlnp # 旧工具，部分新系统需要额外安装 lsof -i:8080 # 查看占用8080端口的进程我推荐优先用ss，它比netstat快得多，处理大量连接时优势明显。-t只看TCP，-l只看监听状态，-n显示数字地址而不是反向解析域名，-p显示进程信息。排查“端口被占用”时这三件套基本够用。
对外的网络连通性测试用curl和ping：
curl -I https://example.com # 只看响应头 curl -v https://example.com/api # 显示详细交互过程 ping -c 4 8.8.8.8 # 发送4个ICMP包测试连通性 curl -X POST -H "Content-Type: application/json" -d '{"key":"value"}' http://localhost:8080/apicurl -v是我调试接口的最常用工具，能清楚看到请求头、响应头、TLS握手信息、重定向链路，比某些浏览器开发者工具还直观。调试 HTTP 接口时别忘了-X指定方法、-H指定请求头、-d指定请求体。
6. 磁盘与系统信息：摸清家底再说
6.1 df 与 du：磁盘空间的两种视角
磁盘撑满导致服务写不进日志，这个问题几乎每个运维都遇到过。排查它靠的就是df和du的组合：
df -h # 查看各分区的总容量、已用、可用 df -i # 查看inode使用情况，inode耗尽比磁盘满还难排查 du -sh /var/log/ # 查看某个目录总大小 du -h --max-depth=1 /var/log/ # 只看一层子目录的大小df -h是宏观视角，一眼看出哪个分区满了；du是微观视角，定位具体是哪层目录吃掉了空间。磁盘告警时我的排查路径是：先df -h找到满的分区，再对根目录逐层du -h --max-depth=1，顺着最大目录往下钻，直到找到元凶。很多时候是日志文件、临时文件、docker 镜像目录在悄悄膨胀。
一个容易被忽略的地方是df显示的是文件系统级别，不是目录级别。同一个目录可能跨多个挂载点，通过不同的路径看同一个文件，统计结果都可能不同。用du统计某个路径时，最好先用df -h 该路径确认一下它落在哪个挂载点上。
inode的概念也要知道。inode 是文件的索引节点，每个文件至少占用一个。如果 inode 耗尽，即使磁盘还有大量剩余空间，系统也会报“No space left on device”无法创建新文件。这种问题多由大量小文件导致，比如邮件队列、临时缓存目录。排查时df -i一看便知。
6.2 free、uname、lscpu：系统信息的快速体检
free -h # 查看内存总量、已用、可用 uname -a # 查看内核版本、主机名、架构 cat /etc/os-release # 查看发行版信息（新版系统更推荐） lscpu # 查看CPU型号、核数、架构 uptime # 查看运行时长和平均负载free -h里的“可用内存”概念很多人误解，Linux 的内存管理会把空闲内存用作缓存，所以“已用”那一列很大并不代表系统真不够用，要看available那一列。排查内存问题时，别光看 used，要同时观察 swap 有没有被大量使用，swap 频繁读写说明物理内存已经吃紧。
uptime输出的三个负载数字分别代表 1 分钟、5 分钟、15 分钟的平均负载。判断系统压力时，负载要和 CPU 核心数对比才有意义：负载持续大于核心数，说明 CPU 已经过载排队了。刚开机负载高往往只是因为启动任务密集，看 5 分钟和 15 分钟的趋势更能说明问题。
6.3 压缩与打包：tar 的日常与变通
处理发布包、备份数据、传输文件，天天都要和tar打交道：
tar czvf app.tar.gz /opt/app/ # 压缩并打包（c=创建，z=gzip，v=显示，f=指定文件） tar xzvf app.tar.gz # 解压（x=解压，z=gzip，v=显示，f=指定文件） tar cjvf app.tar.bz2 /opt/app/ # 使用bzip2压缩 tar xzvf app.tar.gz -C /opt/deploy/ # 解压到指定目录 tar tf app.tar.gz # 不解压，仅查看压缩包内容tar czvf和tar xzvf是出现频率最高的组合，我建议把这 7 个字母背下来，遇到压缩包先tar tf看看里面是什么目录结构，再决定怎么解压。很多新手直接解压，结果文件散到当前目录到处都是，整理起来头大。
解压发布包时有两个参数我很常用。一个是-C指定解压目标，避免把文件解到当前目录。另一个是--strip-components=1，解压时去掉第一层目录。比如包内结构是app-1.0.0/conf/...，你不想多出一个带版本号的父目录，tar xzvf app.tar.gz --strip-components=1 -C /opt/app/就能直接解压到目标目录下。
压缩格式的选择也有讲究：.tar.gz兼容性最好、速度适中，日常备份发布用这个就够；.tar.bz2压缩率更高但慢；.tar.xz压缩率最高但耗时最长。传输大文件或磁盘紧张时可以考虑高压缩率的格式，否则 gzip 是最平衡的选择。除了 tar，.zip格式在跨平台场景用得也很多，Linux 下用zip压缩、unzip解压，处理 Windows 传过来的压缩包是常事。
6.4 日志查看与追踪
日志基本靠tail、head、less三个命令打天下：
tail -n 100 app.log # 查看最后100行 tail -f app.log # 实时追尾日志 tail -F app.log # 实时追尾，日志轮转后自动跟随新文件 head -n 50 app.log # 查看前50行 less app.log # 分页查看，支持搜索tail -f和tail -F的区别是我踩过坑才记住的：-f在日志文件被轮转（比如 logrotate 把 app.log 改成 app.log.1 并新建空文件）后会停止输出，-F能自动识别新文件名并继续追踪。排查长时间运行的服务时，用-F更稳妥。
less是查看大日志文件的利器，进入后按/搜索关键字、按n跳转下一个匹配、按G跳到文件末尾、按g回到开头。查看一个几百 MB 的日志文件，用cat或者vi会卡到怀疑人生，less是增量加载，打开大文件毫无压力。我在分析堆积了几个小时的错误日志时，基本都是less + 搜索的组合，比先 grep 再开 vi 流畅得多。
7. 常见问题与排查技巧实录
7.1 Permission denied：权限拒绝的排查思路
遇到Permission denied，我按以下顺序排查：
- 先看当前用户是谁：
whoami - 再确认目标文件/目录的权限：
ls -ld 路径 - 确认目标目录的上级目录是否具备 x 权限，逐层检查
- 如果涉及服务运行，确认是否要
chown给服务账号
一个常见的隐蔽场景：文件权限显示 777 完全开放，但运行服务的用户根本到不了这个文件的路径，因为中间某个父目录权限为 700，没有 others 的执行权限。Linux 的权限检查是一层层来的，任何一层的 x 权限缺失都会被拒绝。
7.2 No space left on device：磁盘满的应急处理
出现磁盘写满导致服务异常，我的处理流程：
df -h # 确认哪个分区满了 df -i # 确认inode是否耗尽 du -h --max-depth=1 / # 找到占用最大的目录 # 定位后再逐层下钻，找到大文件或可清理的日志如果是日志文件撑满的，可以先通知服务方或自行清空日志。清空大文件有一个技巧：用> /var/log/xxx.log而不是rm，前者直接置空文件且不影响正在写入该文件的进程，后者删除了文件句柄，可能引发意想不到的问题，比如磁盘空间没释放（因为文件还被进程占用）。这条经验我在日志切割时反复用到。
7.3 进程杀不掉：排查事项
kill -9之后进程还在，先别急。用ps aux | grep 进程名看看进程状态：
- 状态为
Z（僵尸进程）：说明进程已经死了，但父进程没回收它。这种情况杀不掉是正常的，你杀的是一个“尸体”，它本身已不占 CPU，只占一个进程表项。处理方式是找到父进程，让父进程回收，或者重启父进程，实在不行只能重启系统。 - 状态为
D（不可中断睡眠）：通常是进程在等待磁盘 I/O 或网络 I/O 完成，此时即使用kill -9也无法立即终止，要等 I/O 操作返回。这种情况只能等，或者检查底层存储是否有故障。 - 如果确认进程是普通运行状态但 kill 无效，检查你是否具备权限，或者是否用错了 PID（比如在用容器 PID 对主机 PID 做操作）。
7.4 command not found：命令找不到的原因与解决
bash: xxx: command not found基本是两个原因：
- 命令没有安装，用发行版对应的包管理器安装即可：Ubuntu/Debian 用
apt install，CentOS/RHEL 用yum install或dnf install。 - 命令已经安装但不在当前用户的
PATH环境变量里：先find / -name "命令名"找到可执行文件，再确认路径是否在 PATH 中，echo $PATH查看。
排查command not found时，我用一个命令快速区分：
type 命令名 # 查看命令类型和路径 which 命令名 # 查看可执行文件的路径另外要提醒的是：某些系统管理命令（比如ifconfig、route）在新版本里被ip命令取代了，有的发行版默认不安装新包。如果你习惯了旧命令，apt install net-tools可以把它们装回来。这不是命令本身没了，只是工具的更新换代。
7.5 端口被占用：定位与释放
启动服务时报port already in use，处理顺序：
ss -tlnp | grep 端口号 # 找到占用端口的PID lsof -i:端口号 # 更详细地查看占用进程 kill 该PID # 优雅终止 kill -9 该PID # 如果优雅终止失败这里要特别注意ss、netstat、lsof的输出差异。ss输出最精简，适合快速定位；lsof -i:端口号信息最全，能直接看到是哪个用户、哪个进程、完整命令行是什么。遇到端口看似没进程监听、但连接仍然被拒绝的情况，记得检查防火墙规则：iptables -L -n或者firewall-cmd --list-all（CentOS 7+）确认端口有没有被防火墙拦截。
8. 命令记忆经验：怎样让这些命令真正变成自己的
说了这么多命令，最后聊点实际的：怎么把这些东西记住。我不推荐死记硬背，更推荐在场景中反复使用，最好的学习方法就是刻意为某些日常任务设计命令组合。
比如你每周都要备份某个目录，别总是用图形化工具，试着用tar czvf配合date命令写一条自动命名备份文件的命令：
tar czvf backup_$(date +%Y%m%d_%H%M%S).tar.gz /opt/data/$(date +%Y%m%d_%H%M%S)会自动生成带时间戳的文件名，这条命令多写几次，tar的自然就会了，而且还会顺带学会 shell 的命令替换。类似的技巧还有：在~/.bashrc里给常用命令设置别名，把容易记混的参数固化下来：
alias ll='ls -lah --color=auto' alias rm='rm -i' alias grep='grep --color=auto'我个人觉得最有用的学习方式是：给自己一个“本周命令目标”，比如这周只看ps和top，下周解锁netstat和ss，再下周攻awk。不要试图一次记下所有命令，人的短期记忆撑不住这么多参数。把命令集合当成案头手册，用到什么查什么，通过实际任务慢慢内化，比强行背参数效果强一百倍。
另外，遇到特别巧妙或者特别容易忘的命令，我习惯直接在命令后面加注释存到一个笔记文件里，哪天想不起来就翻一下。这个集合会被我持续更新，每多一次排障经验、每多一条好用的命令，都往里面补充。你在阅读时如果发现自己的常用命令没被收录，也完全正常——每个人的工作场景不一样，自己的“常用命令集合”才是最有价值的命令手册。
