1. 文件与目录操作：看似基础，细节最见功底

我在面试候选人的时候，习惯先问一个特别简单的题目：“在Linux里，软链接和硬链接的区别是什么？”千万别觉得这题太基础，恰恰是这种题最能区分“背过命令”和“真正理解系统”的候选人。很多人能说出“软链接相当于Windows的快捷方式，硬链接就是文件名指向同一个inode”，但一问到“删掉源文件之后，两者分别会怎样？硬链接能不能指向目录？能不能跨文件系统？”就卡住了。

这轮题目是Linux面试的“入场券”，高频、经典、看似简单，但考察点非常密集。如果你正在准备面试，这部分不建议死记答案，而是要在自己的机器上把每个命令亲手敲一遍，观察现象，理解背后的机制。

1.1 考察点：软链接 vs 硬链接，面试官到底想听什么

先说标准答案，但我会拆开讲，因为面试官想听的不是定义，而是你对“inode”这个核心概念的掌握程度。

硬链接：本质是同一个inode的多个目录项（dentry）。创建一个硬链接，只是在一个目录里新增一个文件名，指向同一个inode。inode里面存着文件的元信息（权限、所有者、大小、时间戳）和数据块指针，但不存文件名。所以硬链接的文件和被链接的文件，是同一个文件的两个名字。用ls -l看，链接数（第二列）会加1。

软链接：本质是一个独立的文件，这个文件的内容是另一个文件的路径。它有自己的inode，有自己的权限（通常就是777，实际生效看目标文件的权限）。它和Windows的快捷方式在逻辑上确实很像，但底层实现完全不同。

关键点在于：

• 删掉源文件，硬链接依然可以正常访问，因为inode还在，数据还没被真正释放（只有当所有硬链接都被删除，inode和数据块才会被释放）。软链接则变成“悬空链接”，指向一个不存在的路径，访问会报No such file or directory，但ls -l依然能看到这个链接本身。
• 硬链接不能跨文件系统，因为不同文件系统有自己的inode编号空间，你不能用一个文件系统的inode去“冒充”另一个文件系统的文件。软链接只是一个路径字符串，所以随便跨，哪怕指向一个不存在的路径也没问题。
• 硬链接不能指向目录，这是出于安全考虑，避免目录之间形成环（比如目录A硬链接到目录B，B又硬链接回A），导致递归遍历死循环。软链接可以指向目录。

面试官如果继续追问“为什么硬链接的inode是同一个，修改其中一个文件，另一个也会变”，你要能回答：“因为底层就是同一份数据块，从一个入口改了内容，另一个入口看到的就是改完的内容。软链接因为是指向路径的，所以对内容的修改其实也是通过目标路径去改的，效果一样，但本质不同——硬链接连inode都共享，软链接只是路径引用。”

1.2 考察点：find 命令的花式用法，考察真实场景解决能力

find也是Linux面试的常客，但很多人只会find / -name "xxx"。真正到了实战场景，比如磁盘告警了，你要找出所有大于1G的文件并排序；或者要清理一个目录下7天前的日志文件，只会-name是完全不够的。

我推荐你把下面这些用法吃透：

# 按大小找，比如大于1G的文件，并把绝对路径列出来 find /data -type f -size +1G -exec ls -lh {} \; # 按时间找，7天前修改过的日志文件，直接删除 find /var/log -name "*.log" -mtime +7 -type f -exec rm -f {} \; # 按权限找，找出来所有其他用户可写的文件，排查安全风险 find / -type f -perm -o+w 2>/dev/null # 最经典的按进程找文件：找出正在被删除但还被进程占用的文件 find /proc/*/fd -lname "deleted" -printf "%p -> %l\n"

最后这个是老运维才会用的技巧。线上排查“磁盘空间已经释放了，但df还是显示100%”的问题时，靠的就是查/proc下所有进程的文件描述符，找出那些被rm掉但还被子进程占用的文件。面试时你如果主动提这个场景，面试官对你的印象会明显不一样，因为它说明你是真处理过线上故障的人。

find的-exec是个高频考点。要注意{} \;和{} +的区别：分号结尾是对每个找到的文件执行一次命令，加号结尾是把所有找到的文件一次性作为参数传给命令。处理大量文件时，+的效率远高于\;，因为进程启动次数少很多，面试时最好能说出这一层。

