1. 开篇为什么你背了一堆Linux命令上了服务器还是发懵第一次接触Linux的时候我也干过这种事买了一本厚得像砖头的命令大全从ls背到tar每一页都抄过笔记每个参数都拿小本本记。结果真正被扔到一台CentOS服务器前面部署一个应用时整个人是懵的。文件该放哪个目录、环境变量怎么配、服务起不来怎么查日志脑子里那些命令全都对不上号。后来带过几届实习生发现大家踩坑的路径惊人一致不是命令不够熟而是不理解命令背后的逻辑以及命令和命令之间怎么串联。所以这篇不打算做成Linux命令字典。网上随便一搜都能找到几百条命令的列表但看完、背完、再忘完这个过程没啥意义。我想换一种方式把我们平时在命令行里真正高频使用的命令按照你要解决什么问题来重新组织一遍同时把那些教程里从来不写、但实际工作中天天踩的坑一并讲清楚。内容主要覆盖这些方向文件与目录操作、文本内容处理、权限与用户管理、进程与系统监控、网络排查、管道与重定向这六大块。适合三类人看第一次接触Linux想系统入门的新人能敲几个命令但组合起来就卡壳的初级运维或开发准备Linux面试或考试想找一份全链路实战梳理的人。每一部分我都会讲几个实际场景带着命令一起过一遍而不是干巴巴列语法。另外我还会穿插一些老手才懂的小习惯和隐患比如为什么不要随手rm -rf、为什么生产服务器上少用vim直接改配置文件、通配符一不小心会把文件删到什么程度。2. 理解Linux基本指令先打通这四大底层认知2.1 一切皆文件不是哲学是做事方法在任何一本Linux入门书里你都会看到一句话一切皆文件。四个字很容易背但很多人不知道它到底怎么指导我们敲命令。在Linux里磁盘分区是文件/dev/sda键盘输入是文件/dev/stdin屏幕输出是文件/dev/stdout网络数据包是文件socket进程信息也以文件形式暴露在/proc目录下。这意味着什么意味着你处理文件的那套命令可以用来处理很多其他东西。举个例子。你要查看CPU信息不用装任何工具直接cat /proc/cpuinfo想知道系统开机时间和运行时长cat /proc/uptime甚至某个进程的启动命令行cat /proc/PID/cmdline。这些都不是传统意义上的文件但你都用读文件的方式拿到了数据。理解了这一层后面我们再讲重定向、管道时很多操作你就能想明白了既然一切都像文件那就能用文件系统的规则去操作它。2.2 命令行的本质是对话不是背题对新手来说命令行像考试得答对了才给分。其实完全不是。命令行是一个对话过程你输入一段指令系统给你一段反馈反馈看不懂就再问比如用echo $?问上一个命令是否成功用man问说明书用which问命令本体在哪里。它的交互逻辑更像你在和一个知道很多但话很少的助手交流。这个对话思路一旦建立你就不需要背命令了你只需要记住我想干什么然后用几个关键词去凑。比如我想看有没有某个进程在运行那大概率是ps加上grep组合我想知道磁盘哪里满了那大概率是df -h。这些目的到命令的联想比命令到参数的记忆重要得多。2.3 权限模型决定了你60%的运维麻烦Linux是一个多用户系统权限模型从设计之初就是防君子不防小人但它的严谨程度远超Windows早期的习惯。每个文件都有三组权限分别是属主user、属组group、其他人other每组有读r4、写w2、执行x1三个位。平时你写的是chmod 755这样的三个数字其实就是在给这三组权限赋权7421541。我见过不少新人在权限上花掉大量时间文件能看不能改脚本能读不能执行目录能进不能建文件。尤其是目录的权限很多人会忽略执行权限x意味着能否进入这个目录。一个只有r权限的目录你能列出文件名清单但cd不进去。这种特性在部署web项目时非常常见。2.4 组合与管道才是基本指令的真正威力单条命令的能力是很有限的。但Linux命令设计之初就遵循一个工具解决一个小问题的哲学然后用管道|把它们组合成强大的数据流处理链。cat access.log | grep ERROR | sort | uniq -c | sort -rn | head -20这一串就能从一堆服务器日志里统计出出现频率最高的20条关键错误。新手看到这么长的复合命令会害怕不知道怎么读。读法是从前往后分段理解先把日志内容读出来再筛出ERROR行再排序再统计次数再倒序排列最后只取前20行。每一段都是独立的小步骤合起来就是一个完整的处理流水线。这也是为什么我建议你先老老实实把每个单独命令练熟再玩组合。地基不牢玩管道就是灾难。3. 文件与目录操作最常用指令群的实战拆解与避坑3.1 目录导航与文件查看ls、cd、pwd很多人觉得ls不用学看一眼就懂了。但实际工作中ls的参数组合能省你大量时间。我的个人习惯是ls -l查看详细属性权限、属主、大小、修改时间ls -a显示隐藏文件。注意隐藏文件是以.开头的文件但它只是个约定不是多安全的保护ls -lhh表示人性化显示文件大小K/M/G不带h的时候看到一串字节数会算到你头疼ls -lt按时间排序。排查刚改过哪些配置文件或者哪个日志还在更新时非常好用$ ls -lht /var/log/ total 32M -rw------- 1 root root 28M Jun 10 23:45 syslog -rw-r----- 1 root adm 11K Jun 10 23:40 nginx -rw-r--r-- 1 root root 3M Jun 9 20:15 kern.log能看出什么syslog刚刚还在写系统确实有日志活动。这在判断服务是否还在运行时是个很敏锐的信号。cd有几个细节容易被忽略。一是cd -回到上一次所在的目录在两层目录间来回切换时非常高效。二是cd ~和cd都是回当前用户的家目录但要注意如果你用了sudo家目录可能跳到root那边去因为sudo默认会重置环境变量。我在给用户配置环境时经常发现明明改了~/.bashrc怎么没生效原因就是这个。pwd返回当前目录路径看起来太简单但有两个场景很关键。一是你在很深的目录层级里迷路时pwd能告诉你现在在哪二是写完脚本后如果脚本里用了相对路径执行时跑出预期外的结果第一件事就是pwd确认当前路径。很多脚本事故排查到最后都是我以为在那个目录其实不在。3.2 创建、复制、移动与删除mkdir、cp、mv、rmmkdir创建目录常用-p递归创建省得一层层建。比如mkdir -p /data/logs/nginx不管/data是否存在一次性搞定。这点在写部署脚本时几乎必用。cp复制文件或目录最常用的是cp -r递归复制目录、cp -p保留权限、属主和时间戳。创建软链接用ln -s它不复制数据只生成一个指向原文件的快捷方式这在目录迁移、版本切换比如把current软链指向v2.3.1目录时非常常用。先别急着复制粘贴我先说一个我交过学费的坑cp默认不保留属性。有时候你从一台机器拷贝一个配置文件到另一台结果服务起不来排查一圈发现权限不对。因为新文件的属主变成当前用户了。所以跨机器、跨用户拷贝时习惯性带上-p甚至用rsync -av代替cp它在保留了权限和时间戳的前提下还支持增量同步。mv移动或重命名文件。大部分人都知道它的功能但可能没想过mv也是原子性操作。在同一个文件系统内mv几乎瞬间完成因为本质上只是改了目录项。所以在需要替换线上正在使用的文件时优先用mv把旧文件挪走、再放新文件会比直接覆盖更安全这也是很多发布脚本的核心思路。接下来是重点中的重点rm -rf。我必须把话讲得很重不要在重要目录下随手敲rm -rf尤其不要敲rm -rf /这种带根路径前缀的、以及带通配符的组合。网上因为这些命令删库删盘的案例数不胜数。# 危险指数五颗星 rm -rf /var/log/*.log # 如果变量没赋值可能变成 rm -rf /var/log/为什么会这样如果脚本里写了rm -rf ${LOG_DIR}/*而这个变量因为某种原因没取到值比如拼错了环境变量名那命令就变成了rm -rf /*。这是真实发生过的生产事故。我的经验是删除前先ls展开通配符确认删除范围重要数据用mv移到临时回收目录比如/tmp/trash_$(date %F)观察几天没问题再清理能用find ... -delete的明确指定路径再删3.3 文件类型与查找file、which、find、locatefile命令能告诉你这个文件到底是什么类型。虽然光看扩展名也能猜但Linux里扩展名更多是给人看的约定。比如你拿到一个文件叫data.binfile data.bin可能会输出gzip compressed data原来它是个压缩包。which用于查找可执行命令的位置比如which python3返回/usr/bin/python3。它只搜索PATH环境变量里列出的目录。有时候你执行python3和/usr/bin/python3效果不同多半是PATH里前面某个目录里还有一个同名程序which -a python3可以看到全部结果。find是文件查找的主力功能非常强。我平时用得最勤的组合find /data/logs -name *.log -mtime -7 # 查找/data/logs下7天内被修改过的log文件 find / -type f -size 500M 2/dev/null # 查找整个系统大于500M的文件错误信息丢弃-mtime是按天追踪-mmin可以精确到分钟测试环境验证某个配置变更是否落盘的时候很有用。find配合-exec或管道可以批量操作但要小心批量命令用错了造成连带伤害。新手上路阶段我建议先用find ... -name ...结合-printf或ls -lh确认一下目标范围再去做删除或修改动作。locate命令基于数据库索引查找速度比find快得多但数据库不是实时更新的新创建的文件可能查不到。如果系统刚装完先updatedb更新索引。如果locate不在系统里说明没装mlocate或plocate包装一下就行。4. 文本查看与处理指令日志排查和高频操作的真正主力军4.1 查阅文件内容cat、less、head、tailcat适合查看小文件。直接在终端把整个文件内容吐出来。文件一大屏幕就会刷屏根本停不下来。这时用less更合适。less启动后不会一次性加载所有内容滚动查看非常丝滑而且支持/搜索关键字按n跳到下一个匹配项再按q退出。排查一个几百MB的大日志文件less几乎是必备工具。head和tail刚好是一对一个从头看一个从尾看。tail可以说是运维排查中使用频率最高的命令之一tail -n 50 /var/log/nginx/error.log # 查看最后50行 tail -f /var/log/nginx/error.log # 持续跟踪文件新增内容-f会保持阻塞状态文件有新内容就实时打印出来。排查线上问题时开一个终端tail -f盯着日志另一个终端复现问题操作日志像流水一样滚出来哪里报错一目了然。如果日志文件被轮转切割了比如变成了error.log.1tail -F大写能自动追踪新生成的文件这个区别在实际生产环境中很重要。head除了看文件开头还经常和管道配合用来限制输出量。比如ps aux | head -10只看前10行先确认进程列表的列名再往下翻。head -n 100 file.txt配合输出重定向可以从大文件里切出前100行生成一个测试用的迷你样本。4.2 搜索过滤grep真的是最常用的命令之一grep按模式匹配行然后把匹配到的行打印出来。最简单用法grep 404 access.log但实际工作中基本都是带参数使用的最常用的几个参数grep -i忽略大小写日志里大小写混着的时候很有用grep -v反向匹配排除掉某些噪音行比如grep -v ^#查看配置文件时去掉注释行grep -r递归搜索目录下的所有文件源码里找一个函数定义很好使grep -n显示行号定位代码、定位配置文件时必备grep -E扩展正则表达式支持更复杂的模式给你一个真实场景。生产环境报错提示某个服务配置无效。我第一反应是去配置目录里搜所有包含invalid或error的文件grep -rn -E invalid|error /etc/myapp/一条命令问题范围就从整个配置目录缩小到具体文件和行号。接着就能进入下一步精准修复。新手常犯的错是忘记-n看到匹配内容却不知道在哪个文件第几行排查效率直接砍半。另外grep匹配的是行不是词如果一行里有一万个字符它会把整行都打出来所以经常看到输出一大串。这时可以用grep -o只看匹配到的部分输出会干净很多。4.3 排序、去重与统计sort、uniq、wcsort按字典序或数值序排序。其实光排序本身没有太大意义它真正的威力是配合uniq做统计。这里有个必然顺序必须先提一下先排序再去重。因为uniq只会把相邻且相同的行合并如果相同内容没排到一起它就识别不出来。你如果直接cat file | uniq -c统计结果大概率是错的。看一个让我印象很深的场景。某天线上接口突然超时需要快速确认是不是某个客户端IP在疯狂访问。一条命令就能出来awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这就是典型的处理流水线取第一列IP地址 - 排序 - 统计每个IP出现次数 - 按次数倒序排列 - 取前十名。整个排查过程只需要几秒钟比任何可视化工具都直接。wc用来统计行数、字数、字节数wc -l统计行数可以说最常用。判断一个文件是否为空wc -c看字节数是否为0、统计日志总共多少行、确认导出数据条数是否符合预期全靠它。4.4 流式文本处理三剑客sed、awk简短介绍sed和awk在系统学习中常常被列为进阶内容但它们其实没那么可怕。我建议新人先各掌握几个高频用法不贪多。sed最实用的是替换和删除sed -i s/old/new/g file把文件里的旧文本全局替换成新文本-i表示直接修改原文件。很多配置批量修改比如把所有URL的http改成https都是靠它。awk最实用的是按列提取和统计awk {print $1}取第一列awk {sum $1} END {print sum}对第一列求和。如果你会了cut、grep、sort、uniq这几件套暂时用awk也能凑合等到你真正需要复杂处理时再回来系统学awk也不迟。4.5 比较文件差异diffdiff用来逐行比较两个文件内容差异尤其适用在我改了配置但不知道改了哪里的场景。我在更换Nginx配置时习惯先备份旧配置再用diff看新旧差异确认无误后进行替换diff nginx.conf.bak nginx.conf输出里会标注哪些行是旧文件独有的开头、哪些是新文件独有的开头一目了然。对比两个目录差异可以加-r参数递归执行。虽然现在很多编辑器有可视化对比功能但服务器上没有图形界面的时候diff仍然是最可靠的工具。5. 权限、用户与进程管理真正区分会敲命令和会管理服务器的分水岭5.1 权限修改chmod、chownchmod用于修改文件或目录的权限。两种写法都要会数字法chmod 644 file符号法chmod ux script.sh给属主加执行权限我推荐先把数字法吃透因为它在脚本里、文档里出现最多看到644、755、600能立刻在脑内翻译成权限位这才算真正理解了。举个例子644是文件拥有者可读写、组和其他人只读这是普通数据文件的标配755是拥有者可读写执行、其他组和人都可读可执行这是脚本和可执行程序的标配600是只有拥有者可读写这是私钥文件和敏感配置文件的标配。这里有一个大多数教程不会细讲的点建议把默认umask记在心上。umask决定新建文件的默认权限。通常情况下新建文件默认644新建目录默认755。如果你新建脚本后发现没有执行权限不是配置错了而是默认规则就是这样。想让它直接可执行要么创建后chmod x要么用umask调整默认值但不建议图省事把umask改成太宽松的值。chown修改属主和属组。用法很简单但有一个重要禁忌不得随意对系统文件使用chown。比如chown -R myuser /usr/bin这种操作会让系统命令的属主变成普通用户尽管权限位可能看起来没问题但在安全模型严格的环境下就是一个隐患某些应用还会因为校验属主失败而罢工。我踩过一个坑项目部署后静态资源无法访问排查了半天发现自己把整个/var/www/html都chown -R成某个普通用户但Nginx进程是以www-data用户跑的权限对不上当然403。所以chown的目标不光是让某个用户能操作还得考虑实际运行进程的用户是谁。5.2 用户与用户组管理useradd、usermod、passwd、userdel创建用户是运维基本功但新手经常被各种参数折腾到怀疑人生。先记住一条不要用useradd的默认值直接建用户。不同发行版默认行为不一样有的不会创建家目录有的不设置密码设置为锁定状态有的不指定shell。如果你直接useradd zhangsan创建出一个登不进去的账户那多半就是因为这些默认值没配好。常用一条比较稳妥的建用户命令useradd -m -s /bin/bash -G wheel zhangsan-m创建家目录-s /bin/bash指定登录shell为bash否则可能默认是/sbin/nologin用户无法登录-G wheel把用户加入管理员组在某些发行版中该组才允许sudo有些系统管理组名是sudo注意区分用getent group查一下最保险然后再执行passwd zhangsan设置初始密码。密码强度不该太弱尤其是生产服务器弱口令被爆破的代价你可能不想体验第二次。usermod用于修改已有用户信息。usermod -aG docker zhangsan把用户追加到docker组-aGappend group比直接-G要稳妥因为-G会覆盖原有附加组列表很容易把用户踢出关键组。一个真实的小事故某同事为了把用户加入某个组用了usermod -G结果用户从wheel组里消失了sudo权限全部失效最后还是root重新加回去的。userdel -r username删除用户并删除家目录。删除用户之前记得确认该用户没有残留运行的进程。如果用户还在跑着服务直接删账户会留下属于该UID但找不到账号名的孤儿文件。5.3 查看进程ps、top、htopps是静态快照用的时候几乎永远加aux参数ps aux。输出中每一行是一个进程PID是进程号%CPU和%MEM是资源占用COMMAND是启动该进程的命令行。排查哪个进程占用了大量CPU时第一反应就是ps aux --sort-%cpu | head -10。top是动态实时视图刷新显示当前系统负载最高的进程。按P按CPU排序、按M按内存排序这在系统卡顿时非常好用。但我得提醒一句top看到的数值是瞬时值不是持续趋势尤其是多核CPU系统上某个进程单核跑满100%在top里可能只显示100%而不是400%或800%容易误判为没占满。要精确一点看ps aux里的累计CPU时间更靠谱。htop是top的增强版界面更友好可以鼠标操作支持进程树形显示还能量化显示CPU核心。如果系统装了htop我建议直接用。没装就apt install htop或yum install htop一条命令的事回报远大于成本。5.4 管理进程生命kill、pkill、killall先从概念上讲清楚kill的参数是进程号不是程序名。比如kill 1234就是给PID为1234的进程发送一个信号。默认信号是SIGTERM15相当于礼貌地请进程结束让它清理现场。如果进程不响应才用kill -9 1234相当于强制终止。我强烈建议按先15后9的顺序来不要一上来就-9有些程序比如数据库在收到SIGTERM时会做事务回滚或状态保存直接SIGKILL可能导致数据不一致。如果不知道进程号就不会用kill所以先ps aux | grep 进程名或pgrep -l 进程名找到PID。pkill和killall允许直接按名字杀进程比如pkill -f java会结束所有命令行里包含java的进程。但正因为匹配范围更宽误杀风险也高你可能只想杀某个Java应用结果把所有Java进程都带走了。所以我默认还是ps先查PID再kill。只有在批量重启同一类型进程时才会用pkill。kill -0 PID也是一个隐藏技巧它不是杀进程而是检查进程是否存在用于脚本中的存活判断。5.5 后台任务与日志输出nohup、、重定向用命令行启动一个长时间运行的服务时最大的问题是关闭终端服务就跟着没了。这是因为进程收到了挂断信号SIGHUP。解决方案就是nohupnohup python app.py app.log 21 nohup忽略挂断信号让进程不随终端关闭而死 app.log把标准输出重定向到日志文件21把错误输出也合并到标准输出里确保日志都写进同一个文件末尾的把进程放到后台执行很多新人第一次跑nohup会忘记21结果程序正常输出虽然写进了日志程序的报错信息还是直接吐在终端上等你关终端后错误就丢了最后只能干瞪眼。这条口诀我每次讲都会重复一遍标准输出和错误输出是一体两面排查问题只留一半信息等于盲人摸象。6. 系统信息、磁盘与网络排查线上出问题时你最需要的生存指令6.1 系统状态总览uname、uptime、free、df、du一到线上问题排查第一件事永远是搞清楚:这台机器现在到底是什么状态系统什么版本、内核有没有特殊修改、开机多长时间、负载高不高、内存剩余多少、磁盘空间够不够、哪个目录膨胀了。uname -a输出系统全部内核版本信息cat /etc/os-release看发行版信息这是判断该用apt还是yum装软件包的依据。uptime显示系统运行时间、已登录用户数和最近1分钟、5分钟、15分钟的负载平均值。如果1分钟负载超过5分钟负载说明系统正在变忙如果15分钟负载一直高企说明压力是持续的。free -h是看内存最常用的命令-h让数值以可读单位显示。这里有一个常见误区很多人看到free输出里的used很高、free很低就以为内存不够了。但实际上Linux会尽量用空闲内存做文件缓存buff/cache这些内存在应用需要时是可以释放的。真正的内存水位要同时看available一列它会扣除不可能被拿回的缓存才是应用真正能用的内存量。df -h查看每个挂载点的磁盘用量。排查磁盘满了问题时先用它定位哪个分区满了再配合du -sh *逐层定位膨胀的目录。du的-sh参数是汇总单个目录总大小不加-s会输出目录下每个子目录的大小信息量太大反而不好看。排查磁盘占用的标准动作是df -h看到/使用率接近100%后立刻cd / du -sh * | sort -hr | head -20一步到位找出占用最大的目录。曾经有个线上服务异常查到最后是Nginx的access.log单文件长到了90多G——那台机器一共才给了100G磁盘。日志文件的增长速度被低估是生产环境非常普遍的翻车原因。6.2 网络连接与端口排查ping、ss、netstat、curl判断网络通不通第一反应是ping。但要注意ping通只说明ICMP协议可达不代表目标端口开放两者是完全独立的事情。比如我可以ping通一个IP但它的80端口是关闭的。所以更接近业务的检测方式是直接测端口ss -lntpt指TCP、n表示不解析服务名、l仅显示监听状态、p显示对应的进程。这是Linux上取代netstat的新版命令输出简洁清晰如果你在一台较新的服务器上敲netstat没反应大概率是没装netstat包但ss一定在。常见的排查链路# 1. 确认端口监听状态 ss -lntp | grep 8080 # 2. 确认本机进程 ps aux | grep java # 3. 确认服务可用性 curl -v http://127.0.0.1:8080/healthcurl命令几乎是万能探测工具。它可以发送HTTP请求、查看响应头、测试API接口、甚至下载文件。调试接口时我最常用curl -i包含响应头和curl -X POST -d {k:v} -H Content-Type: application/json来构造POST请求。很多新人会用浏览器或专门的接口调试工具但服务器上没有图形界面时curl是唯一的选择。这不算什么高深技术但确实能在关键时候救命。6.3 查看实时日志journalctl、dmesg现代Systemd系统上日志管理统一交给了journalctl。journalctl -u nginx.service查看某个服务全部日志journalctl -u nginx.service -f实时跟踪journalctl -u nginx.service --since 1 hour ago只看最近一小时。和直接看/var/log/下的文本日志相比journalctl的好处是结构化、带时间戳、自动关联服务。如果服务起不来第一梯队排查命令就是systemctl status nginx接着就是journalctl -u nginx基本能把八成问题定位到。内核日志用dmesg查看。硬件故障、磁盘坏道、OOM内存耗尽杀进程、网卡断连等内核级事件只有看这里才能发现。有一次我排查一台服务器频繁重启普通应用日志完全正常直到dmesg | grep -i oom才发现是内存不足导致内核把某些进程杀了。这类问题在应用层面几乎无解必须靠内核日志才能定位。6.4 软件包管理apt与yum不同发行族用不同的包管理器Debian系用aptRHEL/CentOS系用yum新版本是dnfArch系用pacman。虽然包管理器不同但底层逻辑都差不多更新索引apt update/yum check-update安装软件apt install nginx/yum install nginx删除软件apt remove nginx/yum remove nginx查找软件apt search nginx/yum search nginx新手经常忘掉的一步是装包前先更新索引。这就好比去菜市场前先看一眼今天的价格表你不更新索引系统可能拿着过期的包列表去装软件经常遇到404 Not Found或版本很旧的问题。另外任何涉及内核、系统核心组件的更新在生产环境最好评估后分批执行不要一口气全量升级。我在测试环境玩坏过好几次系统原因都是没看更新列表就直接upgrade结果新内核和旧驱动发生冲突。7. 管道、重定向与环境变量从敲命令跨到写脚本的那道门槛7.1 重定向、、2、21重定向说白了就是把原本输出到屏幕的内容改写到别的地方。是覆盖写是追加写2是把错误输出重定向到文件。使用上就一条纪律覆盖写之前三思。因为一旦覆盖原文件内容就没了没有回收站。我写脚本时会刻意用做日志追加用的场合非常谨慎。21的解释要多说一句它把文件描述符2错误输出重定向到文件描述符1标准输出当前所指向的位置。所以 app.log 21的书写顺序很重要得先让标准输出去app.log再让错误输出跟着标准输出走。如果顺序写成21 app.log错误输出会指向原来的终端而不是日志文件这在脚本里是个经典陷阱。7.2 管道| 与 xargs管道的语义是把前一个命令的标准输出当作后一个命令的标准输入。它组建的数据流处理流水线前面已经讲了很多例子这里提一个细节并不是所有命令都喜欢管道喂进来的数据。比如rm、cp这些命令默认不接受标准输入它们需要的是命令行参数。这时候就要请xargs出场了find /tmp -name *.tmp | xargs rm -fxargs会把输入转成命令行参数再传给rm。xargs有-0参数配合find -print0处理文件名中包含空格、换行符等特殊字符的场景否则文件名一含空格xargs就会错乱切割。这种低级但致命的bug很隐蔽测试文件名都是常规字符时永远测不出来。有一个大原则能用find ... -delete替代find | xargs rm的场景就用find自带的-delete少一个环节就少一个出错的可能。7.3 环境变量与PATHecho、export、source环境变量是给进程用的全局参数。最常见的就是PATH它决定了你敲命令时系统去哪里找可执行文件。echo $PATH查看当前PATH的值输出是一长串用冒号分隔的目录列表。如果你装了一个新工具命令却提示command not found多半是它的安装目录没加进PATH。临时给当前终端设置环境变量用exportexport MYAPP_HOME/opt/myapp但这样设置是临时的终端关了就没。想永久生效把它写进用户家目录的~/.bashrc或~/.bash_profile然后source ~/.bashrc让配置立即生效。新手经常掉进一个坑改了~/.bashrc后忘了source在同一个终端里执行命令依旧是旧值于是怀疑配置不对。source就是把改完的配置重新加载一遍让当前会话读到新值就这么简单。说到source顺便提一下执行脚本的三种方式差异bash script.sh子进程执行不改变当前进程环境、./script.sh需要有执行权限和source script.sh当前进程执行可以改变环境变量。如果想通过脚本修改当前终端的环境变量必须用source。7.4 查看历史与复用指令history、!、CtrlRhistory能列出当前用户敲过的历史命令配合grep检索很高效。比如你不记得上次启动服务的完整命令参数了history | grep nginx就能找回来。!1024可以重跑历史中第1024条命令。但我更推荐CtrlR反向搜索按下后输入关键字命令行会自动匹配最近一条包含该关键字的命令再回车执行。这个习惯养成后效率提升是肉眼可见的。这里有一个安全意识要单独提不要在终端明文输入数据库密码、API密钥等敏感信息因为history会把它记录下来。临时需要的话用环境变量或交互式输入的方式避免敏感信息留在历史记录里。虽然这只是个习惯但安全习惯就是靠这种细节养成的。8. 综合实战一个从零到一的线上部署排查全流程理论讲再多都不如完整走一遍流程让人更有体感。我模拟一个非常常见的场景在一台全新的Ubuntu服务器上部署一个简单的Python Web应用然后中间故意留一个服务起不来的故障演示完整排查过程。8.1 第一阶段系统信息确认与环境准备拿到一台新服务器不要急着装东西先系统盘查# 确认系统版本决定包管理器 cat /etc/os-release # 确认内核不同内核版本可能影响某些软件的兼容性 uname -a # 确认磁盘是否充足最容易被忽略装到一半报no space left会很尴尬 df -h # 确认内存水位 free -h如果磁盘剩余不到20%我会先清理apt缓存apt clean再检查/tmp下有没有残留大文件避免中后期磁盘告警。8.2 第二阶段安装Python与虚拟环境Ubuntu一般自带python3但自带的版本可能偏旧而且直接在系统层面pip装包容易污染全局环境。我的惯例是装python3-venv为每个项目建一个独立的虚拟环境apt update apt install -y python3-pip python3-venv # 创建项目目录 mkdir -p /opt/myapp cd /opt/myapp # 创建虚拟环境 python3 -m venv venv # 激活虚拟环境 source venv/bin/activatesource venv/bin/activate成功的话命令行提示符前面会出现(venv)标记。很多新手在这一步后依然发现pip装的包不生效原因就是没注意这个标记以为自己已经在虚拟环境里了。8.3 第三阶段启动服务并碰壁写一个最简单的Python Web服务用Flask或内置的http.server都行然后启动python app.py app.log 21 过几秒用curl试探curl http://127.0.0.1:8000/health结果卡住迟迟不返回。按照我们的排查链路走一遍# 1. 进程到底起来没有 ps aux | grep python # 2. 端口有没有在监听 ss -lntp | grep 8000 # 3. 日志里有没有报错 tail -n 30 app.log一看app.log恍然大悟Error: [Errno 98] Address already in use。原来8000端口已经被别的进程占了。到这里这条链接的至少有以下几个系统提示第一进程不存在但端口被占说明是别的进程在监听第二用ss -lntp可以直接看到占用8000端口的进程是谁第三kill掉那个进程后再重新启动服务。这里要插一句Address already in use太常见了可能是上次服务没退出、可能是其他服务共用了端口也可能是你启动了两个实例。不要上来就重启服务器先确认到底是谁占用了端口再决定对策。生产环境里网上也有很多重启大法帖子但对于服务管理和故障定位还是要尽量养成先定位、再处理的习惯。8.4 第四阶段配置开机自启服务手动启动没问题了但如果服务器重启进程就没了。手动启动可以接受但生产环境不能接受。所以还要配置一个简单的systemd服务单元文件nano /etc/systemd/system/myapp.service内容如下[Unit] DescriptionMy Python App Afternetwork.target [Service] Userwww-data WorkingDirectory/opt/myapp ExecStart/opt/myapp/venv/bin/python /opt/myapp/app.py Restartalways [Install] WantedBymulti-user.target然后加载、启用、启动systemctl daemon-reload systemctl enable myapp systemctl start myapp用systemctl的好处非常明显统一管理启动、停止、查看状态、查日志journalctl -u myapp进程崩了自动拉起Restartalways开机自动启动。这比裸跑nohup正规得多。到这里这次部署算是有头有尾了。整个过程用到的命令没有一条超纲全部都是前面章节讲过的基础指令但组合起来就完成了一个完整任务。这也是我想强调的基本指令不是用来背的是用来解决实际问题的。9. 高频故障复习与安全操作习惯最后再给你几条吃饭的本领9.1 命令找不到或软件装不上的排查思路遇到command not found先分清情况命令本来没装搜索包名apt search 关键字确认后安装命令已装但不在PATH用find或dpkg -L 包名找到安装位置把目录加进PATH命令存在但不在当前用户可执行范围参考sudo或修改文件权限软件安装失败也很常见我在工作中总结的经验是排查顺序网络有没有问题ping外网- 软件源是否可用apt update看报错- 依赖是否残缺按提示安装缺失依赖- 磁盘空间df -h。80%的安装失败在第2、4步就能定位。9.2 目录删错、文件覆盖后的急救办法如果没有备份、没有版本控制文件被覆盖或删除后能救回来的概率很低。Linux没有Windows回收站这个机制。所以我在这件事上的所有经验都归结为预防重要目录做定期备份rsync或tar删除用mv到临时回收目录替代配置文件改动前先cp一份.bak备份代码项目务必用git管理这是成本最低、效果最好的安全保障9.3 最值得养成的三个命令行习惯第一每次执行破坏性命令前先用ls或echo确认范围。不要觉得多此一举在真实服务器上敲错命令的代价可能是一个团队一晚上的工作成果。第二写命令时尽量用绝对路径或明确指定的相对路径。脚本里尤其如此。刚刚毕业的同学特别喜欢在脚本里用cd切换到某个目录再执行操作但这个目录如果不存在后面的命令就全乱套。写脚本首要原则是路径不要靠猜。第三错误信息也是信息不要直接忽略。很多人看到日志里有报错就慌或者干脆只看到ERROR就不知所措。正确做法是把报错内容读两遍把它里面的关键信息文件名、行号、错误码提取出来再按关键字去grep、去搜。绝大多数Linux报错信息的英文都很直白直白到你哪怕英文很差也能猜出个大概。9.4 关于Linux面试题的一点个人看法网上流传的Linux面试题很多从ls的参数、chmod 777的含义到软链接和硬链接的区别、进程和线程的区别铺天盖地。我面过一些候选人也做过面试官我的切身感受是面试题不背书不可取但只会背题更不行。真正区分水平的是你在现场能不能把命令组合起来解决一个实际问题。比如给你一台机器让你排查CPU高负载比如给你一个服务让你确认它为什么起不来。这些都要求你把基本指令内化成自己的思维工具。写到最后还是想再啰嗦一句Linux学习本质上是一个小步快跑、不断正反馈的过程。不用等自己学完整本手册再上服务器操作直接上手、遇到问题再查再学就行。我至今仍会时不时翻man帮助文档这没什么丢人的真正丢人的是拿着屠龙刀满世界找龙却不知道自己眼前的文件权限问题只要一个chmod就能解决。