1. 面试官抛出 Linux 面试题时，真正想知道的其实只有三件事

我先抛一个可能挨骂的结论：把网上那份"Linux 面试题 100 问"从头背到尾，通常拿不到高分。我既当过被问的那一方，也在桌子另一侧看过不少简历，真正拉开差距的从来不是你记住了多少条命令，而是面试官在你答完之后追的那一句"为什么"。那些背出来的标准答案，只要被追问一层就会露馅——比如你答"用 top 看 CPU 占用"，对方接着问"top 第一行的 load average 是 1.5，可 CPU 使用率只有 20%，这算正常吗"，背题的人当场就卡住了，而真干过活的人会顺口说一句"得先看有没有进程卡在 D 状态等 IO"。

这就是 Linux 面试题最真实的模样：它表面上考命令，本质上考的是你的脑子里有没有一张完整的系统地图。所以这篇东西不打算再做一份"题库搬运"，我想换个角度，把高频题背后的考察意图拆开讲清楚，再补上那些网上答案里永远不会写、但面试官特别爱听的现场细节。

1.1 你会用，还是你知道它为什么这么用

同一道题，答法分三个档次。以"怎么查看一个端口被谁占用"为例，最低档的回答是"用 netstat"；中间档会补上"netstat -tunlp | grep 端口号，不过现在更推荐用ss -lntp，因为它走的是内核的 netlink 接口，在连接数上万的时候比 netstat 快得多"；最高档还会加一句"如果ss看不到进程名，说明当前不是 root，或者进程在容器独立的 network namespace 里，得进容器再看"。

三层答案背后是三种人：第一种查过一次，第二种查过很多次并且踩过性能的坑，第三种理解 ss 和 netstat 取数据的路径根本不一样。面试官拿着同一道题，几分钟就能把候选人分层，这也是为什么"Linux 面试题"这类搜索词下真正有价值的内容很少——大多数人想找的是第一层答案，而决定 offer 的是第三层。

我个人的经验是，准备阶段与其多背 50 道题，不如把 20 道高频题的答案往深挖两层。挖的方法很简单：每写完一个答案，强迫自己再问三句——这个命令的数据是从哪来的？它有什么不适用的情况？如果它给出的结果和我的预期不符，我下一步看什么？能答上这三句，面试基本就稳了。

1.2 运维、后端、嵌入式问的不是同一套东西

很多人忽略了一个前提：同样写着"Linux 面试题"，不同岗位的考点几乎是三套体系。运维岗最爱问故障排查链路、日志分析、权限与自动化；后端岗（Java、Go 这类）更关心进程线程模型、内存与文件描述符限制、容器里的资源可见性；嵌入式方向则围着交叉编译、内核模块、设备树、启动流程打转。

看这张表就能明白，为什么有人刷了三百道题还是觉得没用——刷的题和目标岗位的评分表根本没对齐。我建议在动手复习之前，先找到目标岗位的三五份 JD，把里面出现的技术词抄出来，再回头决定把哪一类题挖深。这个动作花不了一小时，但能省掉大量无效努力。

2. 命令类题目：那些能把人问出真功夫的细节

命令题是所有 Linux 面试题的入场券，也是最容易被轻视的部分。很多人觉得"命令谁不会"，但恰恰是这一块，面试官最喜欢用一个小小的场景把候选人筛掉。这一章我挑三个最高频的方向，把常见答案往上顶一层。

2.1 文本处理三件套，考的是组合而不是单点

grep、sed、awk 几乎是必问的，但面试官真正想看的不是你会不会用-i忽略大小写，而是你能不能把三者组合起来解决一个具体问题。经典场景：给一个几百兆的 Nginx 日志，统计访问量最高的十个 IP 及其次数。标准链路是awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10。

这一行命令里每一步都有考点。awk '{print $1}'默认以空白切分，取第一列；sort必须先排序，因为uniq -c只能合并相邻的重复行，这是最常被忽略的一个前提；sort -rn的-n是按数值排序而不是字典序，少了它会得到 "9 比 100 大" 这种荒唐结果。如果面试官再追问"日志字段是逗号分隔怎么办"，你就补上awk -F,；问"IP 前面有空格"，就说awk天然会把连续空白当一个分隔符处理。