1.3 考察点：路径问题，绝对路径、相对路径和cd -

路径问题看起来更基础，但有个经典坑：cd -是什么？答案是“回到上一个所在目录”，它依赖环境变量OLDPWD。面试官喜欢用这种小题目试探你有没有实际敲过命令，而不是只看书。

还有一个经常被坑到的场景：脚本里用了相对路径，然后放在 crontab 里跑，结果找不到文件。因为 cron 环境下的当前目录是用户的 HOME，不是你写脚本时所在的目录。所以生产环境的脚本，开头第一行先cd "$(dirname "$0")"，切换到自己所在的目录，这是很多新手没意识到的坑。面试如果聊到“你的脚本在命令行能跑，放crontab就报错”，这就是标准答案。

2. 权限与用户管理：从命令背诵到安全思维

权限题几乎是Linux面试的必考题，而且面试官问的深度天差地别。初级问法是“chmod 754 是什么意思”，中级问法会涉及SUID、SGID、Sticky Bit，高级问法会直接给你一个生产场景：“你发现系统里一个二进制程序运行时会创建某个文件，但创建出来的文件属主居然是root，这是为什么？”

2.1 考察点：chmod 数字权限的推导逻辑

chmod 754的含义，7=4+2+1=rwx，5=4+1=r-x，4=r--。这个背下来不难，但面试官更想听的是你对三类身份的理解：owner、group、other。

我建议你用另一种方式去记：数字模式的本质是二进制。r=4（二进制100），w=2（二进制010），x=1（二进制001）。你把三类身份的权限写成三个二进制位，就明白为什么可读永远是4，可写永远是2，可执行永远是1——这三个数字在二进制里分别对应不同的bit位。

还有一个高频题：chmod和chown的区别。答案很简单：chmod 改权限位（rwx），chown 改属主和属组。但真正容易踩坑的是：普通用户对自己的文件执行chown会提示Operation not permitted，因为把文件所有权转移给别人，是一种需要root权限的操作，否则你能随便把文件丢给别人，就能绕过各种磁盘配额和审计机制了。

2.2 考察点：SUID、SGID、Sticky Bit，三种特殊权限位

特殊权限位是权限题的分水岭。理解它们，关键要抓住一个核心思想：“这个程序运行时，是以谁的权限在跑？”

SUID (Set User ID)：作用于可执行文件，用数字4表示。当一个文件设置了SUID位，普通用户执行这个文件时，进程的有效用户ID（EUID）会临时变成文件属主的UID。最经典的例子就是/usr/bin/passwd：普通用户需要修改自己的密码，但/etc/shadow只有root能写，怎么办？passwd程序的属主是root，设置了SUID位，于是一般用户执行passwd时，进程以root身份运行，就能改shadow文件了。实际面试里，如果你能说出来“SUID是二进制位，在属主权限的x位上体现，用ls -l看是-rwsr-xr-x”，就已经超越大多数候选人了。

SGID (Set Group ID)：数字2表示。作用于可执行文件时，进程的有效组ID会变成文件属组；作用于目录时，在该目录下新建的文件会自动继承目录的属组，而不是创建者的基本组。这个特性常用于团队共享目录，团队成员不管谁往目录里放文件，文件的属组始终是团队组，组内成员就能互相修改了。SEO团队目录如果没设SGID，A用户创建的文件B用户可能碰都碰不着，这就是为什么很多共享目录方案首选SGID。

Sticky Bit (SBIT)：数字1表示。只对目录有意义，典型例子是/tmp。设置了Sticky Bit的目录，所有用户都能在里面创建文件、写文件，但只能删除自己拥有的文件，不能删别人的。这个特性在面试里通常和安全场景挂钩——面试官会问“如果 /tmp 没有Sticky Bit会怎样”，答案是“任何用户都能删除 /tmp 下其他用户的临时文件，这是一个非常严重的本地安全漏洞”。

你还需要知道怎么设置：chmod u+s file是加SUID，chmod g+s dir是加SGID，chmod +t dir是加Sticky Bit；也可以数字法chmod 4755 file。查找位的方式：find / -perm -4000 2>/dev/null找出所有带SUID位的文件，这是安全审计必做的一步。

