我见过太多刚入门的同事抱着 Linux 常用命令大全背了三个月rm -rf、grep、awk 玩得飞起真到线上排查问题时照样两眼一抹黑。原因很简单——你记住了每个命令长什么样却没搞懂 Linux 到底是怎么把硬件、内核、进程和文件组织成一个活体。用个不恰当的比喻命令只是 Linux 的肌肉文件系统和进程模型才是骨架而 Shell 与内核之间的协作机制才是灵魂。这篇文章是《Linux核心进阶之路》的第一篇不准备带你一条条过命令而是先把整台机器的底盘拆开给你看目录树代表什么、进程怎么产生和消亡、权限如何形成边界、管道和重定向在数据流中扮演什么角色。适合刚会用命令但想真正理解系统的你也适合准备跳槽想补基础的人。1. 先打破一个误区命令背得再多不如吃透文件系统很多人学 Linux 是从“背命令”开始的ls 列出文件、cd 切换目录、rm 删除文件。背到一定程度就会遇到瓶颈——同样的命令在这台机器上能用换一台机器就不能用明明按教程敲了输出结果却不对。根子在于你不清楚命令操作的对象到底是什么。Linux 里绝大部分命令本质上是文件系统接口的封装你搞懂了文件系统等于拿到了理解命令的钥匙。1.1 目录树不是随便设计的每一层都对应一种“生命周期”Linux 的目录树从/开始但这个根目录不是 Windows 里那种“C盘”概念。它更像一棵倒挂的树每个子目录都承担不同的责任而且遵循 FHS文件系统层级标准这套约定。记住这些约定比记住一百条命令都值钱。/bin、/sbin系统启动和基础维护需要的可执行文件。很多发行版已经把/bin软链接到/usr/bin但概念上它代表“最小可用的命令集”。/etc配置文件的家。nginx.conf、sudoers、passwd、shadow 全在这里。Linux 的设计哲学是“配置可见即可改”系统行为大多由文本文件驱动。/var经常变化的数据日志、缓存、邮件队列。日志在/var/log容器和包管理器的临时数据也经常落在/var/lib。/tmp和/var/tmp临时文件。前者在重启后可能被清空后者更适合需要跨重启保留的临时数据。/home普通用户的家目录相当于用户的“私人办公室”。/proc、/sys、/dev这三兄弟比较特殊它们不存真实文件而是内核暴露出来的虚拟接口。我第一次真正理解 FHS是在排查一台服务器磁盘写满的时候。当时df -h显示/满了但du -sh /怎么都算不出哪个目录占了大头。最后发现是某个进程把日志写进了/tmp而/tmp挂载在一个独立的小分区上。如果你脑子里有目录生命周期这幅图第一反应就会去查/var/log和/tmp而不是像无头苍蝇一样到处翻。1.2 “一切皆文件”不是比喻而是内核的对外接口Linux 里有句话叫“一切皆文件”这句话一直被误读。它不是说所有东西都是磁盘上的文件而是说内核把设备、网络连接、进程信息、内核参数全部抽象成了“可读写的字节流”。普通文件能 open、read、write、close那么磁盘设备、socket、管道也能用同一套系统调用去操作。举几个例子/dev/null一个永远写不满、读出来是空的“黑洞文件”。/dev/sda一块物理磁盘你用dd写它就是在直接操作磁盘块。/proc/cpuinfo、/proc/meminfo允许你把内核看到的 CPU 和内存状态当成文本文件读取。/sys/class/net/eth0/statistics/网卡流量统计读这些文件就能拿到累计收发字节数。这套抽象的好处是用户态的工具只需要学会对付“文件”就能对付几乎一切资源。比如cat /proc/cpuinfo能看 CPU 型号cat /sys/class/thermal/thermal_zone0/temp能读 CPU 温度本质上和cat一个文本文件没有区别。我见过很多同事调试网络问题时喜欢抓包但很少想到去看/proc/net/tcp。这个文件把当前所有 TCP 连接以文本形式列出来配合ss命令能快速定位端口占用和连接状态。理解了“一切皆文件”你自然会去这些地方找线索而不是靠猜。1.3 删文件夹、临时文件、日志轮转命令只是文件的搬运工热搜词里“linux删除文件夹命令”常年排在前列说明这是多数人的初级痛点。rm -rf威力巨大但它的危险也源于文件系统的层级逻辑-r是递归进入子目录-f是忽略提示强制删除。一个rm -rf /或rm -rf /*如果前面没有做路径校验整棵目录树都会被拆掉。真正稳妥的做法是先确认路径pwd ls -ld /var/log/nginx rm -rf /var/log/nginx/*如果是删除一年前的日志我更推荐find加-mtimefind /var/log/nginx -type f -mtime 365 -name *.log -delete这条命令的意思是找出/var/log/nginx下修改时间超过 365 天的普通日志文件并删除。你先列出、再删除比直接rm -rf可控得多。删除操作之所以难是因为它破坏的是文件系统的“目录项inode”结构误删后很难恢复所以所有资深工程师都会在执行删除前加一道“看见即确认”的流程。2. 进程与信号Linux 的灵魂不在命令而在“谁在跑、谁在等”文件系统是骨架那么进程就是血液。你敲下一条命令Shell 会创建一个进程来执行它你启动一个服务系统会出现一组常驻进程。理解进程如何诞生、如何通信、如何死亡才能真正掌握 Linux。2.1 fork/exec一个命令从被你敲下到变成进程中间发生了什么在 Linux 里创建进程的核心方式是fork()和exec()。fork()会把当前进程复制一份得到父子两个几乎一样的进程exec()则用新程序替换当前进程的代码和数据。终端里敲lsShell 先fork()出一个子进程再在子进程里exec()加载/usr/bin/ls。子进程结束时通过退出码向父进程汇报结果Shell 拿到退出码后把提示符还给你。这条机制解释了无数现象为什么$?能拿到上一条命令的退出状态因为那是子进程“托人带回来的口信”。为什么 source 一个脚本和直接执行一个脚本不一样source是在当前 Shell 进程里跑exec脚本会新建子进程环境变量自然不共享。为什么nohup或setsid能让进程在退出终端后继续跑因为它们把目标进程从“终端进程组”里摘了出去避免收到 SIGHUP 挂断信号。面试时经常被问的“僵尸进程”也源于 fork/exit 模型。子进程先退出父进程还没调用wait()回收子进程的退出状态残留成一个“僵尸”。它不占用 CPU但占着 PID。父进程挂掉后孤儿进程被 init/systemd 收养由系统统一回收。2.2 进程状态和退出码从 ps 里看出系统的呼吸ps和top应该是最常被忽视的工具。很多人只看 CPU 和内存占用其实ps里的STAT列特别有信息量R正在运行或可运行。S可中断睡眠大多数等待 I/O 的进程是这个状态。D不可中断睡眠通常是在等磁盘 I/O这种状态如果长期大量堆积说明存储有问题。Z僵尸进程前面说了等父进程来收尸。T被停止比如按了 CtrlZ。看状态比看 CPU 占用更早发现故障。如果一台机器很卡你ps aux看到一堆D状态进程第一反应应该是查磁盘 I/O而不是想着去 kill 进程。因为D状态的进程根本 kill 不掉得等 I/O 恢复。退出码也是进程通信的核心。0 表示成功非 0 表示失败。写脚本时我会刻意对每一条可能失败的命令做退出码判断if ! grep -q healthy /tmp/healthcheck.txt; then echo health check failed 2 exit 1 fi很多运维事故是因为脚本没判断失败就继续往下走数据被同步坏了才发现。把退出码当成进程的“遗言”你会少踩很多坑。2.3 信号就是进程的“短信”kill、CtrlC、后台任务进程之间除了通过文件和网络通信还有一套轻量级异步通知机制——信号。CtrlC 发送 SIGINTkill默认发送 SIGTERMkill -9发送 SIGKILL。前者允许进程做清理再退出后者直接强制剥夺进程资源。我见过不少人线上排查的时候上来就kill -9把服务和依赖它的进程一起干掉结果留下了一堆锁文件和半截数据。更稳妥的顺序是先 SIGTERM等几秒不行再 SIGKILL。SIGTERM 就像敲门告诉你“该下班了”SIGKILL 是保安直接断电。调试后台任务时jobs、fg、bg、CtrlZ这套组合也很有用。你临时要把一个前台任务放到后台可以 CtrlZ 挂起再bg让它继续跑。但要注意这些任务还是会受终端关闭影响真正要持久运行还是得靠 systemd service 或nohup/setsid。2.4 容器不过是被“关起来”的进程containerd 背后的进程观热搜词里出现过containerd命令很多人第一次接触 containerd 时觉得它是另一个 Docker其实你把它想成“进程管理器”就好理解了。容器不是虚拟机没有独立内核它只是使用 Linux 内核的命名空间Namespace和 cgroups 把一组进程隔离起来。containerd 的ctr、nerdctl命令本质上是管理这些“被隔离的进程组”。搞懂进程模型之后你再去看容器就轻松很多容器里的 PID 1 是入口进程容器退出时 PID 1 退出一个容器里可以跑多个进程但不建议因为重启策略只盯着 PID 1。你在宿主机上用ps aux能看到容器进程用systemctl管不了容器是因为它们不在同一个 namespace 里但内核视角它们都是普通进程。3. 权限模型为什么 root 不是万能的sudo 也有边界文件系统回答了“数据在哪”进程模型回答了“谁在跑”权限模型则回答“谁被允许干什么”。很多人对权限的理解停留在“root 最大其他用户很小”这是远远不够的。3.1 UID/GID、文件 Owner、rwx 九位权限每个 Linux 用户都有一个 UID每个组有一个 GID。内核不关心用户名只认数字 ID。/etc/passwd把 UID 映射到用户名/etc/shadow存储密码散列这也是为什么直接复制/etc/passwd并不会泄露密码但复制到/etc/shadow就非常危险。权限九位三元组rwxr-xr-x分别对应 owner、group、other 三方的读、写、执行权限。目录的执行权限尤其特殊它代表“能否进入这个目录”而不是“能否执行某个文件”。所以一个目录只有r--没有x你能列出文件名却进不去也读不到文件内容。很多新人卡在这里。查看权限用ls -l修改权限我习惯用相对清晰的符号模式chmod ux script.sh # 给 owner 加执行权限 chmod -R grwX /srv/share # 递归设置组权限X 表示只有目录和已有执行权限的文件才加执行权限 chown root:appuser /opt/app/config.yml新手最常犯的错误是把整个目录chmod -R 777。这会让你后续排查权限问题非常痛苦也给攻击者留下了宽松边界。更好的做法是只给需要的路径、需要的用户、需要的权限最小权限原则是所有安全运维的第一条。3.2 SUID/SGID/Sticky 位特殊权限是双刃剑除了 rwx权限位里还有三个特殊位SUID、SGID、Sticky。SUID 位如果出现在可执行文件上意味着执行时进程将以文件属主身份运行而不是运行者的身份。比如/usr/bin/passwd就带 SUID普通用户才能通过它修改自己的密码。热搜词里有个“linux提权”这词听起来很酷但它反映的现实是错误的 SUID 配置会形成提权漏洞。如果某个程序属主是 root且还带着 SUID 位普通用户一执行就变成 root 身份。攻击者一旦找到可利用的 SUID 程序就能从普通权限升级到管理员权限。判断文件是否带 SUID看ls -l的 owner 执行位是不是s而不是xls -l /usr/bin/passwd -rwsr-xr-x 1 root root 68208 May 18 2024 /usr/bin/passwd如果想排查系统里所有带 SUID/SGID 的文件可以这样做find / -perm /4000 -type f 2/dev/null看到异常结果时不要急着删文件先确认它是不是标准发行版自带的。我记得有一次在某台机器上发现了/usr/bin/find被设置成 SUID root这几乎可以肯定是有人手动动的后来查明是测试时误操作。提权的本质不是魔法而是把权限模型里的配置错误变成了攻击路径。3.3 sudo 不过是一次“换身份”的系统调用结果sudo 并不是独立的超级权限它不是“万能的”它只是“受控的身份切换”。sudo命令读取/etc/sudoers的配置根据规则临时把当前用户切换成目标用户执行命令默认目标是 root。检查配置用visudo不要直接 vim 编辑因为语法错误会导致 sudo 全部失效。当你执行sudo cat /etc/shadow真实流程是sudo 进程以 root 身份校验配置再调用setuid类机制切换用户最后 exec 指定命令。它能做的所有操作都被内核权限模型限制。也就是说强制sudo也干不了内核没授权的事比如直接读写一块它看不到的内存。配置 sudo 时NOPASSWD是个需要小心的关键字。它能让某个用户免密执行 sudo方便是方便但一旦账号被攻破攻击者等于拿到了免密 root。我通常只对自动化脚本账号开放最小命令集合比如deploy ALL(ALL) NOPASSWD: /usr/bin/systemctl restart app-service这种配置比deploy ALL(ALL) NOPASSWD: ALL安全太多后者一旦被利用整个系统基本是不设防的。3.4 权限不足时报错和排查思路权限问题的典型报错是 “Permission denied”但你这个字面去猜是没用的。先确认三件事你当前是谁id、目标文件的 owner 和 groupls -ld、你所属的附加组有没有包含目标 groupgroups。很多时候不是没权限而是当前用户和文件属主不匹配。比如/etc/shadow一般只允许 root 和 shadow 组读取。普通用户想读它是正常被拒绝的这不是 Bug。再比如一个目录权限是drwxrwx---属主是appuser:appuser你把应用用户加进appuser组后进程必须重新登录或newgrp才能生效而不是立刻就能访问。我建议每个新环境都要跑一遍id、ls -l、getfacl把权限基线看清楚再动手。权限是安全边界但它同时也是故障排查里最容易被误判的一层。4. 管道、重定向和趁手的工具命令行的“呼吸系统”与“肌肉记忆”文件系统是骨架进程是血液权限是边界那 Shell 就是指挥中心。Shell 里最核心的两个语法点就是重定向和管道。它们让看似独立的命令能像积木一样拼装起来形成强大的组合能力。4.1 标准输入输出与文件描述符命令之间怎么“说话”每个进程默认有三个文件描述符0 标准输入、1 标准输出、2 标准错误。命令把结果写到 stdout把错误信息写到 stderr。你可能没意识到这俩默认都指向同一个终端所以你平时看到“正常输出”和“报错混在一起”。重定向就是改变这几个描述符的指向。 file把标准输出写入文件 file是追加2 file把标准错误写入文件。最常见的坑是21的位置cmd /tmp/log.txt 21这条命令的意思是把 stderr 重定向到“当前 stdout 指向的地方”也就是/tmp/log.txt。如果你写成cmd 21 /tmp/log.txt顺序反了stderr 还会留在终端因为21执行时 stdout 还指向终端。这个细节半年内踩一次每次都能难住一批人。还有/dev/null这个黑洞脚本里经常出现2/dev/null意思是把错误信息扔掉。使用时要注意别把本不该忽略的报错也丢掉否则线上排障时你连错误看不到。4.2 管道钩出数据流一条命令输出的终点是另一条命令的起点管道符|把左边命令的 stdout接成右边命令的 stdin。它不经过磁盘直接在内存里流动。这等于把一系列命令变成了一个流水线每个工位只处理自己关心的一段。一个很实用的场景是查端口监听状态。ss -lntp的输出有时很长配合管道简单直接ss -lntp | grep :8080再比如你想分析 history 里最常用的 20 条命令是什么history 1000 | awk {print $2} | sort | uniq -c | sort -rn | head -20这条管道链里history 输出历史记录awk 提取每条记录的命令名sort 排序让相同命令相邻uniq -c 计数sort -rn 按次数降序head -20 取前 20 个。看起来复杂的分析一条管道就完成了。你不需要写脚本不需要临时文件这就是管道设计的精妙之处。4.3 常用组合套路从 grep、awk、sort 到 xargs除了管道xargs是把前一命令输出变成后一命令参数的关键工具。find /tmp -name *.tmp | xargs rm -f就是找出临时文件并删除。但要注意文件名里有空格或换行时xargs默认按空白切分会切错。更稳的写法是用-0find /tmp -name *.tmp -print0 | xargs -0 rm -f如果只是删除文件我更推荐find ... -delete它不经过 xargs也不用考虑文件名分隔问题。能用 find 内建操作解决的事就不要绕道 xargs。iptables 命令也天然适合和管道搭配。比如你想看防火墙里所有 DROP 规则的命中次数iptables -L -n -v | grep DROPgrep 过滤、awk 提取字段、sort 排序、head/tail 取首尾这套组合拳覆盖了日常日志分析、进程排查、性能查看的大多数场景。等你能用一条管道链完成一次排查你就不会再觉得“命令多到记不完”了。4.4 别把 vim 当 IDE交互工具与批处理工具的配合vim 强大但它是交互式编辑器不是批处理数据流的工具。很多人用 vim 去改几百个文件的共同内容一个个手工编辑效率很低。适合批处理的场景应该交给sed、awk和perl。比如批量把/etc/hosts里所有旧 IP 替换成新 IP可以sed -i s/192\.168\.1\.10/192.168.1.11/g /etc/hosts-i是原地修改但执行前我建议先不加-i跑一遍确认输出符合预期再落地。毕竟一旦改错再想还原就很难。telnet命令也是常见的排查工具功能不只是登录远端设备更多时候我拿它测端口通不通telnet 192.168.1.20 3306能连上就是端口通连不上会报连接失败或超时。现在很多机器没装 telnet 服务端但客户端基本随便装测端口比nc更直观。它不是被淘汰只是从“远程登录工具”变成了“端口探测工具”。你把这些工具当成组合件看待而不是一个个孤立命令思路一下就打开了。5. 内核与用户空间的隔层什么时候该看 dmesg什么时候该看 strace文件系统、进程、权限、管道这些都在用户态看得见摸得着。但很多时候问题出在你和硬件之间的那层隔膜——内核。学会跨越用户态和内核态的边界去排查问题是从“会用 Linux”到“懂 Linux”的分水岭。5.1 用户态和内核态命令跑起来之后谁在真正干活Linux 把 CPU 的运行级别分成用户态和内核态。普通应用跑在用户态不能直接访问硬件和内核数据结构每当它需要读文件、发网络包、分配内存就必须通过系统调用让内核代劳。这层隔离是为了安全和稳定一个用户程序出错不能直接拖垮整个系统。命令不是“直接干活”而是“请求内核干活”。比如cat file会触发一系列系统调用open()打开文件、read()读取内容、write()写到终端、close()关闭文件。你看到的是文件内容实际上是内核在文件系统和终端之间搬运字节。理解这一点之后很多故障排查就有方向了进程跑得慢不一定是代码慢可能是频繁切换内核态磁盘 I/O 高不一定是磁盘坏了可能是大量 read/write 在排队。你可以用vmstat、iostat、pidstat看上下文切换和中断比单纯盯着进程 CPU 占用更接近真相。5.2 ldd、file、strace用动态追踪代替瞎猜排查“命令突然跑不起来”的情况我习惯先看文件类型和动态库依赖再看系统调用到底卡在哪。file /usr/bin/xxx能告诉你这个二进制是 64 位还是 32 位、动态链接还是静态链接。ldd /usr/bin/xxx会列出它依赖的.so库如果输出里有 “not found”多半是环境变量 LD_LIBRARY_PATH 或软件包缺失问题。如果依赖都正常命令还是报错就该上strace了。strace -f -e tracefile,network,process能跟踪命令执行时的系统调用。比如某个命令启动时报 “No such file or directory”但那文件明明存在strace会告诉你它到底在找哪个路径是相对路径还是绝对路径哪个用户身份去访问。strace -f -e tracefile /usr/bin/nginx -t这条命令能看到 nginx 测试配置时读取了哪些文件、有没有权限问题、哪一步触发 ENOENT。比对着配置逐行猜高效多了。很多国产软件或老软件在 Linux 上启动失败都是路径写死、缺 32 位库、环境变量不完整这三类问题strace 基本都能一锤定音。5.3 dmesg、journalctl内核的“病历本”怎么读用户态报错可以看应用日志内核报错则要看dmesg。硬件识别失败、驱动崩溃、OOM 杀进程、磁盘 I/O 错误很多底层故障都会在这里留下痕迹。比如机器突然卡死怀疑是内存不足dmesg -T看结尾有没有 “Out of memory: Kill process”。如果是某个进程被 OOM killer 杀掉了说明内存真的不够如果频繁 OOM你得考虑调应用内存或加 swap。dmesg -T把时间戳转成可读时间这是我最常用的参数因为默认时间戳是内核启动以来的秒数直接用没法换算。systemd发行版的日志统一走journalctljournalctl -xe能看最近一条错误的上下文journalctl -u sshd看某个服务的全部日志。很多系统服务起不来不要只跑systemctl status用journalctl -u 服务名 -n 100看日志末尾信息量更大。dmesg 和 journalctl 两个都要看前者偏内核后者偏用户态服务交叉验证才能定位到根因。5.4 内核版本与发行版别把 Ubuntu 的版本号当成内核版本号最后补一个很基础但容易被忽略的认知发行版版本号和内核版本号是两件事。热搜词里“linux系统安装”“linux国产”经常出现但很多人装完系统后查cat /etc/os-release看到 22.04 或 20.04就以为是内核版本。内核版本要uname -r看比如5.15.0-91-generic。发行版提供的是用户态工具、包管理器和默认配置内核是那个真正和硬件对话的程序。所以你在 Ubuntu 上的包管理命令 apt在 CentOS 上是 yum/dnf在内核层面没有本质区别而同一个内核可以被不同发行版包装成差别很大的系统。遇到内核相关的问题比如某个硬件模块不支持重点查uname -r对应内核的特性而不是发行版文档。如果你在 wsl 或云服务器上看到“内核版本必须更新到最新版”之类的提示那是发行版把内核和用户态打包升级的机制本质上是在提醒你底层内核有了新的安全修复和硬件支持。升级前先uname -r记录原版本升级完再对比一次确认真的切过去了。我在实际排查中经常碰到一种情况用户说“这个命令在 Ubuntu 上能用移到国产 Linux 上不行”。实际上多数是和内核模块或 glibc 版本有关。先uname -a确认内核再ldd --version确认 glibc再file确认二进制格式思路一清晰问题就不神秘了。如果非要把这套思路留成一句心法我的体会是文件系统定义“状态在哪”进程定义“谁在动”权限定义“谁能动”Shell 管道定义“怎么流动”内核则是这一切的裁判。先在心里搭起这五根柱子再谈背命令、调性能你会发现自己一下子从“敲键盘的人”变成了“理解系统的人”。后续我会继续写进程调度、内存管理、网络协议栈这些进阶主题但每一篇都会回到这五根柱子上展开。