面过不少人也被面过不少次。Linux 面试题这块我个人感受是它最能拉开差距也最容易被准备跑偏。很多人一听到要考 Linux第一反应是找一份Linux常用命令大全从头背到尾参数背得滚瓜烂熟结果现场第一道题就卡住了。问题不在于背得不够多而在于没弄明白面试官为什么问这个问题。这篇东西不打算给你一份标准答案清单那种清单网上一抓一大把背完也未必管用。我想做的是把 Linux 面试题背后的出题逻辑、考察层次、以及真正能让你在面试现场加分的表达方式拆开讲清楚。内容覆盖命令类、系统与内核类、网络排障类、以及和后端框架、中间件交叉的那部分题目另外还会聊几道动手实操题——比如虚拟机装系统和整机备份这些在小公司面试里出现的频率比你想象的高。不适合谁看如果你已经做了五六年 SRE天天跟内核参数和性能火焰图打交道这里大部分内容对你偏基础。但如果你是准备跳槽的后端、测试、嵌入式方向的同学或者工作两三年但一直没系统梳理过 Linux 知识体系那这篇应该能帮你把零散的知识点串成一条线。1. Linux面试题到底在筛什么先摸清出题人的心思我参与过团队的技术面试也帮朋友做过好几次模拟面试一个很明显的规律Linux 题目很少是孤立存在的它更像是其他技术问题的前置校验。面试官问你怎么查看某个端口被谁占用他真正想确认的是——线上服务起不来的时候你能不能自己定位而不是第一时间在工作群里喊人。还有一点容易被忽略Linux 题是最难临时抱佛脚的一类题。框架题可以突击八股可以背但 Linux 题的答案往往藏在你过去踩过的坑里。你处理过磁盘写满的故障被问到时自然能说出du和df对不上的原因没处理过就只能干巴巴地报几个命令名面试官两句话就能问穿。1.1 面试官的三层筛选逻辑第一层是你能不能用。这一层的题目通常是命令级的查看磁盘占用、找大文件、看日志尾部、改文件权限、查进程。答不上来基本是一票否决因为这说明你日常几乎没有真正登录过服务器干活或者干活时全靠别人给的脚本。第二层是你懂不懂原理。这一层会往进程调度、内存回收、文件系统、内核模块这些方向走。比如fork 之后为什么通常要跟 exec、OOM Killer 是按什么规则挑受害者的、软链接和硬链接的本质区别。这一层区分的是会用工具的人和理解系统的人也是薪资谈高低的关键分水岭。第三层是你能不能扛事。这一层常常是开放题比如线上 CPU 突然打满你会怎么排查。它没有标准答案考的是你的排查路径是否有序、是否知道先止损再定位、是否清楚每一步能看到什么信息、什么情况下该换思路。这一层最能看出实战经验的厚度。注意很多人栽在第三层不是因为不会而是一上来就报命令没说清楚先看什么、为什么先看它、看到什么现象往哪走。面试官要的是决策链不是命令字典。1.2 不同岗位的考察权重完全不一样同一个问题问不同岗位期望的深度差得很远。你在投简历之前最好先判断自己会被哪一类面试官面到然后把复习时间按权重分配。岗位方向高频考点相对少考后端开发Java/Go进程与端口排查、日志分析、JVM 与系统资源关系、部署脚本、容器基础内核模块编译、发行版细节差异运维 / SRE性能分析、网络排障、权限与安全基线、备份恢复、批量运维业务框架内部机制测试 / 测开环境搭建、服务启停、日志定位、Shell 脚本、接口调试内核参数调优、大规模集群设计嵌入式 Linux交叉编译、根文件系统、设备树、驱动与内核裁剪集群运维、中间件调优前端 / 客户端基本命令、构建产物部署、容器与镜像概念内核机制、系统调用细节我见过不少候选人把时间全花在背内核参数上结果面试时被问到服务起不来怎么查反而答得磕磕巴巴。对大部分业务开发岗来说排障能力的分值远高于内核原理。反过来如果你投的是偏向系统层的岗位只会敲命令而不理解load average包含不可中断睡眠状态这种细节也很难拿到高分。2. 命令类高频题别背参数要懂场景命令题是 Linux 面试的基本盘但它的出题方式早就过了ls 是干什么的这个阶段。现在更常见的形式是给你一个具体场景让你现场写出命令统计日志里访问量前 10 的 IP、找出七天前修改过且大于 100M 的文件、把一批文件的权限统一改成 644。这类题有个共同特点——考的不是单个命令而是组合起来解决具体问题的能力。2.1 找文件、找内容、切字段真正的三件套find、grep、awk加上sed是命令题里出现频率最高的组合。它们的分工很清晰find负责按属性筛文件grep负责按内容筛行awk负责按列取字段做统计。理解了这个分工写命令时就不会乱。找出/var/log下七天内有修改、体积超过 100M 的文件find /var/log -type f -mtime -7 -size 100M -exec ls -lh {} \;这里-mtime -7表示修改时间在 7 天以内负号是关键很多人会写成-mtime 7然后结果不符合预期。-size 100M的大写 M 是按 1024 进制算小写m在部分场景下会被理解成兆字节以外的单位写大写的更稳妥。-exec ... {} \;里那个分号一定要转义用结尾则会把结果批量传给命令效率更高。在代码目录里递归搜关键字只搜特定后缀grep -rn TODO ./src --include*.java --exclude-dirtarget经典统计题——访问日志里请求量最高的 10 个 IPawk {print $1} access.log | sort | uniq -c | sort -rn | head -n 10这条命令我建议你拆开理解每一步做了什么awk取第一列sort排序让相同 IP 相邻uniq -c才能正确计数再按次数倒序排。少了第一次sortuniq的结果就是错的。面试官如果追问如果日志里有几十 G 怎么办你可以答用zcat/grep分流处理或者用awk维护一个哈希表一次遍历完成避免多次排序带来的 IO 开销。2.2 用户、权限和提权细节决定成败新建用户是搜索量极高的一个点但它的坑比想象中多。useradd和adduser是两个不同的东西前者是底层命令创建时不会自动建家目录、不会提示设密码后者在 Debian/Ubuntu 系里是一个友好的封装脚本交互式地帮你把家目录、密码、基本信息一次搞定。CentOS 上默认没有adduser的交互版本这个差异很多人第一次跨发行版操作时都会愣一下。useradd -m -s /bin/bash -G docker,dev deploy passwd deploy-m建家目录-s指定登录 shell-G附加到多个用户组。这里有个细节-G是附加组-g是主组两个参数大小写不同、含义完全不同写错了会让用户的主组变成别的组后面文件权限一塌糊涂。删除用户时用userdel -r会连同家目录和邮件目录一起删掉不加-r只删账号残留的家目录会带着原 UID 继续存在之后新建用户如果恰好分配到同一个 UID就会出现新用户莫名拥有旧文件的诡异现象。权限部分的核心是理解数字的含义r4、w2、x1三位分别对应属主、属组、其他人。755是目录和可执行文件的常规值644是普通文件。面试里常被追问的是umask默认022意味着新建文件自动去掉组和其他人的写权限所以默认文件权限是644、目录是755。这个推导过程要能说清楚别只会背数字。再往上一层是 SUID、SGID、Sticky Bit。passwd这个命令为什么普通用户也能改自己的密码因为它带 SUID 位执行时临时以文件属主的身份运行。目录上的 Sticky Bit比如/tmp保证用户只能删自己创建的文件。这几个点答出来面试官对你的评价会直接上一个台阶。2.3 压缩解压与中文乱码一个非常真实的坑tar的参数组合几乎每场面试都会问到最少记住三条tar -zcvf backup.tar.gz /data/app # 打包c 是 create tar -zxvf backup.tar.gz -C /data/restore # 解包-C 指定目标目录 tar -zcvf app.tar.gz --exclude*.log app # 打包时排除日志-C这个参数很关键。默认解包到当前目录如果你在/下随手解一个包含绝对路径结构的大包可能直接把系统文件覆盖掉。我见过一次事故运维同事在生产机上解包时没加-C把一套旧配置覆盖到了/etc后面花了两个小时才恢复。接下来是Linux 解压文件乱码这个问题它看起来不起眼实际非常高频。现象是在 Windows 上用压缩软件打的包放到 Linux 里unzip后中文文件名全变成问号或者一串看不懂的字符。根本原因是编码不匹配。Windows 下中文压缩包里的文件名通常是 GBK代码页 936编码而 Linux 默认按 UTF-8 解释这些字节解出来自然是乱的。反过来Linux 打的包含中文文件名的包拿到 Windows 上用默认设置解也会乱。处理办法分几种情况unzip的某些版本支持-O CP936参数指定源编码后能正确还原文件名unzip -O CP936 xxx.zip。如果系统自带的unzip不支持-O可以装p7zip用7z x -mcp936 xxx.zip指定代码页。已经解出来乱码了也别急着删用convmv批量改名convmv -f GBK -t UTF-8 -r --notest ./dir。tar包更麻烦因为 gzip 格式本身不保存编码信息只能靠打包时约定好环境或者在解包后手动改名。实操心得团队内部约定用tar.gz而不是zip传代码包能在源头上避开大部分中文文件名问题。如果一定要用 zip打包工具里手动把文件名编码设成 UTF-8。3. 系统与内核类问题从能用走到懂原理这一层是分水岭。会敲命令的人一抓一大把但能把进程状态、内存回收、内核模块讲明白的人明显少很多。好消息是面试官问原理时通常不会要求你背源码级细节他要的是你能用一套自洽的模型解释现象。所以复习重点应该放在因果链上而不是名词解释。3.1 进程、线程与那五个状态ps和top看到的进程状态每个字母都有明确含义R是正在运行或在就绪队列里、S是可中断睡眠最常见等事件、D是不可中断睡眠通常在等 IO、Z是僵尸、T是停止或被调试跟踪。D状态值得单独说。处于D状态的进程不响应信号你kill -9也没用只能等 IO 返回或者重启机器。这就是为什么有些时候进程杀不掉不是权限问题而是它卡在驱动或存储的 IO 上。僵尸进程的本质是子进程已经结束但父进程还没来得及调用wait回收它的退出状态于是这个进程号一直被占着。处理办法不是杀僵尸本身它已经死了而是找到它的父进程看父进程为什么不回收。如果父进程是initPID 1系统会自动清理。再往深一点面试官可能问一个进程最多能起多少线程。这取决于几个限制ulimit -u的进程数上限、/proc/sys/kernel/threads-max、以及最容易被忽略的栈空间——每个线程默认要占 8M 虚拟内存通过ulimit -s控制在 32 位系统上这个限制会非常明显。这也解释了一个常见困惑明明是 64 位机器为什么还是报unable to create new native thread。答案往往不是内存不够而是线程数或虚拟内存地址空间的问题。3.2 内存怎么看才不算外行free -h的输出里真正该看的是available这一列而不是free。free显示的是完全没被使用的内存而 Linux 会把空闲内存拿去做页缓存buff/cache只要应用需要这部分随时可以释放。所以看到free很小不要慌看到available很小才是真的紧张。load average也是面试常客。很多人只知道它表示平均负载但答不出它包含不可中断睡眠的进程。这意味着如果磁盘 IO 很慢一堆进程卡在D状态CPU 明明不忙load也会很高。所以判断负载是否异常必须结合 CPU 核数看4 核机器上load到 4 大致是满负荷到 8 就说明有大量任务在排队。判断 CPU 是否真的忙用vmstat 1看r列和cs列。r是运行队列长度持续大于核数说明 CPU 竞争激烈cs是上下文切换次数短时间飙到几万次通常意味着锁竞争或者频繁的系统调用。这两个指标比top里的 CPU 百分比更能说明问题。内存回收这块要知道 OOM Killer 的存在。当系统实在腾不出内存时内核会挑一个进程杀掉挑选依据是oom_score这个分数和进程占用的内存量、运行时长、是否特权进程有关。/proc/pid/oom_score_adj可以手动调取值范围 -1000 到 1000值越低越不容易被杀。生产上通常把核心服务调成负值把非关键进程调成正值。3.3 内核模块与读写拦截一个偏进阶的方向有些偏底层或者安全方向的岗位会问到内核模块相关的问题比如怎么在不改应用代码的前提下拦截某个文件的读写。这个问题的核心机制是file_operations结构体。Linux 里每个打开的文件都对应一个struct file它内部有一个指向file_operations的结构体指针这个结构体里存着read、write、open、release等一整套函数指针。谁来处理这个文件的读写就由这些指针指向谁决定。所以只要把目标文件的file_operations里的read/write指针替换成自己的函数就能在读写路径上插入逻辑——这就是动态加载 file_operations 拦截 read write的基本思路也是很多透明加解密方案的实现原理之一。static struct file_operations *orig_fops; static ssize_t (*orig_read)(struct file *, char __user *, size_t, loff_t *); static ssize_t hook_read(struct file *filp, char __user *buf, size_t len, loff_t *off) { ssize_t ret orig_read(filp, buf, len, off); if (ret 0) { /* 在此对 buf 中的数据进行处理 */ } return ret; }理论上就这么几十行但实际做起来会遇到一串问题怎么拿到目标file_operations的地址早期用kallsyms_lookup_name后来这个符号导出的限制变严了更多改用 kprobe 或遍历sb-s_files、inode-i_fop的方式、内核版本之间结构体成员位置变化、多核并发下的读写竞争、以及替换函数指针时的写保护需要临时关掉 CR0 的 WP 位。我得强调一句这条路只在自有实验环境里做学习和研究是合适的。生产环境要考虑的东西完全不一样——稳定性、升级兼容、以及与现有安全机制的冲突。真要做文件级透明加解密成熟方案更多是走文件系统层比如 fscrypt、eCryptfs或者内核提供的钩子机制LSM、fanotify、eBPF而不是自己 hook 函数指针。面试时如果能说出我知道底层怎么实现但生产上我会优先选成熟框架这个回答的质量远高于只讲实现。4. 网络与排障面试现场最容易被追问的部分网络相关的问题有个特点——面试官特别爱往下追问。你说用 ping 测连通性他会问ping 不通就一定是网络问题吗你说改/etc/resolv.conf他会问改了以后为什么过一会儿又变回去了。这类问题没有边界答得越深越好。4.1 DNS 配置为什么总是改了没用这是搜索量极高的一类问题。很多人遇到域名解析异常第一反应是打开/etc/resolv.conf加一行nameserver重启服务后发现配置又被覆盖了。原因在于现在大部分发行版上这个文件已经变成了一个被动态生成的文件真正的配置来源可能是systemd-resolved、NetworkManager或者resolvconf这套框架。正确的处理路径是先判断谁在管这个文件ls -l /etc/resolv.conf # 看看是不是软链接 systemctl status systemd-resolved resolvectl status # systemd-resolved 体系下看真实配置 nmcli dev show | grep DNS # NetworkManager 体系下看 DNS如果/etc/resolv.conf指向/run/systemd/resolve/stub-resolv.conf说明是 systemd-resolved 在做解析你要改的是/etc/systemd/resolved.conf或者对应网卡的配置改完systemctl restart systemd-resolved才会生效。直接改软链接目标文件属于治标不治本。另一个高频坑是nsswitch.conf。它决定了系统按什么顺序做名称解析——是先查/etc/hosts还是先查 DNS这个顺序写在hosts:那一行里。理解这一点的实际价值在于ping和getent hosts的结果可能不一样。getent走的是完整的 nsswitch 流程能反映程序真实的解析路径而nslookup、dig是直接向 DNS 服务器发查询绕过了/etc/hosts。所以排查程序解析不对的问题时getent hosts 域名才是更准的工具。4.2 端口、连接与抓包某端口被谁占用是面试白给题但答法有讲究ss -lntp | grep 8080 # 看监听中的 TCP 端口及对应进程 lsof -i :8080 # 更直观需要 lsof 已安装ss正在逐步取代netstat因为它在连接数很多时性能更好。这两个命令记一个就够但要知道-l是只看监听、-n是不做域名解析避免 DNS 卡住导致命令变慢、-p是显示进程。少了-n在 DNS 有问题时这个命令会卡很久这个细节说出来很加分。TIME_WAIT过多也是经典题。它本身不是故障而是 TCP 主动关闭方必须经历的状态目的是保证最后一个 ACK 能到达、以及让旧连接的数据包在网络中消散。但如果服务器作为主动关闭方承受高并发短连接TIME_WAIT会堆积并占用端口资源。优化方向是让客户端主动关闭、开启tcp_tw_reuse、或者调整somaxconn与连接池策略。注意不要用已经被移除的老参数tcp_tw_recycle那个东西在 NAT 环境下会引发连接异常。4.3 df 和 du 结果对不上怎么办这是一个能瞬间分辨出是否真上过生产的问题。现象是df -h显示磁盘用了 90%但du -sh /*加起来只有 50%。原因是文件被删除了但还有进程持有这个文件的句柄。在 Linux 里只要还有进程打开着某个文件即使目录项已经删除文件的存储空间也不会释放。日志文件被rm掉但服务没重启就是这个场景。定位方式lsof L1 # 列出所有 link count 为 0 的已删除文件 lsof | grep deleted找到之后要么重启持有句柄的进程要么用 /proc/pid/fd/fd的方式清空。根治办法是让应用日志走 logrotate而不是手动rm。这个题答完整面试官基本能确认你处理过真实故障而不是只看过文档。5. 服务部署与中间件交叉题后端岗绕不开的部分如果你是投后端开发Linux 题的最后一层往往会和框架、中间件混着问。面试官想知道的是你能不能把业务代码的运行表现和系统层现象对应起来。这个能力在排查线上问题时非常值钱。5.1 JVM、Redis、Kafka 和系统层的那些纠葛Java 应用最常见的坑是被 OOM Killer 杀掉了但 JVM 日志里什么都没打。原因通常是堆外内存JVM 的-Xmx只控制堆加上元空间、线程栈、直接内存NIO 用的 DirectByteBuffer、JIT 编译缓存一个配置-Xmx4g的进程实际 RSS 可能到 7G 以上。容器化部署时如果没设置MaxRAMPercentage或者没识别到容器限制JVM 会按物理机内存来算堆大小然后被 cgroup 限制卡死。这个问题现在基本是 Java 面试的常客能从系统层解释清楚的人不多。Too many open files 也很常见。它对应ulimit -n文件描述符上限和fs.file-max系统级上限。需要知道的是ulimit -n在 systemd 管理的服务里改/etc/security/limits.conf未必生效得在 service 文件里写LimitNOFILE65535。这个差异我踩过一次改了 limits.conf 重启服务完全没用最后是在 unit 文件里加上才解决。Redis 有几个明确的系统层依赖vm.overcommit_memory建议设为 1避免后台 fork 做持久化时因为内存不足失败透明大页THP建议关闭否则 fork 和后端保存时的延迟抖动会很明显net.core.somaxconn会影响高并发下的连接排队。Kafka 则是重文件句柄的组合分区数乘以副本数乘以段文件数很容易把默认的 1024 句柄数打爆。5.2 把服务交给 systemd 管写一份能用的 unit 文件很多人的部署方式还是nohup java -jar xxx.jar 这种方式的问题是一重启机器服务就没了也没法自动拉起。正经做法是写一个 systemd unit[Unit] DescriptionOrder Service Afternetwork.target [Service] Typesimple Userappuser WorkingDirectory/opt/order EnvironmentFile/opt/order/env.conf ExecStart/usr/bin/java -Xmx2g -jar order.jar Restartalways RestartSec5 LimitNOFILE65535 StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target几个容易写错的点Afternetwork.target只保证网络栈就绪不代表外部依赖数据库、注册中心可用需要应用自己有重试逻辑Restartalways会让服务在异常退出后自动拉起但如果启动就崩会陷入无限重启可以考虑加StartLimitBurst限制日志走journal后用journalctl -u order -f看实时日志journalctl -u order --since 10 min ago看历史比翻文件方便。另外EnvironmentFile里的变量不要在文件里加exportsystemd 不认 shell 语法。这个坑说大不大但能让服务起不来我见过有人排查了半小时才发现是这里的问题。6. 动手实操题虚拟机装系统和整机备份这类题在小公司和偏运维的岗位里出现得比想象中多因为它最能验证你到底是真动过手还是只看过文章。典型形式是让你现场描述怎么在一台空机器上装好 Linux 并部署一个服务或者问你怎么给一台已经跑了很久的服务器做整机备份。6.1 选镜像和装系统的几个关键决策镜像选择上官网通常提供几种类型完整版 DVD 镜像自带图形界面和常用软件包体积大minimal 或者 netinst 版本只有基础系统安装时需要联网拉包体积小但依赖网络cloud image 是为了云环境预制的默认通过 cloud-init 注入配置不带你熟悉的安装界面。做实验用 minimal 版最合适能顺便熟悉一下手工装包的过程。架构也要确认x86_64、aarch64是不同的买云服务器的时候很多人只看配置不看架构结果编译好的二进制放上去报cannot execute binary file。用uname -m查看当前架构最稳。安装过程中两个容易忽略的点一是不要给swap分太大现在内存普遍够用swap更多是兜底分到内存的 1 到 2 倍是老经验实际上 2G 到 4G 就够二是分区方案如果以后要在线扩容一开始就用 LVM后面加磁盘可以直接pvcreatevgextendlvextend在线扩不用停机重装。网络模式上NAT 方式虚拟机共享宿主 IP能上网但外部访问不到桥接方式虚拟机会拿到局域网 IP可以被其他机器直接访问做集群实验时更接近真实环境。6.2 整机备份别只会 tar 一下给系统做整机备份方案选择要看你想要什么。只是想备份数据文件rsync或者tar就够了想做到裸机恢复——也就是磁盘坏了换一块新盘能直接还原成原样——那就要考虑块级镜像。常见的几类做法方案适用场景注意点tar打包关键目录只备份数据和配置不能裸机恢复要重装系统rsync增量同步定期同步到备份服务器要处理权限、属主、ACL、SELinux 上下文dd全盘镜像小磁盘、实验环境会拷贝空块镜像体积等于磁盘大小只能在同容量以上磁盘恢复LVM 快照有 LVM 的服务器做在线备份快照空间要预留写入量大时会溢出失效开源整机镜像工具需要跨机器、跨磁盘容量恢复通常基于分区表加文件系统层复制只复制有效数据最后一种就是很多运维会用的方案它的优势是不依赖磁盘容量一致能做压缩、能校验、能增量。做个启动盘从盘启动后按向导操作即可。我个人的习惯是备份任务不验证等于没做每次备份完都拿一台测试机做一次恢复演练否则真出事的时候才发现镜像有问题那才是灾难。7. 面试现场的表达与避坑前面讲的都是知识这一节讲的是怎么把知识卖出去。同样的水平表达方式不同面试结果可能差一个档次。7.1 一个能套用大部分排障题的答题框架我总结的框架是结论—路径—判据—兜底四步。拿CPU 打满怎么排查举例先说结论方向先确认是用户态还是内核态消耗再定位到具体进程和线程最后看是计算密集还是锁竞争。然后说路径top看整体使用率和us/sy比例记下高占用 PIDtop -Hp pid看线程级消耗线程 ID 转十六进制后去 jstack 里找对应栈。再说判据us高通常是业务代码死循环或者复杂计算sy高往往和频繁系统调用、上下文切换有关wa高则是 IO 瓶颈不在 CPU 本身。最后说兜底如果定位不到用perf top看热点函数或者确认是否被其他进程干扰。这套说法的价值不在于内容多高深而在于它展示了你有顺序、有判据、有退路。面试官会觉得把你放到线上是安全的。7.2 几个我见过最多的减分项第一是不懂装懂。被问到不会的东西硬编一个答案面试官稍微一追就露馅。更好的处理是坦诚说这块我接触不多但我理解它大概和某某机制相关如果是排查问题我会先从这个方向入手。这反而展示了你的推理能力。第二是只报命令不说判据。回答怎么查磁盘满时说df -h就完事了面试官会追一句然后呢。完整回答应该说df -h看哪个分区满再用du -sh逐层定位如果两者对不上就用lsof L1查已删除但被占用的文件。有判据有分支才是完整答案。第三是忽略发行版差异。同一个操作在 CentOS 和 Ubuntu 上路径、包管理器、服务管理方式都可能不同。回答时主动加一句这取决于发行版CentOS 系是这样Debian 系是那样会让面试官觉得你踩过不同环境的坑。第四是完全不提权限。排查问题时动不动就sudo、直接改系统文件是很危险的信号。表现出我会先确认当前身份、确认影响范围再动手的意识比多背十条命令更值钱。提示面试快结束时如果对方问你还有什么想问的可以问问团队目前的服务规模、有没有自动化运维体系、线上故障的复盘机制。这几个问题既显得你关心真实工作内容也能帮你判断这家公司值不值得去。我个人在实际操作中的体会是Linux 这块的面试准备最高效的方式不是刷题库而是给自己找一台机器把常见的故障场景亲手复现一遍故意把磁盘写满、故意让一个进程变成僵尸、故意把resolv.conf改错、故意让服务占满文件句柄。每一个坑你亲手踩过一次形成的记忆和看文章完全不是一个量级。面试时脱口而出的那些细节几乎都来自这些踩坑现场而不是背下来的条目。如果时间只够做一件事我会建议你装一台虚拟机从最小化镜像开始装手动分区、手动配网络、手动装 JDK 和数据库、手动写一个 systemd 服务。这一套做下来上面七成的问题你都能用自己的话讲清楚了。