2.3 考察点：新建用户的完整流程，别只会 useradd

“Linux 怎么新建用户”是初阶题，但面试官会把问题升级：“新建一个用户，指定它的家目录、指定uid、指定登录shell，然后设置密码，需要哪些步骤？”很多人只会useradd username和passwd username，但到了指定参数就蒙了。

一个完整的、可上生产的命令是：

useradd -u 1501 -d /home/tom -m -s /bin/bash -G devops,tools tom echo "tom:初始密码" | chpasswd

-u指定UID，-d指定家目录，-m表示如果家目录不存在就创建，-s指定登录shell（如果指定为/sbin/nologin，这个用户就不能登录系统，常用来跑服务），-G指定附加组。

面试官可能会追问：“你新建了一个用户，这个用户想用sudo，怎么做？”答案是usermod -aG wheel tom（CentOS系）或usermod -aG sudo tom（Ubuntu系），然后用visudo编辑 sudoers 文件。注意-aG的-a很重要，它表示append（追加），如果不加，会把这个用户从其他附加组里移除，只保留当前指定的组。

还有一个隐藏考点：/etc/passwd和/etc/shadow的分工。passwd文件存的是用户的静态信息（用户名、UID、GID、家目录、shell），密码位通常是个x，真正的密码哈希放在shadow文件里，shadow文件只有root能读，这样防止普通用户拿到哈希去做暴力破解。面试官如果问“为什么password文件里密码位是x而不是哈希”，你要能答出这层安全设计逻辑。

3. 进程、内存与系统调优：运维和开发都绕不开的硬核题

这一部分面试题，开发背景的候选人容易栽。因为日常写代码很少关心操作系统的调度和资源管理，但一旦你的服务部署到Linux服务器上，内存泄漏、CPU飙高、僵尸进程、负载异常膨胀，每一个都是要命的线上事故。面试官从这部分开始，就已经不是在考察“知识”，而是在考察“解决问题的思路”。

3.1 考察点：僵尸进程是怎么产生的？一定不能回答“杀掉”

我看到很多面试题答案是“用 kill -9 杀掉僵尸进程”，这是错的，而且错得非常典型。

僵尸进程（Zombie Process）的本质是：子进程已经终止，但它还把退出状态留在进程表里，等待父进程调用wait()或waitpid()来回收。这时候进程已经不再占用CPU和内存资源，只是占据了一个进程表项（PID）。你kill -9一个僵尸进程，是无效的，因为僵尸进程已经死了，没有信号处理能力，kill 信号根本不起作用。

正确答案应该是分两条线：

1. 根源：僵尸进程的产生，是父进程没有正确回收子进程的退出状态。如果是你自己写的程序，需要修复代码，在父进程里调用 wait()；如果是常见服务，检查父进程是否异常卡住。
2. 应急：如果僵尸的父进程是 init/systemd (PID 1)，通常会自动回收。如果父进程一直不回收，你需要处理的是“父进程”而不是“僵尸进程”——找到僵尸进程的PPID，然后处理它的父进程。

处理命令：

# 查看系统里的僵尸进程 ps -ef | awk '$3=="Z" || $8~/<defunct>/{print}' # 或者用 top 看，STAT 列为 Z 的就是 top -b -n 1 | grep zombie # 找到僵尸进程的父进程PID ps -o ppid= -p <zombie_pid>

如果父进程是正常的业务进程，修复代码是关键；如果父进程本身已经失去响应，那就需要把父进程重启或结束掉，让PID 1接管并回收剩余的子进程。面试时能把这个逻辑链说清楚，比单纯背答案要好得多。

3.2 考察点：CPU飙高排查，标准五步法

“线上CPU突然飙到99%，你怎么排查？”这是运维开发和SRE岗位的必问题。标准思路要有层次感，我把它拆成五个步骤：

第一步：top -c找到CPU占用最高的进程，拿到PID，同时看整体负载情况。

第二步：top -Hp <PID>或者ps -eLo pid,tid,pcpu,comm | sort -k3 -rn | head -20，找到这个进程内到底是哪个线程在吃CPU，拿到线程ID（TID）。

