很多人第一次接触Linux终端时都以为自己在背一本厚厚的命令手册。实际上我用了这么多年终端以后越来越觉得Linux终端常用命令行不是用来背的而是用来组合的。每条命令就像工具箱里的一个零件真正熟练的人不是记住每个命令的全部参数而是知道“现在这个场景该拿哪个零件、怎么把它跟其他命令串起来”。这篇文章不会面面俱到地罗列几百条命令而是把我这些年真正高频使用、真正能解决实际问题的命令和组合方式讲透。适合刚接触终端不到一年、想在服务器上独立完成排障和日常操作的人也适合已经会用一些命令、但总觉得效率上不去、遇到问题不知道怎么下手的读者。我会把每条命令背后的逻辑、常见误区和实战中的踩坑经验一起放进来尽量让你看完之后能直接落到实际操作里。1. 终端命令行的价值以及新手最容易忽略的底层逻辑1.1 你被困在图形界面里的真正原因我接过不少“某内部系统”的排障任务遇到过一种很典型的情况一台服务器图形化监控页面里能看到CPU红了但运维同事在网页上点来点去花了十几分钟还在找是哪个进程在跑。我那时候正好在终端里一条命令下去三秒钟就锁定了目标进程连它启动了几分钟、占了多少内存都看得清清楚楚。不是图形工具不好而是图形工具通常只给了你“平均值”和“汇总”而终端命令给的是“原始数据”。当你需要定位具体进程、具体端口、具体日志行的时候终端反而是最快的路径。这个差别在服务器环境里尤其突出——绝大多数云服务器、容器、嵌入式设备根本没有图形界面你只有终端这一条路。所以Linux终端常用命令行不是“可选项”而是真正的基础设施。新手往往卡在两个点上第一不知道命令从哪里开始学第二以为每条命令都是孤立的得单独记住。其实第一条命令只要上手了后面越用越顺。1.2 把命令当成零件把管道当成传送带我喜欢用流水线来类比终端。你输入一条命令它会产出一段文本输出输出可以接到下一条命令的输入上去中间用管道符号|连起来就像传送带把半成品送到下一个加工站点。这个模型一旦建立你就不需要死记硬背了因为所有命令的用法都遵循同一个套路有一条命令负责“取数据”有一条命令负责“加工数据”有一条命令负责“展示数据”。比如你想知道当前目录下哪个文件最大并直接看前五名这其实是三件事的组合先列文件ls再按大小排序sort最后取前五行head。中间用管道串起来就是ls -l | sort -k5 -n | head -5你不用专门记住哪条命令能“列出最大的文件”因为你已经掌握了把零件组合起来的思路。这就是终端使用能力真正的分水岭从“背命令”转向“拼命令”。后面的内容我也会反复用这个思路展开。2. 文件与目录操作90%的新手错误都发生在这里2.1 ls、cd、find、du的组合定位法文件操作是终端使用率最高的一块但越基础的命令坑越多。先说ls很多人习惯直接敲ls其实在排查问题的时候ls的信息量远远不够。我更常用的形式是ls -l ls -la ls -lht-l才能看到权限、属主、文件大小和修改时间-a会显示隐藏文件-t按时间排序-h把大小以人类可读的方式显示比如 4.0K、1.2M。排查“某个目录为什么这么大”的时候我最开始的一条命令一般是ls -lht | head -20这会立刻告诉你这个目录里哪些文件最占空间、最近有没有刚生成的异常大文件。cd看起来简单但有一个容易忽略的点cd和cd ..的区别。前者回到当前用户的主目录后者回到上一级目录。在写自动化脚本时建议显式写完整路径或用$HOME不要依赖“当前在哪个目录”。我见过不少脚本因为开发者想当然地以为工作目录固定在某个位置结果在定时任务里跑的时候找不到文件折腾了很久才发现是目录不对。脚本里加一行cd $(dirname $0)能避免这类问题但它把脚本切换到自身所在目录不是所有场景都适合核心原则是“不要假设目录”。find是我认为文件查找里最能救命的一个命令但也是最容易被误用的。基本用法是按名字找find /data -name *.log -mtime -3这条命令的意思是在/data下找所有.log结尾、三天内修改过的文件。-mtime -3非常实用因为排查问题时你通常只关心最近改动的文件不需要把所有历史文件翻出来。-size参数则用于找大文件find / -xdev -type f -size 500M 2/dev/null-xdev是限制在当前文件系统内避免把/proc、/sys之类的虚拟目录也扫进去2/dev/null把权限报错信息丢进黑洞否则你会看到满屏的“Permission denied”。这个习惯很重要终端前面的命令是用来干活的报错噪音要主动隔离。du和df经常被混淆。df -h看的是文件系统总容量、已用和可用空间du -sh /data看的是某个具体目录实际占了多大。排障时逻辑应该是先用df确认哪个分区满了再用du钻进具体目录逐层定位。我在某次处理日志清理任务时就是用du -sh /var/log/*发现某个服务的日志文件已经占了几十G然后立刻做了轮转清理。如果没有这个习惯等磁盘彻底写满再处理很多服务会直接挂掉。2.2 复制、移动与删除前的安全习惯cp、mv、rm这三兄弟是新人重灾区。先说cp我强烈建议保留属性和权限时用-acp -a /data/app /data/app_backup-a等价于-dpR它会保留软链接、文件权限、时间戳这些容易被忽略的属性。做配置备份的时候如果只用普通的cp备份出来的东西表面上一样但你改一个文件后回来恢复可能发现权限全乱了服务起不来。这种情况我至少遇到过三次后来一律改成cp -a或rsync -a。rsync更大的优势是增量同步同一个备份目录反复执行时只传变化部分速度差很多rsync -av /data/app/ /backup/app/注意末尾的斜杠。rsync对斜杠极其敏感源路径末尾有斜杠表示“复制目录里的内容”没有斜杠表示“复制目录本身”。一个不留神备份目录的层级结构就变了。mv有个很反直觉的地方它不只是在同一个目录下改名。跨文件系统的mv实际上会先复制再删除如果目标盘空间不足中间会失败。所以做大型目录迁移时不要想当然地用mv先确认源和目的在不在同一个挂载点必要时改用rsync来做更可控。rm是重灾区中的重灾区。我给自己定了一个铁律在服务器上任何情况下都不直接执行rm -rf开头且路径比较复杂的删除命令。真要删除某个目录先把命令准备好、echo出来看一眼或者先用一个安全别名替代。比如把危险目录先挪到一个临时目录mv /data/old_app /tmp/to_delete_$(date %Y%m%d)等确认无误后再清理/tmp/to_delete_*。这条习惯曾经帮某位同事躲过一次事故——他原本要删/data/project/old/结果手误删成了/data/project/因为路径里只差了一个目录层级Tab补全背了锅。所以我现在建议复杂的非空目录删除前先执行ls -la确认路径再执行删除能用mv过渡就不要直接用rm -rf。2.3 权限到底是谁在管chmod与chown的底层规则每次涉及权限问题时新手都容易崩溃。与其背权限数字表不如理解权限模型。Linux 的权限分三段属主u、属组g、其他人o每段用三位二进制表示读r4、写w2、执行x1。所以chmod 755的意思是属主可读写执行4217属组和其他人只有读和执行415。这个规则是二进制运算不是玄学。目录的执行权限和文件不同它是一个让新手极困惑的点。对目录来说x表示“能否进入这个目录”r表示“能否列出目录下的文件名”。所以一个目录只有r而没有x你是ls不到内容的只有x而没有r你能进去但看不到里面有什么。实际部署时站点目录如果被错误地设成了644而不是755Nginx 访问时就会出现 403 或 404因为进程根本无法进入目录。这类问题排查时先ls -l看目录权限往往一眼就能发现问题。chown负责改属主和属组常见用法chown -R appuser:appgroup /data/app-R表示递归处理目录时几乎必用。我见过一些人改了属主但忘了改属组结果应用能读不能写。正确的做法是chown 用户:组一起写完。还有一个容易忽视的细节当你想让一个目录被多个用户共同访问时除了属组要一致目录的权限最好设成2770前面那个2是 setgid 位会让新创建的文件自动继承目录的属组否则某个用户新建的文件属组可能变成他自己的私有组其他人就看不了。权限相关的命令还有umask它决定了新建文件默认权限。服务器上安全要求高一点的环境我会在/etc/profile或~/.bashrc里设置umask 027会让新文件默认权限收敛很多。排查“为什么新建的配置文件别人读不了”时先umask看看再想别的。3. 文本处理三剑客终端生产力的第一个分水岭3.1 grep筛选只是一半另一半是排除与计数如果说只能带三个命令去荒岛我会带grep、sed、awk。它们的共同点是从纯文本里“加工信息”在服务器排障时90% 的场景都离不开它们。grep最基本的是按模式筛行grep ERROR /var/log/app.log | tail -20但要真正用好grep不能只会这一个。实际排障时日志里可能一屏都是 ERROR真正想找的是“某个时间段内的 ERROR”。这时候我一般会在日志文件名或同一文件内配合范围信息再用grep叠加筛选条件grep 2025-06-11 14: /var/log/app.log | grep ERROR | head -50管道把第一个grep的结果交给第二个grep先按时间粗筛再按级别精确过滤。想看某类错误出现的次数时用-c参数grep -c timeout /var/log/app.loggrep的另一个高频场景是排除别忽略-vgrep -v ^# /etc/nginx/nginx.conf这条命令会过滤掉所有以#开头的注释行我排查配置时经常用它把配置文件里的有效内容单独拎出来看。配合-n显示行号grep -n server_name /etc/nginx/sites-enabled/*你会发现定位问题快很多因为可以直接根据行号跳到配置文件对应位置去检查。关于grep -r我要特别多说一句。很多人用递归搜索时直接写grep -r foo /data/这会把二进制文件也扫描进去输出一堆乱码。我的习惯是grep -rn --include*.py --include*.js api_timeout /data/code/--include限定了只看指定后缀的文件-n保留行号。搜索代码时这种方式比漫无目的地grep -r精准得多。另外grep -E是扩展正则模式当你需要同时匹配多个关键词时很有用grep -E ERROR|FATAL /var/log/app.log | grep -E 2025-06-11这基本上就是我处理多条件筛选的固定套路。3.2 sed流式编辑的替换逻辑与 -i 陷阱sed是按“流”处理文本的工具适合做替换、删除、提取行。最常见的需求是把某个配置文件里的旧版本号替换成新版本号sed -i s/1.2.3/1.2.4/g /etc/app/config.ini这里的s是替换命令g是全局替换不加g的话每行只替换第一处匹配。-i是直接写回文件这是日常使用中最容易出问题的参数——它真刀真枪地改了文件。我踩过最典型的坑是想直接用sed测试替换效果结果忘了去掉-i把配置文件改坏了。所以我现在有一条原则先用不带-i的命令做预览sed s/127\.0\.0\.1/192.0.2.10/g /data/app/config.yml | grep 192.0.2.10看到输出符合预期后再执行带-i的版本。另外macOS自带的 BSDsed和 Linux 上的 GNUsed语法略有差异macOS上-i通常要带一个空字符串参数写成sed -i -e s/a/b/g file。跨平台跑脚本的时候要么统一在容器里跑 GNU 版本的命令要么写兼容写法别想当然复制。sed还有一个高频用法是删除行。比如快速删除配置里所有以#开头的注释sed -i /^#/d /tmp/clean.conf/^#/d表示匹配以#开头的行并删除。要注意的是如果有些行前面有空格^#匹配不到得用/^[[:space:]]*#/d。这个细节我第一次用的时候忽视了结果清理完的配置里还剩一堆带缩进的注释好在预览环节发现了。sed提取区间也很有用。比如从日志中提取 12:00 到 12:05 的内容前提是时区统一且格式规范sed -n /12:00/,/12:05/p /var/log/app.log-n表示不自动打印所有行p表示只打印匹配区间的行。这个用法在按时间片段截取日志时很省事比grep更精确。3.3 awk列操作和简单统计是日常刚需awk是我觉得最“提神”的一个命令它本质上是一门单行脚本语言。初学者不需要学完整语法掌握几个最基本的模式就够用。最核心的是按列提取。默认按空白分隔$1是第一列$NF是最后一列。比如从访问日志里只提取状态码和响应时间awk {print $9, $NF} /var/log/nginx/access.log | head -10假设每行日志的格式是IP - 时间 请求 状态 字节 响应时间去掉$这种细节后你会看到状态码和耗时列被并列打印出来快速得知接口响应分布。$NF总是指向最后一个字段这个技巧在日志字段数不确定时非常实用。awk做统计也很顺手。比如统计某个接口的平均响应时间awk $7 ~ /api\/orders/ {sum $NF; count} END {print sum/count} /var/log/nginx/access.log这里的思路是当第 7 列匹配/api/orders时累加最后一列的耗时并计数文件处理完后打印平均值。说实话这种统计用 Python 写要好几行awk一行就能完成是我在终端里计算日志指标时最常用的方法。另一个高频组合是sort和uniq做分组统计。比如统计访问量最高的 IP 前 10 名awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10这条命令的每一步都值得拆开看awk {print $1}提取 IPsort把相同 IP 排到一起uniq -c统计连续重复次数sort -rn按次数降序排序head -10取前十条。这个管道从头到尾没有任何一个分支需要单独背就是零件组合法的典型应用。我处理过的某次容量问题排查就是靠这条组合命令找到来源的访问日志里某个内网 IP 半小时内请求了上百万次直接把后端服务打挂了。用awk提取来源 IP 并统计数量再结合grep找该 IP 的具体请求路径前后不到一分钟就定位到是某台机器上的定时任务脚本在死循环请求接口。如果没有把awk和管道变成肌肉记忆这个过程会慢很多。4. 进程与系统资源排查从看到到定位的真实思路4.1 ps与top先分清状态再下手服务器卡了CPU 飙高第一件事不是慌而是“看谁在跑”。ps和top是最常用的两个命令但它们的使用场景不同。ps是静态快照适合“查某个进程还在不在、是谁启的、PID 是多少”。我最常用的组合是ps aux --sort-%cpu | head -15这条命令直接按 CPU 使用率降序展示前 15 个进程。ps aux里每一列的含义分别是用户、PID、CPU、内存、VSZ、RSS、终端、状态、启动时间、命令。排障时先看%CPU、%MEM两列基本就能判断是哪类进程在异常。ps查具体进程名也有讲究我一般用ps -ef配合grepps -ef | grep -E java|order | grep -v grep注意最后的grep -v grep它把grep进程自身过滤掉防止你看到一条自己刚敲出来的命令行。这个过滤看起来是个小细节但几乎每个新手都会在这里被绕一下。top是动态视图适合持续观察。进入top后按P按 CPU 排序按M按内存排序按1查看每个逻辑核的使用率按q退出。我在排查时通常先top盯几秒确认哪个进程 PID 稳定在前排再另开一个终端用ps -p PID -o pid,ppid,%cpu,%mem,cmd --no-headers查看这个进程的完整启动命令和父进程。为什么要看父进程因为很多异常进程是某个旧服务拉起来的杀掉子进程后它还会被重新拉起真正要处理的是父进程。内存方面free -h是我必看的命令。这里有个常见误解free显示buff/cache很大有人就慌着要去清缓存。但实际上这部分内存是内核用来缓存文件数据的应用需要时会被自动回收通常不需要人为干预。真正要关注的是available这一列它代表“不用交换内存就能真实可用的内存”。如果available持续很小才需要考虑加内存或排查泄漏。4.2 kill为什么别一上来就打9杀掉一个进程最粗暴的命令当然是kill -9 PID但在实际运维里我建议你把它当成最后的手段而不是第一选择。Linux 进程之间通过信号通信kill的默认信号是15SIGTERM意思是“请优雅地结束自己”。进程收到后可以做一些清理动作关闭文件、释放资源、写好日志然后正常退出。这对服务类进程很重要。而-9SIGKILL是直接强制终止由内核杀死进程它没有机会做任何收尾工作可能留下残缺的临时文件、未写完的数据甚至破坏数据库状态。我处理过的不少“重启后起不来”的问题根源就是之前用-9杀得太猛留下了锁文件或者共享内存残留。所以正确的处理顺序是kill PID等待几秒后检查进程是否还在ps -p PID如果还在再用kill -15 PID重复发一次实在不行最后才走kill -9 PID。有些允许平滑重启的服务甚至支持用kill -HUP PID让它重新读取配置文件而不重启进程我在改 Nginx 或某些常驻服务的配置时经常用这一招先改好配置再kill -HUP 主进程PID服务不用中断就能生效。排查异常进程时还有一种情况值得留意同名进程很多直接用pkill -f orderService会把匹配到命令行的进程全杀掉。这个命令方便但杀伤范围可能超出预期。一条保险的验证方法是先执行pgrep -af orderService看清楚匹配到了哪些 PID再决定是逐个kill还是pkill。我后来养成了这个习惯以后误杀进程的次数明显减少了。4.3 systemctl与lsof服务管理、端口占用的两个高频问题现代 Linux 发行版普遍用systemd管理服务systemctl就成了日常必会命令。最常用的几个systemctl status nginx systemctl restart nginx systemctl enable nginxstatus相当实用输出里明确告诉你服务当前是active (running)还是failed还会附上最近几行日志。如果服务启动失败我一般先看systemctl status再通过journalctl -u nginx --no-pager | tail -50查看详细日志。注意--no-pager它能避免输出被分页器卡住在远程终端里尤其省心。journalctl还有两个组合参数非常出活-u指定服务名-f实时跟踪日志。排查“服务为什么又挂了”时我会开一个终端窗口跑journalctl -u order-service -f再开另一个窗口手动重启服务就能实时看到重启过程中报了什么错。这种联动的排障方式比反复敲tail -f /var/log/xxx.log和systemctl restart xxx高效很多。端口占用是另一个高频问题。我经常听到同事问“这个端口怎么起不来了” 排查第一步永远是谁能告诉我 8080 被谁占了lsof -i :8080输出里的PID和COMMAND直接告诉你是哪个进程占用。确认占用进程后按业务逻辑决定是否处理它。如果没有lsof也可以用ss -lntpss -lntp | grep 8080这两个命令的差别在于ss偏向套接字状态lsof输出更详细。我已经习惯了把ss -lntp作为默认检查项因为它速度快且不依赖额外软件包。排查服务端口问题时的完整套路是先确认服务进程活着再看端口是否监听再看防火墙规则是否放行。缺了中间任何一步都容易把“服务没起来”误判成“网络不通”。5. 网络诊断命令链按顺序执行别一上来抓包5.1 ping、ip、ss三层链路怎么逐层验证网络问题是最让人头疼的一类因为它可能发生在任何一层。我用这么多年终端的体会是网络排障一定要有顺序从低层到高层逐层验证不要一上来就抓包。第一层验证连通性用pingping -c 4 192.0.2.10-c 4表示只发 4 个包测试完自动退出不会一直卡在终端里。如果ping不通说明主机层面的网络链路有问题如果ping通但业务访问仍然失败问题大概率出在更高层。第二层验证 IP 地址和路由使用ip addr和ip routeip addr show ip routeip addr确认本机网卡有没有正确拿到 IPip route确认默认路由是否存在。某次某个容器网络异常生产环境服务一直连接不上我一开始怀疑是应用配置问题最后查了一圈才发现是容器重启后路由表缺了一条默认路由。这个层级的问题如果用ping自己测自己ping 127.0.0.1是测不出来的。第三层验证端口监听用ssss -lntp-l只看监听状态的端口-n不解析域名-t只看 TCP-p显示进程信息。这条命令一次就能看到当前服务器上到底有哪些端口在监听、对应哪个进程。如果应用监听在127.0.0.1上外部机器自然连不上——这不是防火墙的问题是服务只绑定了本机回环地址。这三层都通过了才需要往上进行应用层验证。5.2 curl与dig应用层与DNS的验证技巧应用层诊断离不开curl。它不只是“下载工具”更是我判断 HTTP 服务是否正常的首选工具。最常用的参数curl -I http://example.com/-I只发送 HEAD 请求快速拿到响应头和状态码开销极小。想看完整响应头再带个-i或-v。-L是跟随重定向排查跳转问题时很好用curl -IL http://example.com/两个参数连用会把每一次跳转的响应头都打印出来直接看清楚从访问地址到最终地址之间经历了几层重定向。某次活动页无法打开我就是靠这组命令发现配置路径经历了三次重定向、最终打到了一个 404 页面才定位到是反向代理的地址写错了。curl -w是一个被严重低估的参数它可以输出请求耗时。比如curl -o /dev/null -s -w code:%{http_code} connect:%{time_connect} total:%{time_total}\n http://example.com/-o /dev/null丢弃响应体-s静默模式不显示进度条-w自定义输出格式。这样一次请求就能同时拿到 HTTP 状态码、TCP 连接耗时和总耗时。对比不同内部节点的耗时基本能判断是网络链路慢还是应用响应慢。如果time_connect很小但time_total很大说明主要是应用处理慢如果time_connect本身很大那问题在网络链路上。DNS 问题也很常见。我查域名的第一选择是dig没有它也可以用nslookupdig example.com A shortshort让输出只显示解析结果简洁明了。如果dig解析出来的是旧 IP多半是 DNS 缓存或记录更新没生效。排查“域名能 ping 通但访问不了”时先确认解析结果和你预期的一致再往下一层排查连通性。另外不要忽略curl -H Host: example.com http://192.0.2.10/这种用法它可以绕开 DNS 直接指定 IP 请求同时通过 Host 头模拟域名访问非常适合在 DNS 未生效时提前验证后端服务是否正常。5.3 tcpdump什么时候才需要它以及怎么快速抓tcpdump是抓包利器但它不是第一排查工具。真正需要它的时候是前面所有命令都查不出原因、你怀疑问题出在异常的数据包层面的时候。比如连接频繁被重置、响应内容被截断这种时候抓包能提供最直接的事实。基本用法是抓某个端口上的流量tcpdump -i eth0 port 8080 -c 100 -w /tmp/capture.pcap-i指定网卡port 8080过滤端口-c 100抓满 100 个包自动停止-w把原始包保存为文件。抓完以后可以用 wireshark 打开分析也可以直接在终端里看文本摘要tcpdump -i eth0 port 8080 -n-n不解析域名和端口名输出里能看到源地址、目标地址、TCP 标志位。我曾经排查过一个“连接被间歇性重置”的问题curl 单测时成功率不稳定用tcpdump -n抓了几十秒后发现对端 IP 周期性地发送 RST 包最终确认是中间链路设备的空闲连接老化策略导致的而不是应用代码的问题。用tcpdump有几个实用技巧第一尽量精确指定端口和主机减小抓包量和噪音第二-c限制抓包数量避免一直抓下去第三写文件比直接看输出更有利于后续分析特别是抓包数据量较大的时候。对于普通排障场景抓包时间控制在几十秒内就足够了别让它跑成后台任务。6. 把命令连起来用的提效技巧一条命令干完一天的活6.1 管道、重定向、tee信号在终端里是怎么流动的到了最后一个部分我觉得最重要的反而是“连接能力”。单条命令解决单点问题但真正让你工作效率翻倍的是把多条命令接到一起。管道|是终端最核心的加工方式。它把左侧命令的标准输出接到右侧命令的标准输入实现数据在命令之间的流动。我上面已经用过很多次管道这里想强调的是重定向的细节。是把输出写入文件并覆盖是追加2是单独处理错误输出21是把错误输出并到标准输出里。这在跑脚本、留日志时非常关键./deploy.sh /tmp/deploy.log 21这条命令会把脚本的正常输出和错误信息全部写进同一个日志文件。如果不写21错误信息可能只在终端闪现一下等你回头查看日志时会发现少了一半信息。tee是我最近几年越来越离不了的一个命令。它同时把数据写到文件并继续往管道下游传递grep ERROR /var/log/app.log | tee /tmp/errors.txt | wc -l这样既能把错误日志存档到/tmp/errors.txt又能继续统计行数。排查问题时我经常用tee保留中间结果方便稍后回头查看而不必重新跑一遍前面的命令。使用管道时还有一个很容易被忽视的细节管道里每一条命令的退出码并不完全对等管道的退出码默认是最后一个命令的退出码。所以如果你想确认中间某条命令是否成功可以在脚本里开启set -o pipefail让管道中任何一个环节失败都算整体失败。这个设置在排查脚本问题时帮了我不少忙避免出现“前半截失败、后半截还在继续处理空数据”的隐性错误。6.2 xargs与history批量处理和历史复用批量处理文件时xargs是管道和耗资源操作之间的桥梁。很多命令不接受标准输入作为参数比如rm在需要删除大量文件时不读管道输入这时候xargs把管道输出的每一行转换成命令的参数find /tmp -name *.tmp -print0 | xargs -0 rm -f这里有一个极其重要的细节find -print0搭配xargs -0是一个安全组合。因为文件名里可能包含空格甚至换行默认按换行分隔会把一个文件名拆成两段导致误删。-print0和-0都用空字符作为分隔符就能安全处理任意文件名。凡是用find搭配xargs做批量删除我只建议这一种写法。xargs -n1是另一个常用选项表示每次只传一个参数。比如想逐个查看一批文本文件的行数find /data/config -name *.conf | xargs -n1 wc -l如果不加-n1xargs可能一次性把所有文件名都传给wc虽然结果一样但当文件数量极大时可能触发命令参数长度上限分批执行更稳妥。再说history。终端用久了你会发现自己很多命令是重复的。历史记录不只是用来看的还可以直接复用和搜索。最顺手的操作是Ctrl R进入反向搜索模式输入几个关键字就会匹配到最近执行过的相关命令。如果有条命令今天已经敲过三次下次执行时我一般会先按Ctrl R搜索而不是再敲一遍长命令。批量导出历史命令也可以用来整理自己的常用命令列表history | awk {$1; print $0} | sort -u这会把历史记录去重后输出。偶尔我会从里面发现自己其实经常用到某些命令的组合就会把它提炼成脚本或别名固化下来。6.3 别名与一键巡检把常用套路固化成肌肉记忆最后聊聊效率的终点把常用的长命令固化成短别名。在~/.bashrc或~/.zshrc里写上一行alias以后再敲几个字母就能执行一长串命令。我自己的服务器上长期保留着这几个别名alias llls -alF alias portsss -lntp alias errlogtail -f /var/log/syslog | grep -i error alias diskdf -h | sort -k5 -n不要小看这些别名它们把“打开终端后最容易敲错的命令”变成了“符合直觉的短单词”。我建议每个人都可以从自己的排障过程里提取高频命令做成别名。不过要注意别名不要定义得太花哨否则换个环境比如换一台新服务器你的肌肉记忆会失效。最好把别名定义放到一个单独的配置文件里比如~/.bash_aliases并在.bashrc里引用它这样迁移环境时只需拷贝一个文件。再进一步可以把一组固定检查流程写成一个简单的 shell 脚本命名为diag.sh#!/bin/bash echo 磁盘 df -h | sort -k5 -n echo 内存 free -h echo 负载 uptime echo 端口 ss -lntp | head -10 echo 最近错误日志 journalctl -p err -n 20 --no-pager | tail -20脚本写完后再chmod x diag.sh放到/usr/local/bin/下以后任何一台机器出问题先执行diag.sh就能迅速拿到基础状态快照。这个脚本是我自己长期实践的总结坦白讲它比很多监控平台的截图在排障初期更有用因为你得到的是完整的事实列表而不是一张被缩放过的曲线图。我自己这些年用下来的体会是终端的强大不是某个命令多神奇而是你能够用最少的步骤拿到最准确的事实。多敲几次把这些组合方式变成肌肉记忆遇到服务器出问题时你就会发现从前那些让人手忙脚乱的排查过程其实只需要一个终端窗口和几条命令而已。