在Linux这条路上摸爬滚打这些年我越来越觉得真正拉开运维和开发差距的往往不是那些花里胡哨的框架而是对常用命令的底层理解。很多人背了一堆linux常用命令大全真到线上排查问题时照样抓瞎原因就在于只记住了参数没搞懂命令背后的设计逻辑和适用场景。这篇是Linux系列的中篇咱们不聊安装部署那些入门操作专门挑日常使用频率最高、但最容易出错的几类命令场景做深度拆解文件处理、文本操作、远程传输、权限管理再串一下docker、nginx、python这些热门应用落地时必然会用到的命令组合。无论你是准备linux面试题测试的求职者还是在做嵌入式linux项目、日常维护服务器的工程师这篇内容都能帮你把命令从“会用”提升到“用得稳”。1. 文件与目录操作看似简单坑全在细节里1.1 删除文件夹的三种方式与风险边界先说一下linux删除文件夹命令这是个老生常谈但永远有人踩坑的话题。rm -rf绝对是Linux世界里最危险也最高频的命令之一但很多人并不知道它其实有明确的适用边界。删除文件夹常见三种方式rm -rf dir强制递归删除不询问最直接也最危险rm -ri dir递归删除但逐个询问适合删除重要目录时用find dir -delete按条件筛选后删除适合精确删除特定文件我强烈建议在日常操作中把rm -rf的使用频率降下来尤其是在生产服务器上。一个很实用的习惯是先ls -la看清楚目录内容再用rm -ri做交互式删除确认无误后再批量操作。如果确实需要高频使用rm -rf可以在.bashrc里加一个别名比如alias rmrm -i虽然有时候会觉得烦但关键时刻能救命。另外要特别注意路径中的通配符和空格问题。比如你想删除/data/logs/下所有.log文件写成rm -rf /data/logs/*.log时如果目录里正好有个文件名包含特殊字符或者通配符被shell意外展开就可能删到不该删的东西。我建议先用echo /data/logs/*.log看一眼展开结果再执行删除这个习惯帮我避免过至少三次线上事故。1.2 find命令组合技从检索到批量处理linux find用法是面试中出现频率极高的考点但大多数人只停留在find -name *.log这个层面。实际上find的真正威力在于它能把“查找”和“执行”串联起来配合-exec或管道就成了一个流程化操作工具。先看基础但容易被忽略的几个参数-type f和-type d区分文件和目录比全量查找快得多-mtime 7修改时间超过7天的文件日志清理必备-size 100M按文件大小过滤排查磁盘占用利器-name和-iname后者忽略大小写搜索时常常用到查找到文件之后的处理有两条路# 方式一-exec 直接处理适合对结果集做精确操作 find /var/log -name *.log -mtime 7 -exec rm -f {} \; # 方式二管道配合 xargs适合处理需要二次过滤的场景 find /data -type f -name *.tmp | xargs -I {} mv {} /tmp/backup/这里有个细节值得展开-exec和xargs的区别。-exec是逐个文件调用后面的命令精确但性能较差xargs是把尽可能多的文件名拼接成一条命令行再执行性能好但存在“参数过长”的溢出风险。如果文件数量特别大比如超过几万条建议用find ... -print0 | xargs -0 ...这种以空字符分隔的方式避免文件名中的空格和换行导致解析错误。-exec后面的{} \;和{} 也经常让人困惑。\;表示每个文件执行一次命令而{} 表示所有文件合并成一条命令执行。我实际使用中删除操作更倾向\;确保逻辑清晰批量压缩等操作则用{} 提升效率。1.3 条件判断指令[-d]脚本里的小机关热词里出现了“linux指令[-d]”这其实是shell脚本里的一个条件测试语句全称是test -d用来判断后面跟的路径是否是一个目录。类似的还有-f普通文件、-e路径存在、-x可执行等。很多人写脚本时不太注意这些条件判断导致脚本在目标环境跑不通。我分享一个写健壮脚本的检查模板if [ -d /var/www/html ]; then echo 目录存在 else echo 目录不存在开始创建 mkdir -p /var/www/html fi if [ -f /etc/nginx/nginx.conf ]; then echo 配置文件存在可以启动服务 fi注意到[ -d ]和[[ -d ]]的区别了吗单中括号是传统的test命令双中括号是bash关键字功能更强大支持正则匹配、空值安全等但可移植性稍差。写脚本时如果确认环境是bash建议优先用双中括号如果是纯POSIX shell环境只能用单中括号。这里补充一个常见的坑写[ -d $dir ]时变量一定要加双引号。如果$dir变量为空不加引号会变成[ -d ]返回结果永远是“真”导致脚本逻辑错误。我曾经在部署脚本里遇到过这个问题排查了半小时最终发现就是个引号缺失。2. 文本处理三剑客grep、sed、awk的实战进阶2.1 sed打印乱码的处理思路热词里有一条“linux sed 打印出来有乱码”这是个很典型的问题。先说结论绝大多数情况下sed乱码不是sed本身的问题而是输入文件的编码格式和终端环境不一致导致的。排查步骤按顺序来# 第一步查看文件编码 file -i yourfile.txt # 第二步查看当前环境编码 echo $LANG # 第三步如果是UTF-8文件但终端显示乱码检查终端编码设置 locale常见的情况是文件本身是GBK编码而终端环境是UTF-8这时候用sed处理并打印中文全部变成乱码。解决办法有两种思路一种是转换文件编码后再处理iconv -f GBK -t UTF-8 yourfile.txt | sed -n 10,20p另一种是直接用sed处理二进制流不做编码转换。比如只想提取某几行的数据不在乎中文是否正常显示sed -n 10,20p yourfile.txt | cat -vcat -v会把非打印字符显示成特殊符号方便排查乱码是不是控制字符引起的。还有一类乱码是sed的-i修改文件后出现的。如果你的sed正则里有特殊字符比如\t在某些版本的sed里并不默认支持GNU sed支持BSD sed不支持替换的时候会把转义序列破坏掉看起来就像乱码。解决办法是优先用GNU sedLinux默认或者用$\t这样的bash参数展开代替。2.2 awk处理日志从入门到写出排查工具awk是文本处理里最强大的工具也是最容易被忽视的。很多运维老手写日志分析脚本首选就是awk因为它天然支持按列拆分、条件筛选、统计汇总。看一个实际场景统计Nginx访问日志里每个IP的请求次数。awk {print $1} /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20这里把awk、sort、uniq三个命令串联起来形成一个标准流水线。print $1提取第一列IPsort排序让相同IP排在一起uniq -c统计连续重复行数再sort -rn按数量降序排列。这个组合在面试题里几乎必考也是日常排查的万能公式。awk的BEGIN和END块也值得多用。比如统计日志文件里某个接口的平均响应时间awk $7 /api/login {sum $NF; count} END{print 平均响应时间:, sum/count} app.log这个命令把匹配/api/login的行做累加和计数最后在END块里算平均值。比写一个完整的Python脚本快得多适合现场临时排查时使用。用awk时需要注意字段分隔符。默认是按空白符分割空格或Tab但如果你的日志是逗号分隔、竖线分隔就需要用-F指定awk -F, {print $2} data.csv awk -F| {print $1, $3} app.log2.3 grep的高效用法与常见误区grep是这三个工具里最容易上手的但用得好不好差别很大。几个提升效率的技巧递归搜索日志目录grep -r ERROR /var/log/搜索时忽略大小写grep -i error显示匹配前后行grep -C 5 exception表示前后各5行只输出匹配部分而不是整行grep -o [0-9]\\.[0-9]\\.[0-9]\\.[0-9]\用来提取IP地址还有个容易踩坑的点grep默认不吃“多行模式”也很正常但如果配合-P参数Perl正则能用上更高级的断言。比如查找包含“error”但不包含“ignore”的行grep -P ^((?!ignore).)*error((?!ignore).)*$ app.log这种负向断言在复杂日志过滤时非常有用但注意-P参数在部分精简版系统里需要额外安装pcre2-utils包。3. 远程传输与权限管理生产环境的安全底线3.1 scp命令的完整使用与替代方案linux scp命令是运维工作中最常用的远程拷贝工具。基础用法就不多说了重点讲几个容易出问题的细节。跨端口传输scp -P 2222 /data/backup.tar.gz userremote:/data/注意scp的端口参数是大写-P而ssh登录是小写-p。这个大小写差别的坑我见过不少新手踩过。目录递归拷贝scp -r /data/project/ userremote:/data/-r参数递归拷贝目录但如果目录里有大量小文件scp的性能会非常差因为它每个文件都要重新建立加密连接。这时候推荐用rsync替代rsync -avz --progress /data/project/ userremote:/data/rsync支持增量同步、断点续传、压缩传输在大目录传输场景下比scp快一个量级。如果你每次scp传大量文件都感觉慢赶紧换成rsync。还有个安全层面的提醒scp默认使用SSH通道加密但如果你用的是密码认证方式建议尽早换成密钥认证。操作方法是ssh-keygen -t rsa -b 4096 ssh-copy-id userremote配置完成后scp和ssh都不需要再输入密码既方便又安全。密钥认证失败时的排查重点是检查远端~/.ssh/authorized_keys文件的权限必须是600检查远端~/.ssh目录权限必须是700检查远端sshd配置里有没有禁用公钥认证3.2 linux新建用户的完整流程与权限隔离linux新建用户是运维基本功但很多人只会useradd username用一段时间后就发现权限管理混乱。这里给出一个生产环境的标准操作流程# 第一步创建用户并指定家目录和shell useradd -m -d /home/deploy -s /bin/bash deploy # 第二步设置密码 passwd deploy # 第三步按需加入sudo组 usermod -aG wheel deploy # CentOS/RHEL系 usermod -aG sudo deploy # Debian/Ubuntu系创建用户后最好立刻验证一下权限隔离是否生效。比如用su - deploy切换到新用户确认家目录可写但访问/root或/etc/shadow会提示权限不足。如果需要临时授权某个用户查看指定目录日志又不想给sudo权限可以用ACL访问控制列表setfacl -m u:deploy:rx /var/log/nginx/这样deploy用户只能读取nginx日志目录不会获得其他系统权限。相比直接把人加进sudo组ACL的粒度控制要安全得多。3.3 权限位详解chmod、chown和umask的配合权限管理里chmod、chown、umask是三位一体。很多人单独会用每个命令但不清楚它们之间的关系。chown改变文件属主和属组chmod改变文件权限位umask则是新建文件时默认权限的“反掩码”。比如umask 022表示新建文件的默认权限是666 - 022 644普通文件或777 - 022 755目录。这意味着其他用户对你的新文件只有读权限没有写权限。如果希望更严格同组用户也不可写可以umask 027。实际部署中经常遇到的问题是nginx或php-fpm运行用户和文件属主不一致导致403或500错误。标准做法是# 让www-data拥有项目目录且目录权限为755文件为644 chown -R www-data:www-data /var/www/html find /var/www/html -type d -exec chmod 755 {} \; find /var/www/html -type f -exec chmod 644 {} \;这套“目录755、文件644”的组合是Web服务器最稳妥的权限方案按这个执行基本不会出权限问题。4. 热门应用落地docker、nginx、python安装中的命令串联4.1 linux安装docker时的预检查与避坑linux安装docker是个高频需求但很多人直接复制官方脚本就跑了遇到问题才回来排查。我先给一个预检查清单# 检查内核版本docker要求3.10以上 uname -r # 检查是否已安装旧版本docker rpm -qa | grep docker 或 dpkg -l | grep docker # 检查cgroup挂载情况 mount | grep cgroup安装之后启动服务的标准流程systemctl start docker systemctl enable docker systemctl status docker这组命令是systemd管理服务的基本三连不只是docker适用nginx、mysql等服务都一样。enable设置开机自启status查看运行状态。docker装完后很多人的第一件事是拉镜像。这里有个实际体验直接连官方Docker Hub在国内经常很慢热词里提到“ollama国内镜像linux”本质是配置镜像加速器。做法是在/etc/docker/daemon.json里加registry-mirrors配置然后重启docker服务。{ registry-mirrors: [https://your-mirror.mirror] }配置完镜像加速还需要注意docker的存储驱动选项。如果能确认文件系统是overlay2建议在daemon.json里显式声明避免后续升级或迁移时出现兼容性意外。4.2 linux安装nginx的关键配置点linux安装nginx的方式很多可以用包管理器安装也可以编译安装。我推荐用官方源安装方式原因是方便后续用systemd管理升级也简单。装完后的第一件事是检查配置语法nginx -t这个命令检查nginx.conf的语法是否正确如果不通过会提示错误行号是每次改完配置后必做的验证步骤。证书配置、反向代理、负载均衡这些内容这里不展开重点讲一个和命令相关的操作——日志切割。nginx日志会一直增长不处理的话磁盘迟早被撑爆。常用方案是logrotate/usr/sbin/logrotate -f /etc/logrotate.d/nginxlogrotate的配置文件里指定日志路径、保留份数、切割周期比如/var/log/nginx/*.log { daily rotate 30 compress delaycompress missingok notifempty create 0640 nginx adm sharedscripts postrotate [ -f /var/run/nginx.pid ] kill -USR1 cat /var/run/nginx.pid endscript }这里的关键是kill -USR1这个信号让nginx重新打开日志文件如果少了这一步切割后的日志依然会被旧的文件句柄写入导致磁盘空间不释放。这个细节很容易被忽略但对日志管理非常重要。4.3 linux系统安装python时的版本管理linux系统安装python最头疼的是版本混乱。系统自带的python可能是2.7或3.6而你的项目需要3.10以上。如果直接改系统默认python版本可能会破坏系统工具依赖所以必须用版本管理工具。推荐方案是pyenv# 安装pyenv依赖 yum install -y gcc make patch zlib-devel bzip2-devel openssl-devel readline-devel sqlite-devel # 安装pyenv curl -L https://github.com/pyenv/pyenv-installer/raw/master/bin/pyenv-installer | bash # 安装指定版本python pyenv install 3.10.12 # 设置项目目录使用该版本 cd /data/project pyenv local 3.10.12使用pyenv而不是手动编译python核心优势在于不同项目可以在同一台机器上使用不同python版本pyenv会管理好环境变量和PATH不用手动改软链不用担心中途环境变量写错导致系统命令失效如果项目已经确定python版本但系统里没有合适的包管理工具也可以用conda但pyenv在纯python环境管理上更轻量。装完python后记得用python3 -m pip install --upgrade pip升级pip很多依赖安装失败都是pip版本过旧引起的。5. 内核与性能排查从端口到系统层深入5.1 端口排查9090端口被谁占用了热词里有个很具体的需求“linux的9090端口什么再用”。这类问题应该是运维日常里频繁出现的场景处理思路是固定的。先定位端口占用ss -lntp | grep 9090ss是socket统计命令-l显示监听端口-n不解析服务名直接显示端口号-t只显示TCP-p显示进程信息。输出结果里能看到占用该端口的进程PID和进程名。如果端口被占用但看不到进程名改用lsoflsof -i:9090lsof的输出包含PID和进程完整路径适合进一步定位。拿到PID之后ps -ef | grep PID ls -l /proc/PID/cwd/proc/PID/cwd是进程当前工作目录的软链接查看它能快速知道这个进程是从哪个目录启动的。这条链路是排查端口占用最实用的一套组合拳。若发现一个KNOWN进程意外占用了某端口多半是因为服务配置文件里写了监听规则。拿nginx举例可以快速grep -r 9090 /etc/nginx/确认是不是有server块监听了该端口。5.2 查看cache版本与TCP协议栈数据流热词里提到“linux查看cache版本”通常指的是L2/L3缓存信息或者某个软件的缓存模块版本。如果是查CPU缓存用lscpu | grep -i cache如果是查某个软件的缓存模块版本比如Redis的cache版本用redis-server --version至于“linux tcp协议栈数据流走读”这块偏内核调试和网络底层。如果你在做嵌入式linux项目或需要优化网络性能可以从这几个角度入手netstat -s查看TCP协议栈统计信息重传率、丢包率等cat /proc/net/tcp查看内核TCP连接表tcpdump -i eth0 tcp port 80抓包分析实际数据流排查TCP重传问题时重要的指标是重传率。重传率过高需要考虑网络带宽、延迟丢包、或是对端处理能力不足。用ss -s可以快速看汇总用sar -n TCP可以按时间维度看趋势。5.3 嵌入式linux项目的排查视角嵌入式linux和服务器linux在命令使用上既有重叠又有差异。嵌入式环境通常资源受限、内核裁剪过很多通用命令不存在这时候要用busybox提供的最小化工具集。嵌入式环境排查问题几个常用命令的替代关系top可能不支持用cat /proc/meminfo和cat /proc/loadavg代替dmesg可能没有用cat /proc/kmsg或检查串口日志ps参数受限用cat /proc/*/cmdline逐个查看进程参数在嵌入式linux项目里最常遇到的是根文件系统只读导致的软件安装失败。这时候需要重新挂载根文件系统mount -o remount,rw /如果空间不足需要分析是哪个目录占用了空间du -sh /* 2/dev/null | sort -hr | head -10嵌入式环境下没有那么多交互式工具所以“命令组合和状态查看”才是排查基本功这和服务器运维的理念是想通的。6. 调试与提权场景安全视角下的必备技能6.1 linux提权的概念澄清热词里“linux提权”出现频率不低。关于提权需要先分清楚概念一种是日常操作中的“权限提升”比如用sudo切换root另一种是安全测试中的“权限升级”指从普通用户获取root权限的过程。日常操作中我们最常用的是sudo -i # 切换到root sudo -u deploy whoami # 以指定用户身份执行命令如果想查看当前用户有哪些sudo权限sudo -l这个命令特别重要它能清楚列出当前用户可以执行哪些命令、以什么身份执行。很多运维团队在权限审计时就用这个命令检查用户是否有越权配置。安全视角下的权限升级核心思路是排查系统中哪些服务存在配置不当或被利用的风险。常见排查项检查/etc/sudoers里是否有非必要的NOPASSWD条目检查全局可写的文件find / -perm -0002 -type f 2/dev/null检查SUID文件find / -perm -4000 -type f 2/dev/nullSUID是Linux里一个特殊权限位具有SUID的文件在执行时会以文件属主身份运行。如果一个 root属主的文件有SUID位普通用户执行它就等于获得root权限。这个机制本身是设计特性但也是被滥用的重点对象所以定期排查SUID文件是非常好的安全习惯。6.2 系统激活状态与配置完整性检查排查系统问题时最后别忘了检查系统的激活状态和基本配置完整性。比如红帽系系统subscription-manager statusDebian/Ubuntu系则更多关注源和更新策略apt list --upgradable配置完整性检查一个重要思路是比对关键文件是否被篡改rpm -V nginx # 检查rpm包管理的文件是否和安装时一致如果输出里有S.5....T.这样的字符说明文件的权限、MD5校验值、时间戳有变化。这个检查方法在入侵排查和系统审计时很有用。6.3 国产linux生态与工具适配热词里“linux国产”出现很多次。这几年国产操作系统如统信UOS、麒麟等在政企领域应用越来越广对开发者来说很多原先在CentOS上跑得顺的命令和脚本到了国产系统上可能因为包管理器、默认shell、内核版本差异出现兼容性问题。在国产linux系统上部署应用时我建议先做这几项检查cat /etc/os-release确认系统版本和包管理器类型which yum或which apt确认安装命令uname -a确认内核版本是否支持所需内核模块ls /lib/modules/确认是否有对应内核版本的模块目录国产系统的软件源相比CentOS和Ubuntu偏少遇到软件装不上的情况优先考虑源码编译安装。编译前需要安装基础工具链yum install -y gcc gcc-c make automake autoconf libtool另外输入法这类桌面工具在国产系统上的适配也是个高频话题。linux输入法比较常见的是fcitx5和ibus两套框架国产系统一般默认带了其中一套。如果另外安装输入法记得要先安装对应的框架和引擎再安装输入法本体否则容易出现“装上了但切换不出来”的问题。7. 面试场景回顾与命令速查7.1 高频linux面试题测试中的命令考点linux面试题测试通常会覆盖以下类型结合本文内容整理成一个速查表考点方向典型问题核心命令/思路文件查找找出7天前的日志并删除find -mtime -exec端口排查80端口被谁占用ss -lntp、lsof -i日志分析统计每个IP访问次数awk sort uniq权限管理如何让新用户可读nginx日志但无sudoACL setfacl文本处理提取日志中某个字段grep -o、awk -F网络排查查看TCP重传率netstat -s、ss -s系统状态查看CPU缓存、内存信息lscpu、cat /proc/meminfo用户管理创建用户并加入sudo组useradd usermod面试时除了知道命令写法还要能讲清楚命令的原理和适用场景。比如同样是查看端口ss和netstat的区别是什么ss是直接读内核socket信息速度快、输出更清晰netstat在某些旧系统上需要额外安装且性能较差。能讲出这个层面面试官会觉得你是真的用过而不是背手册。7.2 一条命令思路排查应用故障把本文涉及的命令组合成一条完整的故障排查链路以“用户反馈服务访问慢”为例# 第一步看进程活着没 ps -ef | grep nginx # 第二步看端口监听状态 ss -lntp | grep 80 # 第三步看CPU和内存 top -bn1 | head -20 # 第四步看磁盘空间 df -h # 第五步看nginx错误日志 tail -n 100 /var/log/nginx/error.log # 第六步看tcp连接数 ss -s遇到线上问题先别慌按照这条链路依次排查大概率能定位问题所在。这套思路比死记命令重要得多也是面试里“排查思路”类问题的核心回答框架。8. 一些个人操作习惯最后分享几个我实际工作中养成的习惯这些经验都是踩过坑换来的。第一个习惯是“批量操作前先dry run”。无论是用find批量删除、用sed批量替换还是用awk批量处理文件先输出结果看一眼再执行真正的操作。比如sed替换前先sed s/old/new/g file | head -20预览确认无误后再加-i写回。第二个习惯是“线上操作必留后路”。要修改重要配置文件前先备份一份cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date %Y%m%d)这个操作虽然简单但回滚时能省下大量时间。配上nginx -t这样的语法验证命令基本不会出现改完配置服务起不来的情况。第三个习惯是“日志是排查问题的第一现场”。遇到任何异常先看对应服务的日志文件而不是盲目重启服务。系统级问题看/var/log/messages或journalctl应用级问题看各自的日志文件。日志的记录和轮转也是部署时就要规划好的基础设施不要等到磁盘满了才处理。linux常用命令看起来零散但只要理解了命令背后的设计逻辑用起来就会越来越顺手。这篇提到的场景和命令组合都是我日常工作中高频使用、不断验证过的内容。命令本身不复杂难的是一次次踩坑之后总结出的应用边界和操作习惯。希望这篇内容能帮你在实际环境和面试中少走一些弯路。