sed 的高频考点集中在原地替换和分隔符上。把配置文件里所有/usr/local/app换成/opt/app，直接写sed -i 's/\/usr\/local\/app/\/opt\/app/g'会看到一屏反斜杠，实际工作中更常见的写法是换分隔符：sed -i 's#/usr/local/app#/opt/app#g'。这里有个新手常踩的坑——-i在不同平台上的行为不一致，某些环境下必须写成sed -i ''才能正常执行。生产环境改配置前，我一定先跑一遍不带-i的版本看输出，确认无误再落盘，这个习惯帮我避免过至少两次事故。

grep 的深度在于上下文检索。查日志时只知道报错内容但不知道前后发生了什么，grep -C 5 "OutOfMemory" app.log会把报错行的前后五行一起带出来，-B和-A则分别只看前和后。再加一个--include='*.log'配合-r，就能在几层目录里只搜日志文件，不至于把二进制文件也翻出来刷屏。

2.2 权限、用户与 umask，年年考但年年有人答错

权限题最常见的问法是："644 和 755 分别代表什么？"这是送分题，但紧接着的那句追问才是分水岭："目录的 x 权限和文件的 x 权限是一回事吗？"答案是不是。对普通文件来说，x 表示可执行；对目录来说，x 表示能否进入这个目录、能否访问目录内文件的元信息。所以只有 r 没有 x 的目录，你连ls都列不出来，更别提读里面的文件了。

再往上，SUID、SGID、Sticky Bit 这三个特殊权限位是面试官的心头好。chmod 4755给可执行文件加上 SUID，运行时进程的有效用户会变成文件属主，passwd命令能改/etc/shadow靠的就是这一手。SGID 用在目录上时，新建的文件会自动继承目录的属组，团队协作目录经常这么配。Sticky Bit 就是/tmp那个1777，作用是目录里的文件只有属主本人能删，别人最多能看能建。

umask 这道题几乎每次都会衍生出一个计算题："umask 是 027 时，新建目录和新建文件的权限是多少？"记法很简单：目录基数是 777，文件基数是 666（出于安全，新建文件默认不带执行位），用基数减 umask。所以 777-027=750，666-027=640。我见过不少人把文件基数也写成 777，一算就露馅。还有一个小细节值得提：umask 是"屏蔽位"而不是"设置位"，它只影响新建对象的初始权限，不会去改已有文件的权限。

2.3 find、xargs 和管道，组合题的重灾区

find 的考点在于筛选条件的组合和-exec与 xargs 的取舍。清理七天前的临时文件：find /tmp -type f -name "*.tmp" -mtime +7 -delete。这里+7表示七天以前，-7是七天以内，7是正好第七天，三个写法的差异经常被拿来当陷阱。

更值得讲的是-exec和xargs的选择。find . -name "*.log" -exec rm {} \;是一条一条执行，文件多了慢得让人想砸键盘；换成-exec rm {} +或者find . -name "*.log" -print0 | xargs -0 rm，会把结果批量传进去，效率高一个量级。为什么非要-print0配-0？因为文件名里可能有空格甚至换行符，默认以换行分隔会被切碎，-0用空字符分隔就不会。这个细节不写出来大部分人不会主动讲，但一说出来，面试官就知道你在真实环境里被文件名坑过。

还有一个反直觉的点：find的-name用的是通配符匹配而不是正则，想用正则得加-regex。我曾经在一个项目里写-name "[0-9]*"想匹配纯数字文件名，结果匹配出一堆以数字开头的文件，排查半天才反应过来方括号在 shell 通配里是字符集而不是正则的字符类。

3. 进程、内存、IO：把系统原理题答成排查题

原理题是最容易背、也最容易被追问的部分。我的建议是：不要把它当"知识点"背，而是当成"排查时我会看哪个文件、哪一列"来记。这样答出来的内容天然带着现场感，而且不容易忘。

3.1 进程状态里藏着的排查线索

ps aux和ps -ef的区别是个高频小问题，答案是前者是 BSD 风格，后者是 UNIX 风格，输出字段略有差异。但真正有含量的是 STAT 那一列：R 是运行或可运行，S 是可中断睡眠（在等事件），D 是不可中断睡眠，Z 是僵尸，T 是停止。其中 D 和 Z 两个状态最值得展开。