第三步：把TID转成十六进制：printf "%x\n" <TID>。这一步是为了去线程dump里找对应线程。

第四步：jstack <PID> | grep -A 30 "nid=0x<十六进制TID>"（Java应用），或者用gdb attach，拿到线程当前的调用栈。看它到底卡在哪个方法、哪个循环里。

第五步：根据调用栈定位代码问题，是死循环、正则回溯爆炸、还是频繁GC、又或者是业务逻辑里有耗时的IO调用。

整个过程面试官愿意听的不是你背了哪条命令，而是你这五步之间的逻辑关系：从进程找到线程，从线程找到代码，一层一层收敛。我做面试官时，只要候选人能主动说出“top -H 看线程”，我就知道这个人真的处理过线上问题，因为只看书的人不会知道这一步。

3.3 考察点：free 命令输出，你真的看懂了吗

free -h的输出，有一块最容易误解：有时候free那一列很小，但系统并没有内存压力，因为有一部分内存被用作了缓存（buff/cache）。Linux的内存管理哲学是“空闲内存不如用来做缓存”，所以它会尽可能多地把内存当作page cache，加速磁盘IO。

面试要掌握的核心是：判断系统到底缺不缺内存，不能只看free一列，要看 available。available 表示“在不触发swap的前提下，还能分配多少内存”，它会把可回收的cache算进去。所以在CentOS 7之后的版本，free -h直接展示 available 列，就是用来纠正“只看free”的误区。

还有一个常见追问：“系统开始用swap了，是不是说明内存不够了？”答案不绝对。Linux有 swap 的 swappiness 参数（默认60），它控制内核“倾向于把内存页换出到swap”的程度。如果设置了 0，表示尽量避免swap；如果服务对延迟敏感，很多团队会把 swappiness 调成 10 甚至 0。但也有场景，比如内存充足的机器，偶尔有一点swap也不代表一定有问题，关键看是否持续、是否伴随严重的IO等待。

用 sysctl 调优的姿势：

# 查看当前值 sysctl vm.swappiness # 临时调整 sysctl vm.swappiness=10 # 永久生效，写入 /etc/sysctl.conf echo "vm.swappiness = 10" >> /etc/sysctl.conf sysctl -p

3.4 考察点：Linux 的 OOM Killer，数据库进程被杀的原因

这个问题面试频率很高，因为大多数Java后端或者数据库进程，都遇到过“半夜进程突然没了”的惨案，查日志发现是 OOM Killer 把进程杀了。面试官问“你的MySQL怎么突然挂了”，如果你能答出“被OOM Killer杀了”，并继续解释原因，那这题就是加分项。

OOM Killer的机制是：当系统内存严重不足时，内核会挑一个进程杀掉，释放内存。不是随机挑，而是根据每个进程的 oom_score 来选。评分越高，越容易被杀。oom_score 一部分由进程占用内存量决定（内存越大分越高），另一部分由oom_score_adj决定，它默认是0，但某些系统服务（比如sshd）会设置负值来保护自己。

保护重要进程的办法是设置oom_score_adj为一个负值，比如：

echo -1000 > /proc/<PID>/oom_score_adj

用systemd管理服务的话，在service文件里加：

OOMScoreAdjust=-500

调优建议：优先考虑减少内存占用和排查内存泄漏，而不是单纯调低 oom_score。因为如果系统真到了必须杀进程才能续命的地步，把数据库进程保护起来，可能会导致系统hang死，这是一个比较微妙的取舍，面试时能谈到这一层就已经赢过大多数候选人了。

4. 网络排查与故障定位：靠“经验”而非“背诵”拉开差距

网络这块的面试题，边界很清晰：如果面后端开发，重点在HTTP协议、TCP三次握手、端口连通性排查；如果面运维/SRE，重点在tcpdump抓包、内核网络参数调优、负载均衡、DNS解析链路。我挑几个最高频、最有区分度的题来讲。

4.1 考察点：端口不通排查链路，从链路层到应用层

经典的面试题叫做“两台机器之间，端口明明开着，但客户端就是连不上，你怎么排查？”这题没有标准答案，但有标准思路——逐层向下排查。

我推荐的顺序是：

