1. 终端认知与最常用的文件操作指令
1.1 从终端的第一条指令说起
先说个定心丸：Linux的指令再多，日常工作中真正高频使用的，其实不超过三四十条。很多人一上来就去啃几百页的命令手册，结果记住的没几条，遇到问题还是到处搜索。我一直建议的方法是先掌握几个基础指令的细节，把它们的各种选项用透，比泛泛记住一堆指令名字有用得多。
终端打开之后，第一个要理解的概念是“当前位于哪个目录”。pwd（print working directory）就是干这个的，输入后直接回显当前绝对路径。很多新手在写脚本或配路径时，报错“No such file or directory”，十有八九就是不知道当前在哪个目录，把相对路径写错了。记住一句话：任何时刻都不确定自己在哪，先pwd。
cd切换目录时有一个很多人忽略的细节——cd ~和直接cd都是回到当前用户家目录，cd -是回到上一次所在的目录。cd -这个指令在你要在两个目录之间反复切换时特别好用，比一个个敲路径快得多。还有cd ..是上级目录，cd ../..是上两级，这个没什么好说的。
ls是使用频率最高的指令之一，但大多数人只用了ls和ls -l。实际工作中我说的标准组合拳是：
ls -lah # 查看当前目录所有文件（含隐藏文件），人类可读大小 ls -lt # 按修改时间倒序排列，最新修改的排在最上面 ls -lS # 按文件大小降序排列，找大文件时首选-h选项让文件大小显示为K、M、G这样的单位，而不是冷冰冰的字节数。-t这个选项在排错时特别好用，你刚修改过的配置文件会排在第一个，一眼就能看到。
1.2 文件操作三件套：cp、mv、rm 的隐藏细节
文件复制、移动、删除是每天都在做的操作，但这里的坑其实不少。先讲cp：cp source dest是最基本用法，但复制目录时必须加-r（recursive），即cp -r dir1 dir2，否则会报错“omitting directory”。日常我几乎总是加-a而不是-r，这两个的区别在于-a等于-r加上保留权限、时间戳、属主等属性。尤其在打包项目迁移时，用cp -a复制的目录跟原目录的元数据几乎完全一致，后面对比文件或者校验权限时省很多事。
mv移动文件时还有一个场景：跨文件系统移动。比如从/tmp移动到一个挂载在其他磁盘的目录，此时mv实际上是先复制再删除原文件。如果你要移动的是几十个G的数据库文件，这个操作会耗时很长，而且如果中途断电，可能出现源文件已删、新文件不完整的情况。遇到这种大文件跨分区移动，我建议直接用rsync并在确认完整后再删原文件，这个后面讲传输时会展开。
rm的杀伤力就不必多说了，rm -rf是每个Linux用户最需要敬畏的组合。我的习惯是能不用rm -rf就不用，删目录前先ls确认一遍路径。更稳妥的做法是养成给重要目录设置别名保护的习惯：
alias rm='rm -i' # 每条删除都要确认 alias rm='rm -I' # 删除超过3个文件，或递归删除时要求确认上面两个写进~/.bashrc之后，能拦住大部分手滑的操作。不过提醒一句：别名只在交互式 shell 里生效，脚本里写的rm -rf不会受别名影响，所以写脚本时删除操作更要慎重。
再补充一个文件链接的常识。ln -s source link创建软链接，相当于Windows里的快捷方式；ln source link创建硬链接，相当于给同一个文件再起一个名字。两者的关键区别是：软链接删除原文件后链接就失效了，硬链接删除原文件后文件依然可以通过另一个名字访问（inode还在）。目录不能做硬链接，但可以做软链接。日常部署里设置环境切换时，软链接用得最多，比如ln -s /data/app/current /data/app/release，下次发版时把current从旧版本重新指到新版本就行。
2. 查看与处理文本内容
2.1 阅读类指令：cat、less、tail、wc 怎么选
日志文件、配置文件的查看是Linux日常操作里绕不开的活儿。很多人一上来就是cat加文件名，然后屏幕上刷刷刷滚出几百行，看完头都晕了。这里要分清场景。
cat适合查看内容不长的文件，或者用于把几个文件拼接成一个文件（cat a.txt b.txt > c.txt）。但是文件超过一屏时，cat就不是好选择了，你应该用less。less支持上下翻页、搜索，进入后按/输入关键词回车就能高亮定位，按q退出，按g跳到文件开头、G跳到文件末尾。我排查日志时几乎都是less打开，定位到关键字附近之后，再按n跳转到下一个匹配项，效率非常高。
tail是日志排错的另一个核心指令，尤其是tail -f会实时跟踪文件输出，常用于观察正在写入的日志。这个-f选项在紧急定位线上问题时能让你看到日志的最新动态。如果日志文件太大，从尾部开始看反而更接近问题发生的时刻，这也是为什么tail永远比head用得多。head偶尔用来查看配置文件的头部注释说明，比如head -50 nginx.conf。
wc -l计算文件行数，这个在统计日志规模时很常用，比如wc -l access.log看当天请求记录量。加-c则是看字节数。需要注意的是，如果文件最后一行没有换行符，wc -l统计出的行数会比实际少一，这个细节在一些严谨的统计脚本里会被坑到。
2.2 文本三剑客：grep、awk、sed 的实战姿势
这三个指令是Linux文本处理的核心，值得花时间把高频用法吃透。
grep的第一原则：能加引号就加引号。搜索带空格的字符串或者正则表达式，不加引号很容易被shell展开误导。第二原则：-E表示用扩展正则，如果你要匹配类似(foo|bar)的多选模式就必须加；不带-E时默认的基础正则也能应付大多数场景，但有些元字符（如+、|）需要转义才能用，容易记混，所以我现在干脆都用grep -E，心智负担小。
实战里我常用的一套组合是：
grep -E "ERROR|Exception" app.log | grep -v "timeout" | head -50含义是：先粗筛出包含错误关键字的行，再排除掉包含timeout的干扰行，最后只看前50行。这种层层过滤是排查问题时效率最高的方式，比一次次地重新搜整个文件强得多。还要提醒一个坑：grep在匹配二进制文件时可能输出“Binary file matches”而看不到实际内容，此时可以加-a把文件当文本处理。
awk的核心价值在于按列处理。默认按空白字符（空格、Tab）分隔字段，$1是第一个字段，$NF是最后一个字段，NR是当前行号。经典的统计案例是查看日志里的请求耗时：
awk '{print $NF}' app.log | sort | uniq -c | sort -nr这条指令把每行的最后一个字段提取出来（假设是耗时数值），排序后统计频次，再按频次倒序。一眼就能看出耗时最多的几种情况分布。awk 还可以在行首加条件，比如awk '$3 > 500 {print $1, $3}'只打印第三列大于500的行。这种按条件抽取列的写法，在分析性能数据时特别顺手。
sed的替换功能是改文件内容的首选。比如把配置文件里的旧IP批量改成新IP：
sed -i 's/192.168.1.10/192.168.1.11/g' nginx.conf-i是原地修改，s是替换指令，g表示全局替换每行中所有匹配，不加g时只替换每行第一个匹配。这个-i选项要小心，建议第一次执行时先不加-i预览输出结果，确认无误再真正落地修改。sed删除行的场景也很常见：sed -i '/^#/d' config.conf可以删除所有以#开头的注释行，这在清理配置时非常高效。
find和xargs是一对黄金搭档。find负责搜索，xargs负责把搜索结果交给其他指令处理。比如搜索所有.log文件并查看总大小：
find /var/log -name "*.log" -type f | xargs ls -lh有个细节：find -exec也能实现类似功能，但每次遇到一个文件就启动一次外部进程，文件多的时候性能很差。xargs会把文件列表打包成批，一次性传给外部指令，效率高得多。但要注意文件名含空格的情况，xargs默认按空格拆分会出错，稳妥做法是find ... -print0 | xargs -0，用空字符做分隔符。
3. 用户权限与磁盘管理
3.1 权限模型与 chmod、chown 的实战理解
Linux的权限模型抽象出来不复杂：每个文件都有属主（user）、属组（group）、其他用户（other）三类主体的读（r=4）、写（w=2）、执行（x=1）权限。很多人看到-rw-r--r--就懵，其实拆解一下：第一个字符是文件类型（-普通文件、d目录、l软链接），后面9个字符按三个一组读，rw-表示属主可读写，r--表示属组可读，最后一个r--表示其他人可读。
日常最常用的是数字方式改权限：chmod 755 script.sh。7是属主权限（4+2+1=全部），5是属组权限（4+1=读执行），5是其他用户权限。执行权限x是脚本能不能跑的关键，所以新建的脚本文件需要chmod +x或直接给到755才能被执行。
有个典型坑是目录权限：一个目录只有r和x权限而对用户没有w权限时，用户可以进入并查看目录内容，但无法在其中新建或删除文件。很多权限问题排查半天，发现不是文件本身的问题，而是上级目录的权限限制了访问。
chown修改属主和属组，线上部署时几乎天天用：
chown -R www:www /data/wwwroot-R递归作用于目录下所有子文件和子目录。给Nginx或PHP-FPM部署站点后，如果不把目录属主改成运行服务的用户，常常会遇到页面能打开但写不了缓存之类的权限报错。排查这类问题有一个固定套路：先看进程以哪个用户运行（ps -ef | grep nginx），再看文件属主是否匹配（ls -l），最后看中间目录的权限链。
3.2 磁盘占用排查：df、du、mount 的组合用法
磁盘空间满了是运维场景里出现频率极高的问题。先分清两个指令：df -h查看整个文件系统的使用情况，du -sh查看某个目录占用的空间大小。-h都是人类可读格式。网上有人把二者混淆，其实定位思路很清晰——先用df确认哪个分区满了，再用du一层层深入找出大目录。
我排查磁盘占用的标准动作是这样的：
df -h # 确认哪个分区使用率接近100% du -sh /var/log/* | sort -rh | head -20 # 找出占用最大的子目录sort -rh按人类可读大小倒序排序，这里要特意提一句：sort -h才能正确识别1K、10M、2G这类单位做排序，不加-h时会出现1G排在1M后面的笑话。找到大目录之后继续深入下一层，重复du -sh，直到定位到具体文件。
还有一个隐蔽场景：df显示满了，但du统计出来的总占用却远小于分区容量。这种情况多半是文件被进程删除了但句柄还被占着，空间无法释放。排查手段是lsof | grep deleted，杀掉对应的进程或让服务重启，空间才会真正归还。
磁盘挂载相关的mount指令，日常用得最多的参数是mount -t nfs -o vers=4 server:/path /mnt/nas这类挂载网络存储的操作。这里强调一个经验：挂载不要顺手写进/etc/fstab除非明确知道要开机自挂。因为网络存储如果在系统启动时还没就绪，启动流程可能卡在挂载上，导致等待超时甚至进系统缓慢。真要开机挂载，建议加nofail选项，让挂载失败时自动跳过，不给启动流程带来阻碍。
4. 进程管理与系统资源排查
4.1 进程查看与 kill 的正确姿势
ps是查看进程的入口指令。我几乎不用不带选项的裸ps，日常固定用这一套：
ps -ef | grep nginx ps aux --sort=-%mem | head -10 # 按内存占用倒序，找出内存大户ps -ef输出里几个字段要知道：PID是进程号，PPID是父进程号，一般排查僵死进程时看PPID能判断是从哪个服务拉起来的。查询进程还有个更精准的方式是用pgrep -f，比如pgrep -f "java.*app.jar"能按完整命令行匹配，而pgrep java可能把无关的java进程都匹配出来。
进程的信号控制核心是kill，但很多人一上来就是kill -9，这是错误用法。信号级别从弱到强：TERM(15)是默认信号，请求进程正常退出，给它机会做收尾工作；INT(2)是Ctrl+C发的中断信号；KILL(9)是强杀，由内核直接终止进程，没有任何清理机会。所以遇到要停服务时，正确顺序是先kill（即kill -15），等几秒没反应再kill -9。对数据库这类有事务逻辑的服务直接-9，轻则恢复耗时长，重则数据文件损坏。
查看资源占用动态变化，top进入后可以按1（显示每核CPU）、M（按内存排序）、P（按CPU排序）、z（彩色高亮）。如果看到某个进程CPU持续接近100%，结合htop的树形视图能看到进程间的父子关系，更直观地定位到具体服务。不过线上环境往往没装htop，纯top也完全够用。
僵尸进程是个特殊情况：进程已退出但父进程没回收它的状态信息，ps里显示为Z状态。僵尸进程本身不占CPU和内存，但大量累积说明父进程逻辑有缺陷。关键是找不到 PID 去强制清理——僵尸进程不能被kill，只能等父进程退出后由init进程接管回收，或者直接重启父进程。
4.2 系统资源排查：free、uptime、iostat 的联动判断
系统卡顿的时候，CPU、内存、磁盘IO三个维度都要看。
内存看free -h，观察available字段而不是死盯free。因为Linux的内存分配策略是“能缓存就缓存”，buff/cache占了一大块并不代表内存不够，真正体感卡顿要看available是否接近0。如果swap使用率持续上涨，说明内存确实吃紧，系统正在频繁把内存页换入换出，这时候最有效的办法是找出占用大户进程并重启或调优。
平均负载看uptime，输出的三个数字分别代表过去1分钟、5分钟、15分钟的负载均值。这里有一个误读很常见：负载不等于CPU使用率。负载的含义是在等待调度的进程数量，如果服务器是4核，负载长期超过4.0，说明进程排队明显，可能是CPU瓶颈也可能是IO瓶颈。1分钟比15分钟明显高说明是短期波动，可能是瞬时任务导致；如果15分钟也很高就是持续压力。
磁盘IO用iostat -x 1观察，重点看%util是否经常接近100%，await等待时间是否居高不下。注意一个很容易踩的坑：%util100%不代表磁盘一定坏了，它表示该磁盘设备在整个采样周期内一直有任务在排队，但不一定所有IO都在等待（NVMe盘几乎可以一边处理一边接收新请求），所以还要结合r/s、w/s的吞吐量绝对值判断。数据库类服务器的慢查询排查，如果 SQL 本身没问题，八成就是IO瓶颈支撑不住并发。
我排查系统卡顿的固定顺序是：先uptime看负载是否有异常，然后free -h排除内存不足，接着top看谁在吃CPU，最后iostat -x 1确认是否有磁盘等待。四个维度串下来，绝大多数问题的第一嫌疑对象就出来了。
5. 网络诊断与配置排查
5.1 网络状态检查：ip、ss、ping、traceroute
以前的ifconfig和netstat已经逐渐被ip和ss取代，新装的发行版上这两个老指令常常不存在，需要额外装net-tools。所以我现在的习惯是直接用新的指令，免得换个环境就报command not found。
ip addr查看本机IP地址，ip route查看路由表，ip link set dev eth0 up启用某个网卡。这些是最基础的操作。需要特别提醒的是配置好网卡后，如果发现IP配置看起来没问题却不生效，多半是忘了重启网络服务或在新的网络管理器里重新加载配置，不同发行版的方式不同，但思路是一致的：让配置从树形落到实际网卡上。
连接排查的核心是ss。
ss -lntp # 查看所有监听中的TCP端口及对应进程 ss -anp | grep :8080 # 查看8080端口是否有人监听-l只看监听状态的端口，-n不做域名反解析（不然可能卡在DNS解析上导致输出很慢），-t只显示TCP，-p显示对应进程。这个-p选项是日常查端口冲突、查服务是否启动的最顺手工具。以前大家查监听端口习惯用netstat -lntp，但现在很多精简系统没有 netstat，ss是标准替代。
ping测延迟、判断目标是否可达，但注意通的不代表业务通。ICMP通只能说明网络链路层没问题，不代表目标服务器的80或443端口在正常响应。所以链路通之后要立刻用telnet ip port或者更现代化的nc -vz ip port测试目标端口是否开放。traceroute（或tracepath）用于定位链路中哪一跳延迟高或丢包，排查跨运营商丢包问题时很实用。不过要理解一点：很多骨干网节点出于安全考虑不响应ICMP，显示*并不一定就是故障，只要最终到达了目标，中间节点有星号很正常。
5.2 DNS解析排查与配置文件的关键项
网络不通的问题排查到后面，往往不是IP层而是域名解析层。域名解析不了，现象是ping 域名报“unknown host”。
排查第一步看系统里的DNS配置，cat /etc/resolv.conf，里面nameserver行指向哪个DNS服务器。很多内网环境连不上外网时，把nameserver改成内网DNS就能解决；反之外网环境配了内网DNS地址，所有域名解析都会失败。
第二步用nslookup或getent hosts验证解析结果。nslookup是查询域名的DNS记录，但现在有些系统默认没装，而getent hosts baidu.com走的是系统底层解析流程（也就是会尊重/etc/hosts的优先规则），更能反映应用层到底能不能解析成功。/etc/hosts这个文件里手动映射的域名优先级高于DNS服务器，测试环境里经常用它临时把域名指向本机IP。
还有一个高频场景：应用日志里报连接超时，但直接curl目标站点却正常。这时要想到应用可能用了独立的DNS配置或本地hosts不生效，比如Java应用有自己的/etc/hosts白名单机制，或者Docker容器里的DNS配置与宿主机不一致。思路是分别验证容器内和宿主机上的解析结果，再决定是调整/etc/resolv.conf还是改应用的DNS策略。
5.3 端口连通性测试与HTTP排查
curl可以说是线上排错里最重要的网络工具。基础用法curl -v http://localhost:8080/health能看到详细的请求过程，包括DNS解析、TCP握手、TLS握手、HTTP响应行。-v输出里的以下关键点值得关注：
Connected to xxx (127.0.0.1) port 8080表示TCP连接建立成功HTTP/1.1 200 OK表示服务端正常响应- 卡在
TLS handshake多半是证书或协议版本问题 Connection reset by peer往往是服务端主动断开，服务可能正在崩溃或防火墙拦截
连接不上时，curl配合端口测试的思路很顺手：先curl本机验证服务是否活着，再curl外网IP验证监听地址是否正确绑定（很多服务只绑了127.0.0.1，外网访问不了），最后用ss -lntp确认监听地址。这串下来，网络层和端口层的问题基本都能定位。
HTTP状态码的快速判断也是基本功：401/403是鉴权问题，看Nginx的error.log里是不是有connection refused或者proxy_pass指向的后端挂了。502是网关/代理连不上后端，504是后端超时。日志里出现大量的502时，首先要做的不是看应用而是看后端的进程是否还活着，很多时候ss -lntp | grep 9000一下，发现PHP-FPM或Java进程已经没了。
6. 系统与服务管理
6.1 systemctl 的日常体系
现在的Linux发行版上，服务管理基本都是systemd体系，systemctl成为主力管理工具。日常用到的高频子指令：
systemctl start nginx # 启动服务 systemctl stop nginx # 停止服务 systemctl restart nginx # 重启服务 systemctl status nginx # 查看状态及最近日志 systemctl enable nginx # 设置开机自启 systemctl disable nginx # 取消开机自启 systemctl daemon-reload # 修改service文件后重新加载enable和start的区别常被混淆：enable只改开机自启的配置，不会立刻启动服务；start只启动本次，不设开机自启。线上部署时两个都要执行，比如systemctl enable --now nginx一条命令同时完成。
排查服务起不来的标准流程：systemctl status查看当前状态，如果有失败原因直接看journalctl -u nginx查看服务的日志。注意很多服务启动失败的原因是配置语法错误而不是服务本身问题，比如Nginx配置写错后，systemctl restart nginx会失败，此时nginx -t可以直接检测配置文件语法，更快定位问题。
还有一个易踩的坑：改完配置文件后systemctl restart不生效。这不是指令没用，而是系统级缓存或子进程没有完全退出。遇到这种“诡异问题”，先systemctl stop然后确认进程不存在（pgrep查一遍），再start。如果进程杀掉马上被拉起，那是有守护进程在自动拉起它，或者 systemd 的Restart=策略在作用。
6.2 日志集中查看：journalctl 的正确打开方式
systemd 会把服务的标准输出和标准错误统一收集，journalctl是查看这些日志的唯一入口。高频用法：
journalctl -u nginx # 查看某服务的全部日志 journalctl -u nginx -f # 实时跟踪该服务的日志 journalctl -u nginx --since "10 minutes ago" # 只看最近10分钟 journalctl -u nginx -p err # 只看错误级别以上的日志-p err这个参数大多数人都忽略，而当服务每天刷几千条INFO日志时，这个选项能直接过滤出关键问题。日志级别从高到低是emerg、alert、crit、err、warning、notice、info、debug，指定-p err表示只看err及更高级别。
journalctl重启后日志会持久存储，但如果/var/log/journal目录不存在，日志只保存在内存里，重启就丢了。这个坑在排查“开机后日志怎么不见了”时尤其容易碰到。解决方法是创建/var/log/journal目录并重载。
如果想看所有启动阶段的完整日志（包括boot loader阶段），那是journalctl -b的活。-b -1可以查看上一次启动的部分日志，这在排查开机问题（系统启动到一半卡住）时几乎是唯一线索。配合systemctl --failed查看启动失败的单元列表，可以快速判断是哪个服务拖了启动进度。
7. 打包压缩与文件传输
7.1 tar 的命令细节与打包避坑
tar是最通用的打包工具，但它本身不压缩，只是把多个文件打包成一个归档，再配合gzip（gz后缀）或bzip2（bz2后缀）压缩。日常用到的高频组合：
tar -czvf backup.tar.gz /data/wwwroot # 打包并gzip压缩 tar -xzvf backup.tar.gz -C /tmp # 解压到指定目录 tar -tzvf backup.tar.gz # 只查看归档内容列表，不解压-c创建、-x解压、-t查看列表、-zgzip压缩/解压、-v显示过程、-f指定文件名。-f必须放在选项组最后，因为-f后面跟的是文件名参数，如果写成tar -cvfz，z会被当成文件名的一部分，这是新手经常报错的地方。
打包还有一个经典坑：绝对路径。如果执行tar -czvf /tmp/backup.tar.gz /data/wwwroot，解压时归档里的路径是/data/wwwroot，文件会被解压回原路径，而不是你期望的当前目录。正确做法是先cd /data再执行tar -czvf /tmp/backup.tar.gz wwwroot，这样归档里的路径是相对的。备份脚本里如果没注意这个细节，恢复时可能会把文件散落到系统各个目录，非常危险。
压缩格式的选型上，追求速度（比如日志归档）用gzip；追求更高压缩率且不在乎耗时（比如冷数据备份）可以用xz，即tar -cJvf。个人做大数据量归档时推荐xz或zstd，但要注意目标机器是否支持相应的解压工具，否则换台机器解不了压就尴尬了。
7.2 远程传输与同步：scp 与 rsync 的取舍
跨机器传文件，scp是最直接的方式：
scp file.txt user@remote:/tmp/ scp -r /data/app user@remote:/data/ scp user@remote:/var/log/app.log ./scp依赖SSH服务，需要目标机器开放22端口。-r递归传目录。它的缺点是全量复制，哪怕只改动了一个字节也会重新传完整文件，网络条件不好时效率偏低。
Syncing场景我会用rsync，它只同步差异部分，支持断点续传和增量复制，在日常备份时比scp好用得多。
rsync -avz --progress /data/app/ user@remote:/data/app/ rsync -avz --delete /data/sync/ user@remote:/data/sync/-a归档模式（保留权限和时间戳），-v显示过程，-z传输时压缩，--delete删除目标端多出的文件（让两端完全一致）。--delete必须谨慎，它意味着源端删了，目标端也会删，如果源端目录被误清空，目标端也会被清空。我通常在第一次同步时不加--delete，确认两端内容对比无误后再加上。
rsync还有个重要细节：源路径结尾是否有斜杠含义不同。rsync -avz /data/app/ user@remote:/data/app/表示同步目录内容；rsync -avz /data/app user@remote:/data/app/则会把app目录本身放到目标端。多一个斜杠，目录结构就多一层，这个细节能直接影响部署后的文件路径是否匹配。
8. 提升指令效率的四个小习惯
前面七章覆盖了日常运维和开发中最常用的指令和场景。最后分享几个我用了很多年、在实际工作中反复验证过的效率习惯，都是小事，但日积月累能省下大量时间。
第一个习惯：多用补全，少手敲。Bash的Tab补全不仅能补指令名，还能补文件名、目录名、命令选项。按下两次Tab会列出所有匹配项。很多人觉得自己记得住全名就不用补全，但在路径很深、文件名很长的场景下，补全不仅快，还能避免拼写错误带来的“command not found”。
第二个习惯：善用历史记录。按上方向键翻历史命令太慢，Ctrl+R直接反向搜索历史，输入一个关键字就能找到曾经敲过的完整指令。history | grep keyword也可以，但Ctrl+R更快。如果你经常在同一台机器上重复执行相近操作，这个习惯能让手指少受很多罪。历史记录默认只存最近1000条，可以增加HISTSIZE=5000到~/.bashrc里。
第三个习惯：给高频长指令做别名。在~/.bashrc里加：
alias ll='ls -lah' alias j='journalctl -u nginx -f' alias dps='docker ps --format "table {{.Names}}\t{{.Status}}"' alias duf='du -sh * | sort -rh'这些别名写好后source ~/.bashrc生效。别名的价值不只是少敲几个字母，而是把你最常用的、容易记错的那条长指令固化下来，减少输入出错。我见过不少工程师在服务器上反复敲同一条十几位长度的查询指令，每敲一次都费劲，其实定义个别名一劳永逸。
第四个习惯：写脚本之前先查手册。man指令是Linux自带的说明书，man ls、man rsync能查看完整选项和示例。很多人遇到不熟悉的选项第一反应是上网搜索，但网络内容良莠不齐，最权威的解释始终是官方手册。查man的时候注意按/搜索关键词，比如/timeout能直接跳到相关段落。这比把整个手册从头读一遍高效得多。
我个人还有个心得：每遇到过不去的报错，先把报错信息原封不动地复制到搜索引擎里搜一次，并且加上你的发行版名称（比如Ubuntu或CentOS），因为很多报错在不同发行版上的处理方式完全不同。但这里要强调：网上给出的命令，尤其是涉及rm、mkfs、dd这类高风险操作的，一定要先看懂每一条的作用再执行，不明白的先man查清楚，不要“一键复制粘贴”。这也是我最后想认真说的一点——指令本身就是工具，工具本身没有对错，但用工具的人如果没有敬畏心，再简单的指令也能造成大事故。
Linux的学习曲线在头一个月最陡，熬过去之后你会发现：指令记住的越多，排查问题时的思路就越宽；思路越宽，解决未知问题的速度就越快。这篇汇总里的指令和技巧，都是我从业以来用得最顺手、被验证过最可靠的那一批，希望对你也有同样的价值。