D 状态的进程通常卡在等磁盘 IO 或网络文件系统响应，此时它不响应任何信号，连kill -9都杀不掉——不是权限问题，是内核不检查信号。遇到 D 状态堆积，正确的方向不是杀进程，而是去查存储：看一下iostat -x 1里设备的%util和await，是不是磁盘已经跑满。这个"为什么 kill -9 杀不掉 D 状态进程"的问题，我身边能完整答出来的人不到一半。

僵尸进程的成因是子进程退出后父进程没有调用 wait 回收，进程表项还留着。处理方法也很直白：僵尸本身几乎不占资源（只占一个进程号），关键是处理它的父进程，让父进程正常回收，或者让父进程退出，由 1 号进程接管后回收。如果看到僵尸数量持续增长，那基本可以判定是父进程代码里的资源回收逻辑有问题，这时候就该去看代码而不是敲命令了。

顺带说一句进程优先级。Linux 的 nice 值范围是 -20 到 19，数值越小优先级越高，普通用户只能往正的方向调（降低优先级），想提高优先级需要 root 权限。后台运行常用nohup command &，但如果已经在前台跑起来了，可以用 Ctrl+Z 挂起，再bg放到后台、disown让它脱离当前 shell 的作业控制表，这样终端关掉也不会被挂断信号带走。

3.2 free 命令的输出，怎么读才不会被追问倒

free -h这份输出里，最容易被误读的是 buff/cache。很多人一看"可用内存只剩 200M"就慌了，其实 Linux 会把空闲内存尽量拿来做文件缓存，这部分是可回收的，真正该看的是 available 这一列，它才是内核估算出来"新程序要内存时实际能拿到多少"。

真正内存吃紧的信号是 swap 在被频繁使用。vmstat 1输出里的 si 和 so 两列分别代表从 swap 换入和换出，如果这两个值持续不为零，说明物理内存已经不够，系统在拿磁盘当内存用，性能会断崖式下跌。再严重一步就是 OOM Killer 出手，dmesg | grep -i "out of memory"能看到它杀了哪个进程，以及当时的内存快照。这道题如果只答"free 看内存"，面试官多半会追一句"那 buff/cache 算不算占用"，答不上来分数就掉了。

3.3 load average 高但 CPU 空闲，到底发生了什么

这是我最喜欢问的一道题，因为它能把"背过 top"和"理解 top"的人干净利落地分开。load average 统计的是运行队列里处于可运行状态和不可中断睡眠状态的进程数，注意后半句——D 状态的进程也算进去。所以当磁盘 IO 打满时，一堆进程堵在 D 状态，load 会飙到很高，但 CPU 因为无事可做，使用率可能只有百分之十几。

判断思路就三步。第一步top看 load 和使用率的组合：load 高、CPU 低，几乎可以锁定 IO 或锁等待。第二步vmstat 1看 b 列（阻塞进程数）和 wa 列（IO 等待占比），wa 长期偏高就实锤了。第三步iostat -x 1看具体是哪块盘，%util接近 100% 说明设备已经饱和，await是平均等待毫秒数，数值明显偏大说明有排队。这一套走下来，才是面试官想听到的答案，而不是"load 高于核数就有问题"这种含糊的判断。

4. 现场排查题：面试官最爱看的那条完整链路

排查类题目的特点是没法背，因为面试官会顺着你的回答一直往下问。反过来说，只要你能把一条链路完整讲出来，这一轮基本就过了。下面四道题是出现频率最高的，我把链路拆开写。

4.1 CPU 使用率飙到 100%，你从哪一步开始

标准链路是：top找到高 CPU 的进程号，记下 PID；top -Hp PID看这个进程里哪个线程占得最狠；把线程号转成十六进制，printf "%x\n" TID；如果是 Java 应用，jstack PID | grep -A 20 十六进制线程号，就能看到那个线程当时在跑什么代码。如果是非 Java 应用，可以用perf top -p PID或者pidstat看热点函数。