# 1. 先ping，确认三层通不通 ping <目标IP> # 2. 再telnet或nc，确认端口通不通（四层） telnet <目标IP> <PORT> # 或者 nc -vz <目标IP> <PORT> # 3. 看本机有没有监听端口（在目标机器上执行） netstat -tlnp | grep <PORT> # 或者用 ss，ss比netstat更快更现代 ss -tlnp | grep <PORT> # 4. 检查防火墙规则 systemctl status firewalld # CentOS系 iptables -L -n -v # 看INPUT链是否有DROP # Ubuntu 的话看 ufw status # 5. 如果是云环境/跨机房，要检查安全组、ACL

这里隐藏着一个重点：ss和netstat的区别。面试官问“这两个命令有什么区别”时，正确回答是：netstat 通过读取 /proc/net 下的文件来获取信息，ss 直接和内核通信，所以ss更快，而且在高并发连接数下，netstat 容易卡顿甚至输出不准确。现在新安装的Linux系统都自带ss，netstat 反而需要额外安装 net-tools 包。这个细节很能体现你对现代系统工具的掌握程度。

还有一种非常典型的场景：防火墙把端口drop掉和reject掉，表现完全不同。DROP是客户端一直卡在连接状态，直到超时；REJECT是客户端立刻收到Connection refused。这个区别在排查“为什么telnet卡半天”的故障里非常有用。

4.2 考察点：TCP三次握手、四次挥手，用什么抓包证明

TCP的握手和挥手是Linux面试题里“最经典中的经典”，但经典题也能问出新意。面试官可能会说：“别背书，告诉我你用什么命令能看到三次握手的过程？”

答案是tcpdump，而且这是一个非常能体现实战能力的命令。

# 在目标机器上抓80端口的所有包 tcpdump -i eth0 port 80 -nn -S # 抓完后能看到 SYN, SYN-ACK, ACK 三个包的流转

-nn表示不做DNS反解，不显示服务名，直接显示IP和端口，抓包时一定要加，否则会非常慢且输出混乱。-S表示显示绝对序列号，默认tcpdump显示的是相对序列号，在做包分析时容易困惑。

面试官如果继续深挖：“你连不上一个远程服务，抓包看到对面回了RST包，怎么分析？”这时候你要知道RST包的含义：TCP收到一个无法处理的报文时，会回复RST重置连接。可能是端口没监听，可能是防火墙REJECT，也可能是连接队列满了。RST出现的位置和上下文不同，原因完全不一样。面试能说到这层，就已经超出只背三次握手的候选人了。

4.3 考察点：如何实时看一个端口被哪些进程占用

这个问题看起来简单，但现场实战非常高频。很多人会背netstat -tlnp | grep 8080，但这有个问题：如果端口是通的，但进程是别人用-p参数看不到的（权限不足），怎么办？

推荐组合拳：

# 查看端口监听情况（注意不带-p也能看，但只有root能看到进程名） ss -tlnp sport = :8080 # lsof 也很直观 lsof -i :8080

如果是“端口没有监听，但连接能通”的情况，那就要查是不是有iptables的 REDIRECT 或者 DNAT 规则在捣鬼。这个知识点面试官大概率不会直接问，但作为加分项说出来，会非常惊艳。

5. Shell脚本与文本处理：写出的东西要能上生产

“你在Linux环境里，最常用的三个命令是什么？”这道题经常被当作暖场题，但回答上下限差距极大。新人答“ls、cd、cat”也没错，但如果能答出“awk、grep、sed三件套”，并配上真实的使用场景，面试官立即就知道你平时是在命令行里干活的。

5.1 考察点：grep 的经典用法和“坑”

grep的高频用法：

# 递归搜索目录下所有文件，输出匹配行的文件名和行号 grep -rn "error" /var/log/ # 只看某类文件，比如 .log 文件里搜关键字 grep --include="*.log" -rn "ERROR" /var/log/ # 排除某个目录 grep -rn "password" /etc/ --exclude-dir=ssl # 正则匹配，比如匹配所有IP地址 grep -E -o "[0-9]{1,3}(\.[0-9]{1,3}){3}" /var/log/syslog | sort | uniq -c | sort -rn

