每天打开终端我敲的第一批命令永远是固定的那几条df -h扫一眼磁盘水位uptime确认负载再git status看看昨天留下的活儿干到哪了。这些指令闭着眼都能打出来属于典型的常规操作和指令——高频、基础、风险低但覆盖面极广。可我发现一个有意思的现象很多人能熟练敲出十几条常用命令却说不清每条命令背后在做什么、选项之间有什么区别、什么场景下该换哪种写法。真到排查问题的时候就容易卡在命令会打但不会组合的尴尬位置。这篇东西没有高深的内容就是把我在日常开发和服务器运维里反复使用的那些常规操作和指令整理成了一套自己的用法和习惯。适合刚入行的新人当成一份每日必敲清单来对照也适合有几年经验但习惯零散记忆的朋友看看有没有可以互相补充的顺手技巧。1. 先聊聊我理解的常规操作和指令1.1 常规不等于简单很多人一听到常规两个字就觉得是入门级的东西不值得花时间。我恰好持相反观点。常规操作和指令的定义应该是你在日常工作中使用频率最高、出错后影响面大、并且能组合出复杂能力的那些基础动作。它们可能语法很简单但组合起来就是排查问题的完整链路。举个最直白的例子ls够常规了吧但ls -l输出的每一列代表什么ls -lt和ls -ltr的区别是什么ls -d */能用来做什么这些细节不是每个人都答得上来。常规操作的价值恰恰体现在这些细节里——真正干活的时候你是不可能停下来查手册再继续的手指比脑子快才是常态。1.2 我把常规操作分成三个层次第一层是会打。知道有cd、cp、mv、rm这些命令能凑合着完成简单操作。这一层的人通常依赖方向键和猜效率低且容易踩坑。第二层是知道选项。明白cp -a和cp -r的区别知道rm要加-i才安全清楚grep -E可以用扩展正则。到了这一层日常工作基本够用了。第三层是组合成套路。比如排查磁盘问题时我不会只敲一条df -h而是会接着用du -sh /*定位大目录用find /data -type f -size 500M找出具体的大文件再用lsof | grep deleted排查有没有删了但没释放的句柄。这一套下来问题基本就能定位了。这篇文章主要想帮你走到第三层。每一组指令我都会给出日常用法 容易忽略的细节 我自己踩过的坑你可以直接拿去对照自己的工作场景。1.3 为什么值得专门整理一遍我的体会是线上事故往往不是复杂的架构问题引起的恰恰是最基础的常规操作失误——误删了文件、权限配错导致服务起不来、日志里明明有报错却定位不到位置。把常规操作练成肌肉记忆等于给日常工作的基础打了一层底。真正的高手不是会什么冷门黑科技而是把常规指令用到了下意识就能组合出正确套路的程度。2. 文件与目录操作每天最频繁的一批指令2.1 增删改查的顺手写法文件操作是所有常规操作里占比最高的部分我先从最常用的几个指令说起。ls -l我基本不用裸ls原因很简单没有权限、属主、大小、时间的列表等于没看。输出里的第一列是文件类型-是普通文件d是目录l是软链接这一眼就能判断当前目录下有什么类型的东西。cp -a和cp -r的区别值得多说一句。-a是归档模式等于-dR --preserveall会保留权限、属主、时间戳和软链接属性-r只是递归复制。日常备份、迁移目录的时候我默认用cp -a否则复制出来的文件属主和时间戳全变了后面排查问题时会多出很多干扰信息。mv有一个隐藏坑跨文件系统移动文件时mv实际上是复制 删除不是简单的改个名字。如果目标路径在另一个挂载点mv大目录会非常慢而且中途失败还可能留下半成品。判断方式很简单先df -h 源路径 目标路径看是否在同一文件系统不在的话建议直接rsync。rm是所有人最该谨慎对待的命令。我的习惯是凡是要删东西先ls -l或find确认路径再执行删除能用rm -i就用rm -i让系统再问你一次批量删除前面加echo预览结果确认无误后再真正执行。比如find /tmp -type f -name *.log -exec rm {} \;这种我每次都会先跑一遍不带-exec的版本把结果列出来看清楚再动手。提示生产环境里我还会额外做一件事把rm做一个别名指向rm -i。别觉得多余我见过太多次手滑多按了一个空格造成的悲剧了。2.2 权限管理最容易忽略的常规操作权限问题是新人最容易忽略、线上却经常出事的领域。最常见的场景是部署服务后发现没有权限或者无法写入日志这时候你需要的是chmod和chown的组合操作。日常写法里我倾向于用符号模式而不是数字模式。chmod ux script.sh比chmod 755 script.sh更直观因为你明确知道自己在给属主加执行权限。而数字模式适合一次性明确设置完整权限比如chmod 640表示属主可读写、属组可读、其他人无权限。两者不冲突但你要清楚自己到底在改哪一项。chown的坑在于-R递归。chown -R appuser:appgroup /data/app会把整个目录树下所有文件的属主都改掉这在部署时很常见但要注意符号链接的处理——chown默认会修改链接指向的目标而不是链接本身。如果只想改链接需要加-h。我在初始化新环境时通常会写一段固定的初始化命令把属主、权限、目录结构一次性配好省得后面一个个排查。2.3 查找与定位find 的常规用法find是定位文件最核心的指令它和ls、grep组合起来能解决绝大多数文件去哪了的问题。按名字找find /data -type f -name *.log。注意-name是精确匹配文件名-iname忽略大小写。按时间找find /data -type f -mtime 7表示修改时间在 7 天前的文件-mtime -1表示 1 天内修改过的。排查哪个文件刚被动过时这个参数特别好用。按大小找find / -type f -size 1G。磁盘告警时的主力命令先按大小筛出大文件再决定是清理还是迁移。执行操作find ... -exec rm {} \;或者find ... -exec ls -lh {} \;。这里有个细节{}会被替换成每个找到的文件路径\;表示命令结束。如果换成-exec ... {} 则会把结果打包成尽量少的批次执行性能更好但有些命令不支持这种写法。我在组合find和xargs时特别注意一个坑文件名包含空格的情况。find /data -type f -print0 | xargs -0 grep keyword是安全的写法-print0用空字符分隔xargs -0按空字符解析这样任何文件名都不会被拆错。直接用默认的xargs遇到带空格的文件名结果会非常诡异。3. 系统状态与进程管理常规检查清单3.1 资源查看的组合用法排查系统问题我有一套固定的开场动作叫做三查uptime看负载。输出的最后三个数字分别代表 1、5、15 分钟的平均负载。如果 1 分钟负载远高于 15 分钟负载说明系统正在经历突发压力如果三个数字都高说明问题持续有一段时间了。free -h看内存。重点不是 Available 那个数字而是理解 buff/cache 的作用。Linux 会把空闲内存拿来当缓存所以内存不够不代表系统真的不够用要看 Available 是否充足。如果 Available 持续走低、同时 Swap 开始被使用那才是真正需要关注的时候。df -h看磁盘。这里有个容易踩的坑——df -h显示的是文件系统的容量但很多场景下 inode 先被耗尽了。所以磁盘相关的常规检查我会顺手加一条df -i看 inode 使用率。我遇到过几次这样的情况df -h明明还剩 30%服务却报no space left on device最后查出来都是 inode 耗尽了。这三条命令单独看都很简单但它们组合起来能快速给出系统状态的完整画像。我的习惯是把它们写成一行固定命令uptime free -h df -h df -i每次怀疑系统出问题时先跑一遍基本能把方向定下来。3.2 进程管理信号的理解比 kill 本身更重要ps和kill是进程管理的常规指令但很多人对信号的理解是模糊的。ps aux和ps -ef输出格式略有差异我习惯用ps aux因为 CPU 和内存占用率直接显示在第三和第四列方便一眼看出谁在吃资源。查某个具体进程时会用pgrep或ps aux | grep 名称注意 grep 本身也会匹配到一般我会再加一个grep -v grep或者直接pgrep -f。kill的核心是信号。实际工作中最常用的三个信号SIGTERMkill pid默认信号让进程优雅退出。进程可以捕获这个信号做清理工作比如关闭连接、保存状态。日常关闭服务应该优先用这个。SIGKILLkill -9 pid强制杀死进程没有机会做任何清理。这是最后手段不是常规手段。滥用-9可能导致数据丢失或者留下脏状态。我见过有人一杀进程就-9结果服务重启后因为之前的锁文件没清理而直接起不来。SIGHUPkill -1 pid很多守护进程把收到这个信号当作重新加载配置的指令。比如nginx -s reload本质上就是发送相关信号让 worker 平滑重启。改完配置文件想不中断服务地生效优先找它对应的 reload 方式而不是 kill 再重启。我的习惯是先pgrep -f 完整命令行关键字确认 PID再ps -p pid -o pid,ppid,cmd确认没杀错人最后才执行kill。这套三连在批量操作时尤其重要。3.3 日志查看的固定套路日志排查是常规操作里最需要套路的部分。我的固定流程是三段式第一段先定位时间范围。journalctl --since 1 hour ago或者journalctl -u myservice --since 2024-01-01 10:00 --until 2024-01-01 11:00把窗口框住。直接从头翻整个日志文件是最低效的做法。第二段按关键字过滤。grep -i error或者journalctl -u myservice | grep -i exception。如果日志量特别大我会用grep -A 20把报错后面的上下文一起打出来因为真正的根因往往藏在报错前的几行而不是报错本身。第三段用tail -f跟进实时输出。改动配置后重启服务tail -f /var/log/app/app.log能看到启动过程有没有新的报错。提示这里分享一个我自己的小技巧。排查问题时的每一条命令我都会把时间戳带上比如date %s记录发现问题的时间点再用journalctl --since精准定位。别高估自己的记忆力事后复盘时你会发现时间线才是排查问题的第一线索。4. 文本处理三件套grep、sed、awk 的常规用法4.1 grep从筛选到上下文分析grep是文本处理里使用频率最高的指令它解决的问题只有一个从一堆文本里找出我关心的内容。但常规用法里有几个细节值得注意。-E启用扩展正则这样可以用|做多条件匹配。比如grep -E ERROR|FATAL app.log一次过滤出两种级别。-v反向匹配排除不需要的内容。比如grep -v ^# config.conf可以快速去掉注释行。-r递归搜索目录。grep -r keyword /data/logs/比逐个文件搜高效得多但要注意加--include*.log限定文件类型否则会把二进制文件也扫一遍。-l只输出文件名。当你只想知道哪个文件里出现了这个关键字时加-l能省掉大量刷屏输出。-A/-B输出匹配行的下文/上文。grep -B 5 -A 10 Exception app.log是我看 Java 报错时最长用的组合。我自己的另一个习惯是给grep加上别名alias grepgrep --colorauto让匹配到的内容带颜色高亮。这个习惯很小但效率提升非常明显尤其在日志刷屏的时候一眼就能定位到关键字的位置。4.2 sed流式编辑的常规操作sed被人记住往往靠一条命令sed -i s/old/new/g file。确实全局替换是它最常规的使用场景。但除了替换我还会用到这几个删除空行sed -i /^$/d file。清理配置文件格式时很实用。按行号打印sed -n 20,30p file。想快速看文件的某一段时比cat再数行数方便得多。按范围删除sed -i /^#/d file。去掉所有以#开头的注释行。-i参数有个隐藏风险它直接修改原文件没有备份。我的做法是任何时候都写成sed -i.bak s/old/new/g file这样file.bak就是修改前的原始文件。为什么强调这个因为我真的见过有人批量替换配置文件后因为正则写错导致全文件被改废、又没有备份最后只能从版本控制里恢复的惨状。多敲一个.bak成本几乎为零收益是随时能反悔。4.3 awk分列统计的威力awk看起来最难其实常规操作就三件事按列取数据、按条件过滤、做统计。按列取数据是最常用的。awk {print $1, $NF}里的$1是第一列$NF是最后一列NF是当前行的字段数量。这个语法理解之后很多场景会变得很简单。比如ls -l的输出里文件大小是第五列文件名是最后一列想列出当前目录下所有文件大小大于 100M 的文件可以这样写ls -l | awk $5 104857600 {print $9}按条件过滤配合指定分隔符是第二个常用场景。日志文件一般用空格或者逗号分隔awk -F, {print $2}可以指定逗号作为分隔符。比如处理 CSV 格式的导出数据一列一列拆出来非常顺手。第三个是统计。去重统计最简单的方式是awk {print $1} file | sort | uniq -c | sort -rn。这条管线的逻辑是取出第一列 → 排序uniq要求相邻才去重必须先sort→ 统计出现次数 → 按次数倒序排列。比如统计 nginx 访问日志里每个 IP 的请求次数10 秒就能出结果。awk的统计能力更强比如对某一列求和awk {sum $5} END {print sum}。虽然这个例子很简单但当你面对几千行的日志时这种按列直接算的写法比写脚本快太多了。5. 网络指令排查问题时的固定顺序5.1 连通性检查从 ping 开始判断网络排查是我日常工作中比较容易慌的领域因为涉及的因素太多。但常规的检查顺序是固定的第一步永远是ping。ping -c 4 目标地址的-c参数指定发包数量不加-c的话它会一直ping下去在自动化脚本里是个隐患。判断标准很简单能 ping 通网络链路通问题大概率在更高层端口、服务、域名解析。不能 ping 通可能是网络不通、防火墙拦截或者目标主机确实不在线。这时候不要慌继续往下排查域名解析和路由。ping还有一个容易忽略的信息TTL 值。不同操作系统的默认 TTL 不一样比如 Linux 很多是 64Windows 是 128。如果你 ping 一个主机发现 TTL 是 118 左右通常说明目标主机是 Windows128 减去中间的跳数。减少的数值大致就是中间经过的路由跳数这在判断为什么延迟高时能提供线索。5.2 端口与服务ss 和 curl 的配合ping通了不代表服务可用下一步要确认端口是否在监听、服务是否能正常响应。查看端口监听状态我用ss -tlnp-t只看 TCP-l只看监听状态的端口-n不做域名解析速度快输出更干净-p显示占用端口的进程信息。确认某个具体端口时ss -tlnp | grep :8080。如果没有任何输出说明端口没在监听或者服务绑定到了别的端口。端口监听正常后紧接着用curl验证 HTTP 服务是否真的能响应。curl -I http://localhost:8080/health能快速拿到响应头判断状态码是否 200curl -v会输出详细的请求和响应过程包括 DNS 解析、TCP 连接、TLS 握手每一步定位卡在哪一步非常好用。提示检查本机服务时很多人习惯用netstat但新版系统里ss是更推荐的指令输出更快、信息更全。我的建议是尽早切换到ss别等netstat彻底淘汰了再适应。5.3 域名解析别让 DNS 问题消耗你的时间域名解析是网络排查里最容易被忽视的环节。遇到访问不了、但 IP 能通的情况优先怀疑 DNS。nslookup 域名或者dig 域名都能查解析结果。dig的输出更详细dig short直接给出解析后的 IP 列表是我日常最常用的写法。还有一个细节解析顺序由/etc/resolv.conf决定如果第一个 DNS 服务器响应慢整体解析就会变慢。排查域名解析耗时过长时可以用time dig short 域名来量化解析耗时然后对比换一个 DNS 服务器比如改成公共 DNS 或者内网自建的 DNS之后的差异。很多服务起不来的问题根源是配置里写了域名但容器或服务器上解析不了。所以我的常规建议是能用 IP 做内网通信的地方尽量用 IP用域名的地方务必确认dig能正常解析这两条做好了能避开一半的网络连接问题。6. 把常规操作练成肌肉记忆的几个习惯6.1 别名与快捷键让高频操作变成一键常规操作的效率提升我做得最多的一件事是配置别名。每个人工作场景不同别名的内容也不同但下面几个是我觉得通用性很高的alias llls -l alias lals -la alias grepgrep --colorauto alias dfdf -h alias freefree -h alias rmrm -i配置写进~/.bashrc或者~/.zshrc后执行source ~/.bashrc即可生效。这些别名没有改变命令本身的能力只是把最容易踩坑的默认行为做了修正——比如rm加-i、df和free自动用人性化单位。它们是安全的也是我推荐所有人最先配置的一批。6.2 历史命令你敲过的每条命令都是资产终端的历史记录不是给你按上下键翻着玩的它是一个可以检索的操作日志。默认的history会列出最近执行的命令配合CtrlR做反向搜索输入几个关键字就能找到之前敲过的长命令。比如你上周写过一条特别复杂的findxargs组合现在想复用CtrlR输入xargs就能找回来。我更进一步的做法是在~/.bashrc里加上这两行export HISTTIMEFORMAT%F %T export HISTSIZE10000这样每条历史命令都会带上时间戳。这个习惯的价值在复盘排障过程时尤其明显——我当时是什么时间执行了什么命令导致了这个结果有了时间戳整个操作的因果链条清晰很多。6.3 我自己常犯的几个错误最后聊几个我在实际工作中交过学费的坑给读者提个醒。第一个是管道命令的半截操作。比如ps aux | grep java之后如果你要kill这些进程千万不要直接kill $(ps aux | grep java)就完事。这条命令会匹配到 grep 自身而且输出里可能包含不相关的进程。我会先看一遍输出用pgrep -f精确定位再逐个确认 PID。第二个是find配合-exec时不先预览。前面提过任何带写操作的find指令我都强烈建议先跑一遍不带-exec的版本把即将被操作的文件列表完整看一遍。这一条救了我很多次。第三个是引号和转义的疏忽。grep keyword file里的引号看似可有可无但当你匹配的内容里包含空格、特殊符号时少了引号命令行为完全不一样。我的规则是凡是关键字里可能有特殊字符一律加引号宁可多打两个字符也不要让 shell 帮你解释关键字。把常规操作练成肌肉记忆不是让你死记硬背命令参数而是建立一个本能反应看到现象立刻想到对应的指令组合。我在实际使用中最深的体会是常规操作的价值不在于单条命令多酷而在于它们组合起来能形成一套不假思索的排查链路——从磁盘到进程从网络到日志每一环都有一两条固定的指令在等着出了问题照着链路走大概率能定位到根因。