这里有个很容易被忽略的细节：top默认按 CPU 排序，在多核机器上按的是所有核加起来的总占用，一个把单核跑满的进程在 8 核机器上只显示百分之十几，容易被漏掉。这时候按一下数字键 1 展开各核，或者干脆用top里按 P 强制按 CPU 排序再看。还有一种情况是us和sy的比例，用户态高说明是应用自身的问题，系统态高就要怀疑是不是在疯狂做系统调用，比如频繁读写小文件。

我实际处理过一次线上告警，CPU 占用一直在 60% 左右不算特别高，但接口延迟抖得厉害。最后查出来是某个定时任务在批量读小文件，sy占比异常，把 IO 也拖起来了。这件事让我养成了一个习惯：看 CPU 从来不只看一个总数，一定同时看 us、sy、wa 三个值。

4.2 磁盘写不进去，是空间满了还是 inode 用完了

很多人第一反应是df -h，但df -h只反映块空间，还有一半的可能是 inode 被耗尽。报错信息通常是 "No space left on device"，但df -h显示还有几十 G 空闲——这时候换df -i一看，inode 已经是 100%。成因通常是某个目录下堆了海量的小文件，比如临时文件没清理、缓存目录膨胀。

定位方法是从根目录一层层往下找：du -sh /*排序，确定是哪个一级目录爆了，然后逐层深入。文件数量太多的话du会很慢，可以先find /path -xdev -type f | wc -l数一下文件数，确认是不是小文件问题，再决定怎么清理。清理 inode 的时候还要注意，删掉文件只是释放 inode，如果进程还持有这些文件的句柄，空间和 inode 都不会立刻归还，这个坑下一节细说。

4.3 文件删了空间没释放，是怎么回事

Linux 里文件的空间释放条件是"链接数为零且没有任何进程打开它"。进程正在写日志的时候你用rm删掉，文件名消失了，但那个进程手里的文件描述符还指向这块数据，磁盘空间就一直占着。经典的定位命令是lsof | grep deleted，它会把所有被删除但仍被打开的文件列出来，后面跟着持有它的进程号。

解决办法有两种：一是重启或者让那个进程自己重新打开日志文件（很多服务收到特定信号会重新打开日志，配合日志切割工具用），二是用> /proc/PID/fd/N这种写法清空内容而不是删除文件。生产上更稳妥的做法是从一开始就用日志切割工具管理，避免直接rm正在写的日志。这道题几乎每次问都会带出lsof的用法，顺带一提lsof -p PID还能查一个进程打开了哪些文件和连接，排错时非常好用。

4.4 DNS 解析异常与中文文件名解压乱码

这两道题看着不搭，但它们有个共同点：都属于"配置和编码细节"类问题，答得好特别加分。

DNS 这块，常见现象是ping 域名不通但ping IP通。排查顺序是：先cat /etc/resolv.conf看 nameserver 配得对不对，再cat /etc/hosts看有没有被本地记录劫持，然后dig 域名或nslookup 域名确认解析链路。有个高频坑是/etc/resolv.conf被网络管理服务覆盖——手动改完重启网络又变回去了，说明有服务在托管它，得去改对应的配置源，而不是直接改这个文件。另外要注意nsswitch.conf里 hosts 那一行的顺序决定了先查文件还是先查 DNS，而 resolv.conf 里的 nameserver 一般最多生效三个，写多了后面的不生效。

中文压缩包乱码是另一个经典场景。在本地打包的中文文件名压缩包，传到服务器上解压出来一堆问号或者乱码，原因是打包时用的是 GBK 编码，而服务器默认按 UTF-8 解释。用 unzip 的话可以加-O CP936指定编码；tar 包则要看打包时的编码情况，必要时可以先解出来再用convmv -f gbk -t utf8 -r 目录批量转换文件名。这里有个注意事项：转换前务必备份，因为文件名转换是不可逆的，转错了只能重新打包。要想从根上避免，打包前统一用 UTF-8 环境，或者干脆在打包时避免中文文件名。

5. 把答案讲出"我做过"的味道

技术对的人不少，能把技术讲清楚的人不多，这是面试里一个很现实的落差。这一章聊的是表达层面的事，但它的重要性不比技术本身低。

5.1 结论先行，再补证据链

面试官也是人，一天面七八个候选人，注意力是有限的。所以回答问题时不要从背景铺垫开始，先把结论抛出来。举个例子，问"服务器变慢了怎么查"，先给一句"我会按 CPU、内存、磁盘、网络四个方向逐个排除，先看资源有没有瓶颈，再看是不是单点服务的问题"，然后每个方向讲一个具体的命令和一个判断标准。这样面试官能立刻抓住你的框架，后面追问哪个细节都有话说。

我见过太多候选人，一道题讲了五分钟还在铺垫背景，面试官已经走神了。技术表达的核心其实是信息密度，不是长度。你完全可以把"我遇到过类似情况，当时的排查顺序是……"这句话当作开场，既给了结论，又天然带上了实战经历，一举两得。

还有一点值得说：尽量在回答里带上具体数字。比如"我们的日志文件一天大概涨到 20G，所以切割按小时做"，比"我们会做日志切割"有说服力得多。数字是最便宜的可信度证明。

5.2 遇到不会的题，怎么接住

没有人什么都知道，关键是别慌、别编。我自己的做法是先诚实说"这块我没有实际处理过"，紧接着给出思路："如果让我来解决，我会先从 A 方向看，因为……，如果 A 没问题就到 B 方向。"很多面试官其实不在乎你会不会，而在乎你面对陌生问题时的分析方法。编答案是最危险的，因为追问两句就会露馅，一旦被发现编造，前面答得再好也会被扣分。

另一个技巧是把不会的题引到你熟的领域。比如问了一个你没碰过的内核参数，你可以说"这个参数我没调过，不过类似的场景我用过另一个方式处理，思路是这样的……"。注意，是自然过渡，不是硬拗，硬转话题面试官听得出来。

6. 复习节奏与反问环节怎么安排

最后说点备考方法层面的东西。技术题会背不代表考场上能想起来，复习的节奏和方式其实很影响发挥。

6.1 两周的复习清单怎么排

我不建议按"命令大全"的顺序从头扫一遍，那样记不住也没重点。更有效的排法是按排查场景归类：

• 第 1 到 3 天：命令基础与文本处理，重点是 grep、sed、awk、find 的组合使用，配合几个真实日志做练习
• 第 4 到 6 天：进程与资源，重点是 ps/top/vmstat 的字段含义，动手制造一次僵尸进程和一次内存压力看看输出长什么样
• 第 7 到 9 天：磁盘与 IO，重点是 df 与 df -i 的差异、lsof 定位被删除的文件、iostat 读表
• 第 10 到 12 天：网络与服务，重点是 ss、dig、resolv.conf、systemctl 与日志查看
• 第 13 到 14 天：把上面所有链路连起来，用一台虚拟机自造故障自己排查

这个排法最关键的是最后一步。看别人写的排查步骤和自己动手做出一次故障，记忆深度完全不是一个量级。我最推荐也最推荐给别人推荐的练习方式，就是在一台测试机上手动制造几个故障——把某个目录塞满小文件、用 tail 打开一个日志然后删掉它、起一个死循环的 CPU 消耗进程，然后不看答案自己排查一遍。做过一轮之后，所有"Linux 面试题"的答案都会从记忆题变成经验题。

6.2 轮到你提问的时候，问什么

面试最后一般会留时间让你提问，很多人说"没有问题"，这其实是在浪费一次加分机会。合理的问法是把问题和岗位绑起来，比如"这个岗位日常处理最多的 Linux 场景是哪个方向"、"团队现在的监控和日志体系大概是什么样的"。这类问题既显得你真的想干活，也能帮你判断这个岗位值不值得去。

我个人最看重的一个问题，是问对方"如果线上出了故障，从发现到定位一般是几个人负责，流程是怎么走的"。对方的回答基本能反映出这个团队的技术成熟度：有明确流程的团队，日常肯定有规范的排查工具和复盘机制，进去之后能学到东西；如果回答含糊其辞，那多半是救火队模式，做好长期加班的心理准备。

至于复习的强度，我的实际体会是：Linux 面试题从来不需要"背一百道"，把二十道挖到底、亲手复现过一遍，比背一百道浅层答案管用。命令是死的，排查链路是活的，面试官要的是后者，工作中真正用得上的也是后者。