一个容易踩的坑：在管道中grep到大量文件时，比如ps aux | grep java，会匹配到grep本身那条进程。因为grep java的命令行里包含字符串“java”，所以会把grep自己的进程也匹配出来。老手都会在 grep 后面加一个方括号技巧：ps aux | grep [j]ava。方括号让“java”这个字符串在命令行里变成“[j]ava”，grep自身那一行就不再匹配，而Java进程命令行里是真正的“java”，依然能被匹配到。这个小技巧面试官如果看到了，会心一笑。

5.2 考察点：awk 和 sed，一页纸理解核心

awk 的处理模型是做“列处理”，逐行读取，按分隔符（默认空格）把一行拆成列，然后对每一列做操作。核心变量：NF 是当前行的字段数，NR 是当前行号，$0 是整行，$1、$2...是第1列、第2列。

高频用法：

# 打印第1列和最后一列 awk '{print $1, $NF}' /etc/passwd # 按冒号分隔，打印用户名和shell awk -F: '{print $1, $7}' /etc/passwd # 算某列的和，比如统计文件大小总和 ls -l /var/log/*.log | awk '{sum += $5} END {print sum}' # 找出某个目录下大于1G的文件并排序 find /data -type f -size +1G -exec ls -lh {} \; | awk '{print $5, $9}' | sort -rh

sed 是做“行处理”的，主要操作是替换、删除、插入。

# 将所有 old 替换成 new，注意是全局替换 sed 's/old/new/g' file.txt # 直接修改文件（加 -i 参数），生产环境建议先不带 -i 试运行一次 sed -i 's/old/new/g' file.txt # 删除第10到20行 sed '10,20d' file.txt

sed 的-i参数，在 macOS 和 Linux 上报错方式不一样（macOS 需要sed -i ''），面试官如果问到跨平台，你能说出来这个差异，又是一个加分点。

5.3 考察点：nohup 和 & 的区别，以及 nohup 的坑

“后台运行一个服务，为什么用 nohup 而不是直接用 &”是一个非常经典的面试题。标准答案是：&只是把进程放到后台，但进程的stdout和stderr仍然绑定到当前终端；如果终端关闭，进程会收到 SIGHUP 信号而退出。nohup的作用是忽略SIGHUP信号，配合&使用，才能真正脱离终端运行。

正确的起服务姿势：

nohup java -jar app.jar > /data/logs/app.log 2>&1 &

这部分面试官爱追问的是：2>&1是什么意思？答案是：把标准错误（文件描述符2）重定向到标准输出（文件描述符1）当前指向的地方，也就是日志文件。注意顺序很重要，> /data/logs/app.log 2>&1和2>&1 > /data/logs/app.log结果完全不同——后者stderr会指向终端，而非日志文件。这个细节在现场实战中能直接决定你的日志是否完整。

5.4 考察点：文本处理三件套综合实战

很多面试官喜欢出一个综合题：“有一个日志文件，每行是一个访问记录，格式是IP 时间 URL 状态码，现在让你统计访问量最多的前10个IP，并输出IP和次数，你会怎么做？”

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

这个链路的每一步都值得展开：

• awk '{print $1}'：提取第一列（IP）
• sort：把相同的IP排到一起，因为uniq -c只能统计相邻的行
• uniq -c：统计连续相同行的数量
• sort -rn：按次数从大到小排
• head -10：取前10

如果面试官继续加码：“URL里的查询参数要忽略，只统计路径，怎么做？”答案是用 awk 的 -F 指定分隔符，或者用 grep -o 提取正则匹配的路径部分。这种题没有唯一答案，面试官想看的是你能否熟练运用文本处理工具解决具体问题。

6. 磁盘、存储与文件系统：很多老手也会栽的题目

磁盘这块的面试题，很多候选人分不清“文件系统满了”和“inode满了”的区别，这在面试里是明显的减分项。其实这两个问题是两个层面：一个是磁盘块空间不足，一个是文件系统元数据表满了，表现完全不同。

6.1 考察点：inode 耗尽，df 还有空间但系统报错

现在固态硬盘容量越来越大，每个文件的最小占用是1个块（通常是4KB），但每个文件还需要消耗1个inode。如果你的磁盘上全是密密麻麻的小文件——比如一堆1KB的临时文件、缓存碎片、邮件队列——磁盘可能还有空间，但inode表已经满了，这时候你touch一个新文件都会报No space left on device。

排查命令：

# 查看各文件系统inode使用率 df -i # 找出那个目录下文件数量多到离谱 find /data -maxdepth 3 -type d | while read dir; do echo "$dir $(ls "$dir" | wc -l)"; done | sort -k2 -rn | head -10

解决方案分两种：一是清理小文件，二是如果确实需要大量小文件，就得规划大inode的文件系统。格式化时指定-i参数（每多少字节分配一个inode）或指定-N（指定inode总数）。这是运维要掌握的技能，面试能谈到这个层面，说明你真的处理过存储问题。

6.2 考察点：df 和 du 不一致的三层原因

“为什么df显示磁盘满了，但du查不到大文件在哪儿”是线上排障的经典问题。原因至少有四个层面：

1. 删除了文件但进程还在占用：这是最常见的，rm掉一个大文件，但某进程仍持有文件句柄，磁盘空间不会真正释放。解决办法是lsof | grep deleted找到进程，重启或让进程重新打开文件。

2. 文件系统有快照：比如LVM快照、ZFS快照，快照里还保存着旧数据，df会计算在内，但du找不到。

3. 挂载点遮挡（mount bind）：你删除的文件在某个子目录，但子目录被另一个挂载点遮挡了，df统计的是整个挂载点的使用量，du看到的是当前目录树，两者计算范围不一致。

4. 稀疏文件（sparse file）：文件逻辑大小很大，但实际物理占用很少。du 按实际块数算，df 按文件系统层算，两者结论会不同。

面试能把这个链条里至少前三层说出来，面试官就会认定你是经历过“故障轰炸”的人，而不是只看过视频的初学者。

6.3 考察点：软RAID 还是 硬RAID？LVM 到底解决了什么问题

这块偏系统设计，面试官问“你了解LVM吗”，回答思路可以是：

LVM（Logical Volume Manager）就是“存储的金刚圈”——在物理磁盘和文件系统之间加了一层逻辑卷层。它解决的核心问题是“分区大小固定，扩容太麻烦”。你有一块500G的磁盘，传统分区方案，建了一个100G的 /data 分区，想扩到200G，如果相邻空闲空间够就直接扩，不够就非常麻烦。LVM的做法是：把物理磁盘分区/整盘做成PV（物理卷），多个PV合成VG（卷组），VG就像一大块“存储池”，再从池子里切LV（逻辑卷）给文件系统用。这样扩容时只要VG里有空闲，一条lvextend就能给LV加空间，不用管底下物理磁盘的布局。

常用命令：

pvcreate /dev/sdb1 /dev/sdc1 vgcreate myvg /dev/sdb1 /dev/sdc1 lvcreate -L 100G -n data myvg mkfs.ext4 /dev/myvg/data mount /dev/myvg/data /data

动态扩容的完整链路：

# 给LV加20G lvextend -L +20G /dev/myvg/data # 让文件系统感知新空间（不同文件系统命令不同） resize2fs /dev/myvg/data # ext4 xfs_growfs /data # xfs

面到这个层级，你已经不是在背命令，而是在讲存储架构的设计思路。

7. 几道场景综合题：面试官真正想听的答题方式

最后这部分，我放几道综合场景题，它们不是孤立的命令题，而是考察你“遇到问题时怎么分析、怎么讲清楚、怎么给方案”。面试官如果时间充裕，一定会问一两道这样的题。

7.1 场景题：新来的同事把服务器的 /etc 权限改了，整个系统可能出问题，怎么办

这题经常被用来考察“危险操作的修复能力”。候选人别慌，先明确表态：系统还能不能正常登录？如果能登录，优先修复关键文件和目录的权限；如果不能，就要用单用户模式/救援模式。

常见的/etc权限异常，比如chmod -R 777 /etc，会导致很多服务无法启动。修复时可以尝试利用安装包重装相关组件来恢复权限：rpm -V可以校验已安装包的文件属性和权限，rpm --setperms --setugid可以按rpm数据库恢复文件权限，Debian系用dpkg --verify和dpkg-statoverride。如果连rpm都用不了，就得进单用户模式，用备份恢复/etc或者用初始化系统自带的工具重建关键配置。

这题考察的重点不是你会不会修复命令，而是遇到高风险操作时，有没有提前做备份的意识和事故恢复预案。所以最好在回答中强调：“我们生产环境所有核心目录变更前，必须先在测试环境验证，且变更前会对 /etc 做完整备份（tar 或 rsync）。”

7.2 场景题：数据库CPU飙高、响应变慢，你怎么用Linux命令配合定位

这是一道跨界题，后端开发和DBA都可能碰到，考察的是综合排查能力。

建议按这个顺序回答：

# 1. top 看整体，确认是否是数据库进程在吃CPU top -c # 2. 进入MySQL/PostgreSQL，看当前有哪些慢查询、活跃事务 SHOW FULL PROCESSLIST; # 3. 用 vmstat 看系统层面是否有频繁的上下文切换、IO等待 vmstat 1 5 # 4. 用 iostat 确认磁盘IO是不是瓶颈 iostat -x 1 # 5. 如果是Java类应用，用 jstat 看GC情况，jstack 看线程 jstat -gcutil <PID> 1000

核心思路是“从现象到根因，层层排除”。CPU高的原因可能是：慢SQL导致单核CPU跑满、大量并发连接导致频繁上下文切换、索引失效全表扫描、IO等待导致CPU空闲但系统响应慢（这种情况CPU不高，是IO问题）。面试能把这些可能性和对应的排查命令说出来，就已经是标准的高分答案了。

7.3 场景题：多台服务器都需要执行同样的命令，怎么批量操作

这题在云原生面试里很常见，是考察“工程化能力”的题目。初级答案是“一台一台ssh”，中级的答案是“用pssh / pdsh”，高级的答案是“用Ansible写个playbook”。

推荐思路：先讲清楚批量操作的难点（主机清单管理、并发控制、错误处理、回滚），再给出Ansible的方案。

# Ansible 批量执行命令 ansible all -i hosts -m command -a "uptime" # 用playbook管理服务 ansible-playbook -i hosts deploy.yml

相比pssh，Ansible的优势是幂等性——同一个playbook跑很多次，结果一致，不会因为重复执行而出问题。这是生产环境里最重要的特质，也是面试官想考察的地方：你不是在解决“一次性的临时命令”，而是在建立“可持续、可维护的自动化运维体系”。

7.4 场景题：系统负载很高，但CPU和内存看起来都不高，可能是什么原因

这题非常考察分析能力。负载（load average）高但CPU不高，最常见的原因是不可中断睡眠（D state）的进程太多，通常意味着进程在等待IO——磁盘IO、网络IO、锁。也可能是内存里大量swap换页导致进程都卡在IO上。

排查步骤：

# 1. 查看哪些进程处于 D 状态 top -c # 看 STATE 列，D = uninterruptible sleep # 2. 看IO是否成为瓶颈 iostat -x 1 vmstat 1 5 # 3. 查看内核日志，可能伴随IO错误 dmesg -T | tail -50

如果vmstat的wa列很高，说明CPU大量时间在等IO；如果si/so不为0，说明正在大量swap。这两个指标都不高，但负载高，就要考虑是不是运行队列里堆积了大量短小的进程，瞬时负载被拉高了。这道题能答出“D state进程”这个概念，就已经远超只会看load average数字的候选人了。

面试其实分两个层次。第一个层次是背题目、背答案，这是很多面试题库给你的，能帮你兜底，但上限不高。第二个层次是真正理解“为什么”——为什么硬链接不能跨文件系统，为什么僵尸进程kill不掉，为什么OOM Killer会挑数据库进程下手。理解了背后的机制，面试官换任何角度追问，你都能接住。

我在实际面试中见过不少候选人，命令背得滚瓜烂熟，但一到“如果遇到xxx，你怎么排查”就卡壳。原因就是没有把知识串成体系。所以这篇文章虽然讲的是面试题，但我更建议你把它当成一份“Linux知识体系自查清单”——每道题不是用来背的，而是用来验证：我是不是真的理解我每天在用的这套系统？把这套逻辑想通了，面试只是顺带的事。