Linux实战100例：从命令到排错的系统化训练

简介：这是一套面向 Linux 学习者与开发者的实战代码合集，精选 100 个经典且最具代表性的代码实例，覆盖网络调用命令、Apache 服务器参数配置、Linux 错误代码详解等高频应用场景，并针对系统使用过程中常见的诸多错误给出排查思路与解决方法，适合需要边敲边学、快速积累排错经验的初中级读者。资源包为 RAR 压缩格式，解开后共 204 个文件，总大小约 40.19MB。其中 195 个网页格式文档构成主体，这些网页将每个示例的代码、注释、运行效果与功能调用过程说明整合在一起，在浏览器中打开即可逐条学习，无需单独搭建复杂环境；另配 PDF、DOC、EXE 等多种电子文档作为参考手册和延伸阅读，少量素材以压缩包形式存放。目前已有 2180 人学习下载，内容既包含 100 个实战示例，又附带 Apache 配置要点、错误代码对照与常见问题排错参考，读者可从中获得系统化的功能调用流程说明、参数设置细则及错误应对清单，既能当作日常开发速查手册，也可用于考前复习或项目实战前的集中强化。

1. Linux 实战 100 例不是命令大全：而是一套有顺序的训练题

「Linux 实战 100 例」是那种看着简单、真练起来能让人冒冷汗的题库。它不按字母序罗列参数，而是按场景抛任务：找出 7 天内被改过又超过 100MB 的日志、给新用户限死权限、把 Nginx 装起来并开机自启、挂载一台 NAS 存储还要保证重启不翻车。每道题都对应一个真实运维现场，刷完一遍，你会发现原来抄命令的手感，变成了判断问题出在哪一层的能力。适合转行做运维的新人、准备 Linux 面试的求职者，以及写了两年脚本但系统管理还是很散的开发者。我拆这套资源时，把它按训练顺序重排了位置，下面按我的做法讲。

2. 把 100 例拆成五个训练段：命令、脚本、系统、网络、排错

拿到 100 例先别急着从第 1 题刷到第 100 题。我第一次刷就是这么干的，刷到 40 题回头看，前面的命令已经忘了个干净。后来我把它按场景切成五段：高频命令、Shell 脚本、系统与权限、网络与服务、故障排查。这样每一段解决一类问题，命令之间天然有关联，记忆是挂在真实场景上的，不是孤零零的字符串。

2.1 为什么按场景练而不是按命令背

背命令的问题在于遗忘曲线非常陡。今天记住了awk '{print $1}'，下周遇到「统计日志里每种状态码出现的次数」还是会卡住，因为你不知道 awk 要配合 sort、uniq 用。场景化训练的核心是让命令成组出现：一个任务至少要组合两三条命令，每次重复都是把整条链路走一遍。100 例里的题大多也是复合任务，拆开看就是一个一个小场景。

这五个段的切法有讲究。高频命令段负责文件查找、文本处理和压缩解压；脚本段负责把命令串成自动化流程；系统与权限段负责用户、进程和 systemd；网络与服务段负责端口、DNS、Nginx 和网络存储；故障排查段是把前四段的坑集中踩一遍。这样切完，你练每道题之前都知道自己在补哪块短板。

2.2 高频命令段：先把 find、grep、awk 练成条件反射

第一道典型的题是「找出 /var/log 下 7 天内改动过、大于 100MB 的日志文件」。用 find 一条命令就能做：

# 找出 7 天内改动、超过 100MB 的普通日志文件，并显示大小 find /var/log -type f -mtime -7 -size +100M -exec ls -lh {} \;

-type f限定只匹配普通文件，避免目录和 socket 混进来；-mtime -7表示 7 天内修改过，注意是修改时间而不是访问时间；-size +100M匹配大于 100MB 的文件；-exec ls -lh {} \;对每个匹配结果执行 ls，{}是文件名的占位符，\;是 exec 参数结束的标志，少了会直接报语法错误。

接着是「列出当前所有监听端口」这类端口排查题。我一般顺手用 ss 加管道：

# 查看本机所有正在监听的 TCP 端口，去掉重复项 ss -tlnp | awk 'NR>1 {print $4}' | cut -d: -f2 | sort -u

ss取代了老的 netstat。-t只看 TCP，-l只看监听中的连接，-n用数字端口不做反向解析，-p显示进程名，这也是排查进程间通信最常用的参数组合。管道里 awk 的NR>1是跳过第一行表头，取第 4 列，这列内容是「本地地址:端口」；cut 用冒号做分隔取第二段，剥离出纯端口；最后 sort -u 排序去重。注意-p需要 root 权限，普通用户看不到进程名。

文本处理题绕不开 grep 和 sed。查配置最常用的组合是递归加文件过滤：

# 在 /etc/nginx 下递归查找所有 .conf 文件里的 listen 行 grep -rn "listen" /etc/nginx/ --include="*.conf"

-r递归目录，-n显示行号，--include只扫描匹配后缀的文件，能排除一堆无关的默认配置。这类命令的共通点是参数都要能脱口而出，不是会敲就行。

2.3 脚本段：for、while、case 三个结构覆盖日常 80%

命令练熟之后，就该练把命令装进脚本。100 例的脚本题其实不考算法，考的是三个循环分支结构和退出码的处理。最常见的监控脚本是这样：

# 检查一组服务是否在线，停掉的服务写入 /tmp/check.log for svc in nginx php-fpm mysqld; do systemctl is-active --quiet "$svc" || echo "$svc is down" >> /tmp/check.log done

systemctl is-active检测服务是否激活，--quiet让它不输出内容、只返回退出码；退出码为 0 表示在线，非 0 会被||捕获，然后记录日志。这个写法比systemctl status加 grep 干净得多，也更快。注意变量一定要加双引号，"$svc"不带引号时，如果服务名含空格会被拆成多个参数。

while 循环常用来按行读文件，比如批量 ping 一批主机：

# 从 hosts.txt 逐行读取主机名，逐个 ping 并判断在线状态 while read -r host; do ping -c 1 -W 1 "$host" >/dev/null 2>&1 && echo "$host ok" || echo "$host down" done < hosts.txt

read -r里的-r关闭反斜杠转义，防止主机名里的特殊字符被吃掉；-c 1只发一个包，-W 1表示超时 1 秒；重定向到/dev/null是为了不让 ping 的输出刷屏。&&和||在这里串起来：成功打印 ok，失败打印 down。输出重定向成列表，再配合 awk 统计，就是一套小型的存活检测脚本。

case 结构适合写有参数的管理脚本，比如 nginx 的后台管理：

# 简易服务管理脚本：start|stop|restart 三种动作 case "$1" in start) systemctl start nginx ;; stop) systemctl stop nginx ;; restart) systemctl restart nginx ;; *) echo "usage: $0 {start|stop|restart}" ;; esac

$1是脚本第一个参数，start)到;;之间是这个分支的命令，最后的*匹配所有没命中的输入，用来输出用法提示。这类脚本是 100 例里最常考的模板，背住结构，遇到「写一个备份脚本」「写一个健康检查脚本」都能直接套。

2.4 压缩与同步：tar、7z、rsync 的基本盘

系统备份恢复是面试和运维都绕不开的题，压缩和同步是它的两块基础。打包用 tar 是最稳的组合：

# 把 /etc 目录打包压缩，文件名带当天日期 tar czf /backup/etc_$(date +%F).tar.gz /etc

-c创建归档，-z用 gzip 压缩，-f指定输出文件；$(date +%F)会展开成类似 2025-06-10 的日期，这样备份文件不会互相覆盖。如果想保留权限和时间戳，给 tar 加-p。恢复时的命令是tar xzf etc_xxxxxxxx.tar.gz -C /opt/restore，-C指定解压目录。

遇到 7z 压缩包，Linux 下常见的是7z x：

# 解压 7z 文件到指定目录，保留原有目录结构 7z x /home/user/source.7z -o/tmp/7z_extract

x表示解压并保留路径，-o指定输出目录，注意-o和路径之间没有空格，这是 7z 一个容易踩的小坑。生产环境批量同步文件我更习惯 rsync：

# 同步本地两个目录，保持属主和时间戳，并保证目标与源一致 rsync -av --delete /data/ /backup/data/

-a归档模式，合并了递归、保持权限、时间戳等一堆选项；-v输出进度；--delete会把目标端多余的文件删掉，让两边完全一致。这个参数是双刃剑：目标路径写错，比如漏掉末尾的斜杠，可能会导致文件放到错误层级；配了--delete再写错，就是批量删文件的事故现场。

注意：rsync 带--delete之前，先执行rsync -avn干跑一遍，确认目标路径没问题再真正同步。

3. 用户与权限：新建用户、sudo 提权与最小授权

用户是 Linux 系统管理的分水岭。100 例里只要涉及多用户、上线部署、安全问题，基本都会落到这一章。会建用户只是开始，真正的差距在于能不能控住权限：给对的人、给对的命令、不留后门。

3.1 新建用户完整动作：useradd、chpasswd 与验证

很多新手用 adduser 建用户，在 CentOS/RHEL 系上 adduser 只是个软链接，行为跟 useradd 一致；在 Debian/Ubuntu 上 adduser 是交互式封装，会一步步问你密码和全名。脚本化场景下我一般用 useradd，参数固定，不会被交互卡住：

# 创建用户 dev，建家目录、指定 bash、加入 wheel 组 sudo useradd -m -d /home/dev -s /bin/bash -G wheel dev

-m表示创建家目录，漏掉它用户会有一个不存在的 $HOME，很多软件起不来；-d指定家目录位置，通常配合-m用，防止默认路径不符合规范；-s指定登录 shell，不设的话可能被 lock 掉；-G wheel把用户附加到 wheel 组，这是 CentOS/RHEL 系 sudo 授权组的名字，Debian/Ubuntu 系对应的是 sudo 组。

用户建好后设置密码，用 chpasswd 比 passwd 更适合脚本：

# 通过标准输入设置密码，格式是 用户名:密码 echo 'dev:ChangeMe_2025!' | sudo chpasswd

chpasswd 从 stdin 读取「用户名:密码」的格式，批量设置时是循环里最顺手的一行。密码里出现冒号会被截断，所以密码别用冒号。设完验证一下：

id dev

输出里能看到 uid、gid 和 groups。uid 1000 以下通常被系统账户占用，普通用户从 1000 开始，这个约定在 100 例里出现频率很高。

给已有用户追加组，usermod 是标准做法：

# 附加 docker 组，保留用户原有组 sudo usermod -aG docker dev

这里的-a是 append，必须配合-G用。只写-G docker会把用户的附加组整个替换成 docker，原来在 wheel 组里的权限全部消失，这是个非常隐蔽的事故：用户明明没动，sudo 突然用不了了。我见过不止一个人在这里翻车。

3.2 sudo 最小授权：别一个 ALL 打天下

个人虚拟机里把用户加进 wheel 组图个省事，生产环境必须走最小授权。100 例里有一类题就是「给应用账号分配指定命令权限」，标准操作是单独建一个 sudoers 文件，而不是改主配置：

# 用 visudo 编辑独立授权文件，语法错误会被拦下来 sudo visudo -f /etc/sudoers.d/deploy

文件里写一行：

deploy ALL=(ALL) /bin/systemctl restart nginx, /bin/systemctl reload nginx

这行的语法是「用户 主机=(身份) 命令白名单」。ALL第一部分是主机名匹配，单机就用 ALL；括号里的 ALL 表示可以切换到任意身份执行；命令必须是绝对路径，多个命令用逗号分隔。这样 deploy 用户只能重启和重载 nginx，改配置、看别的服务、执行 shell 都不被允许，这就是最小授权。

验证授权是否生效，别靠猜，用 sudo 自带的列权限命令：

# 列出指定用户能执行的命令 sudo -l -U deploy

-l列出指定用户能执行的命令，-U指定用户名。输出会明确显示可执行的白名单，如果没有预期中的命令，回去检查 sudoers 文件的路径和语法。

注意：/etc/sudoers.d下的文件权限必须是 0440，普通用户可写会导致 sudo 直接拒绝加载整个配置。

白名单里带参数的命令要格外小心。允许/bin/rm *和允许/bin/rm区别不大，因为 rm 的-rf参数照样能传；允许 vi 意味着用户可以借助!bash逃逸成 shell。所以白名单越短越好，能用 systemd 统一管理的服务，就只放systemctl的指定动作，不要放通用编辑器。

3.3 批量建号与用户回收：脚本化与安全边界

批量创建用户是脚本段和权限段交叉的题。网上很多教程直接给初始密码写死在脚本里，风险很大。我一般配合 openssl 生成随机密码：

# 批量创建 3 个用户，初始密码随机生成，成功后才设置 for user in ops-1 ops-2 ops-3; do useradd -m -s /bin/bash "$user" && echo "$user:$(openssl rand -base64 12)" | chpasswd done

&&确保 useradd 成功才设置密码，用户已存在时 useradd 返回非 0，不会覆盖旧密码；openssl rand -base64 12生成 16 个随机字符，密码强度比写死的强得多。生成的密码需要记录到临时文件里再发给使用者，不要直接在循环里 echo 出来，会留一大堆历史记录。

查看系统里已有哪些普通用户，用 awk 翻 passwd 文件比记一堆命令快：

# 输出 UID 大于等于 1000 的用户名 awk -F: '$3>=1000 {print $1}' /etc/passwd

-F:指定冒号分隔，$3是 UID 列。这个技巧在清点账号、排查「哪个用户占用了 uid」时很好用。

回收用户的坑主要在 userdel：

# 删除用户并清理家目录和邮件池 sudo userdel -r olduser

-r会连家目录、邮件池一起删。如果这个用户的数据还没备份，这就是不可逆操作。我自己的习惯是回收前先tar czf打包家目录到归档目录，再从用户列表移除，确认一个月没人找才真正删除。100 例里关于用户删除的题，考察点从来不是命令本身，而是删除前的判断和备份意识。

4. 网络与服务：Nginx 部署、NAS 挂载与三层排查

网络段是 100 例里「对着答案看都懂，关掉文档就翻车」的重灾区。原因很简单：网络问题层层嵌套，现象暴露在应用层，根源可能在网卡、防火墙或 DNS，少看一层就多折腾半小时。这一章的题我建议按部署和排查两条线走。

4.1 从零部署 Nginx：装包、自启、防火墙

部署 Nginx 是最高频的题。在 CentOS/Rocky 上直接dnf install nginx大概率会提示找不到包，主流做法是先启用 EPEL 扩展源：

# 安装 EPEL 扩展源，再安装 nginx sudo dnf install -y epel-release sudo dnf install -y nginx

-y表示自动确认安装。如果不想依赖 EPEL，可以走官网源或源码编译，但源码编译要先装 gcc、make 等工具链，维护成本高，日常部署我基本都是 dnf 装官方包。Debian/Ubuntu 系则直接用apt install nginx，源里自带，没有这步。

装完启动并设开机自启：

# 启动 nginx 并加入开机自启，一条命令完成 sudo systemctl enable --now nginx

enable --now是 enable 和 start 的组合，比分开敲少一次状态不一致的机会。验证是否真的起来了，先看本机：

# 只拿响应头，3 秒超时，确认 HTTP 服务有响应 curl -I --connect-timeout 3 http://127.0.0.1 systemctl status nginx --no-pager

curl -I只取响应头不下载页面，--connect-timeout 3防止 connect 阶段挂死；--no-pager让 systemctl 不要进分页器，直接把状态打出来，脚本里也常用。本机通不代表外部能访问，防火墙是下一道门槛：

# 放行 http 服务并重载防火墙规则 sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --reload sudo firewall-cmd --list-services

--permanent把规则写进持久化配置，不加它 reload 后规则就没了；--reload重新加载；--list-services核对当前放行的服务清单。经典翻车现场是：本机 curl 通，另一台机器访问超时，最后发现 http 服务在 firewalld 里没放行，而旧教程还在让你关防火墙。放行单个服务而不是整机关闭，是生产环境的基本要求。

4.2 挂载 NAS 存储：mount 与 fstab 的坑

NAS 挂载题考察的是网络文件系统的挂载和持久化。以 NFS 为例，先装客户端工具再挂载：

# 安装 NFS 客户端，创建挂载点，挂载远程目录 sudo dnf install -y nfs-utils sudo mkdir -p /mnt/nas sudo mount -t nfs4 192.168.10.10:/data /mnt/nas

-t nfs4指定 NFS 版本，老环境可能只支持 nfs 或 nfs3，遇到mount.nfs: Protocol not supported就换成-t nfs再试。挂载后df -h | grep nas确认容量和挂载点。这只是半成品，重启后挂载会消失，需要写进 /etc/fstab：

192.168.10.10:/data /mnt/nas nfs4 defaults,_netdev,noatime 0 0

defaults,_netdev是关键：_netdev告诉系统这是网络设备，等网络就绪后再尝试挂载，不加这条，开机时网络还没起，系统会一直卡在挂载等待上，最后进 emergency mode。noatime减少读操作时的访问时间回写，对 NAS 这类远程存储能省不少 IO。

遇到 SMB/CIFS 共享，比如群晖的共享文件夹或 Windows 共享，挂载命令加认证参数：

# 挂载 CIFS 共享，指定用户和 SMB 协议版本 sudo mount -t cifs //192.168.10.20/share /mnt/share -o username=nasuser,vers=3.0

-o里username是共享账号名，vers=3.0指定 SMB 3.0。老服务器如果只支持 SMB1，这个参数要改成vers=1.0，但因为安全原因现代系统默认禁用 SMB1，首选是升级服务器端而不是降版本。CIFS 挂载出现mount error(112): Host is down时，先 ping 确认主机通，再看 vers 是否匹配，这两个问题占了大多数。

注意：改完 /etc/fstab 先执行sudo mount -a验证，确认没有报错再重启，不要直接 reboot 赌运气。

fstab 改完千万别直接重启验证，先执行 mount -a 预演一遍：

# 按 /etc/fstab 挂载所有未挂载项，验证配置没有语法错误 sudo mount -a

有报错当场就能看到，不用赌重启。mount -a是验证 fstab 的后悔药，我改完任何挂载项都会先跑这一条再考虑重启。

4.3 三层排查：ping、端口、应用，逐层缩小范围

排查题讲究顺序。网络不通时，我习惯从下往上查：先链路和网络层，再传输层，最后应用层。

# 第一层：ping 网关，确认本机到内网通不通 ping -c 3 -W 1 192.168.10.1 # 第二层：看本机 80 端口是否在监听 ss -tlnp | grep ':80 ' # 第三层：用 curl 验证应用层响应 curl -I --connect-timeout 3 http://192.168.10.10 # 第四层：确认域名解析结果 nslookup app.example.com 192.168.10.2

ping -c 3发 3 个包，-W 1超时 1 秒，而不是默认的无限等；ss -tlnp | grep ':80 '在端口后面加空格，是为了避免把 8080 也匹配进来；curl 加超时防止卡死；nslookup 第二个参数指定 DNS 服务器，避免走系统里可能被污染的配置。

把这四步串起来，定位规律是这样的：

顺序不能跳。很多人一上来就抓包，抓了半天发现是机器之间网线没通，白费时间。先 ping，再端口，再应用，每层都能回答「通还是不通」，问题范围立刻缩小一半。

4.4 DNS 的隐藏坑：resolv.conf 与 getent 的玄学

DNS 是网络排查里最玄学的一层，因为现象和原因经常隔着两层。最典型的题是「nslookup 能解析，curl 却报域名找不到」。原因多半是应用没有走 nslookup 查的那台 DNS，而是走了系统配置。系统实际的解析路径最好用 getent 验证：

# 走 nsswitch 配置解析主机名，贴近应用的真实解析路径 getent hosts app.example.com

getent会按 /etc/nsswitch.conf 的配置依次查文件、DNS、NIS 等，比 nslookup 更接近应用的实际行为。另一个隐藏坑是 /etc/resolv.conf 被 NetworkManager 或 systemd-resolved 接管，用户手工改了，重启之后又被覆盖。判断是不是被接管，看文件头部注释，如果有「Generated by NetworkManager」字样，正确做法是在 NetworkManager 的连接配置里改 DNS，而不是直接编辑 resolv.conf。

这台机器的 hostname 也常被归到网络段。改主机名的标准命令是 hostnamectl：

# 设置静态主机名并查看当前状态 sudo hostnamectl set-hostname app-server hostnamectl status

hostnamectl status会同时显示 static、transient 等主机名状态，改完能立即看到效果，不必重启。如果发现 shell 提示符没变，重开一个终端就是新主机名。这几道题刷完，网络段的基本盘就稳了。

5. 故障排查与避坑：rm 误删、黑匣子日志与虚拟机蓝屏

100 例里最有含金量的是排错段，因为它考的从来不是知识，而是习惯：先复现、再缩小范围、最后动手。我把刷题和实际运维里翻车最多的三个场景写下来，每条按「现象 → 原因 → 解决」展开，都是我踩过或者看着同事踩过的坑。

5.1 rm 误删：变量为空与未加引号的两记重锤

现象：脚本里写了rm -rf $LOG_DIR/，某次运行 LOG_DIR 没赋值，执行后当前目录被清空，系统直接损坏。

原因：没开set -u，变量展开成了空字符串，$LOG_DIR/实际变成/，rm -rf 顺着根目录一路删下去。这是删目录类脚本最经典的事故，网上每年都有翻车帖。第二个变体是路径写死末尾斜杠，比如rm -rf "$dir/"，当 dir 是/home/app时正常，可一旦 dir 变成空串，又变成删根。

解决：脚本第一行写set -eu，-u让未定义变量直接报错退出，从源头杜绝这种展开；删除前用[[ -n "$dir" ]]判断变量非空；命令写成rm -rf -- "$dir"，--结束参数解析，"$dir"整体作为一个参数，防止路径里带空格或开头是减号。更大的保护是不用 rm 而先 mv 到回收目录：

# 删除前先移动到临时回收区，确认无误再清空 mv "$dir" /tmp/trash_"$$" && echo "已移至回收区，确认后手动删除"

这样即使路径算错，文件还在 /tmp 里，有后悔药吃。从那之后我写任何包含 rm 的脚本，都会保留这条「先移后删」的习惯。

5.2 systemd 服务起不来但日志为空：黑匣子怎么打开

现象：systemctl start app返回 failed，systemctl status app显示进程退出，但journalctl -u app里什么输出都没有，服务像个黑匣子。

原因：最常见的三种。一是 ExecStart 指向的脚本把 stdout/stderr 重定向到了文件，journald 采不到；二是 ExecStart 里用了包含特殊字符的命令，systemd 解析出错但没有把原始错误打出来；三是二进制路径不存在，systemd 启动失败但错误行被服务自身的输出淹没。

解决：先在 unit 里显式指定日志输出方式：

# 强制把服务的标准输出和错误输出交给 journald StandardOutput=journal StandardError=journal

加完systemctl daemon-reload再启动，journalctl -u app 就能看到真实报错。另一个有效动作是用 systemd-analyze 做静态校验：

# 检查 unit 文件的语法和路径引用 systemd-analyze verify /etc/systemd/system/app.service

它会把 ExecStart 里不存在的命令路径、非法参数直接报出来，比反复 restart 试错快得多。遇到还是没有输出的情况，手工去 shell 里执行一遍 ExecStart 的完整命令，通常能立刻复现：权限不足、命令不存在、环境变量缺失都会在终端里现形。日志是排错的第一现场，让日志先落地，问题就解决了一半。

5.3 虚拟机装 Linux 蓝屏：镜像与虚拟化的两处排查

现象：VMware 或 VirtualBox 里安装 Linux 发行版，安装到一半宿主机蓝屏，或者虚拟机开机直接黑屏。

原因：排查下来最常见的有三类。镜像下载不完整，安装器读到损坏的数据触发崩溃；宿主机开启了 Hyper-V、内核隔离等虚拟化功能，和 VMware/VirtualBox 的虚拟化引擎抢 CPU 硬件虚拟化资源；虚拟机设置里开启了不兼容的加速选项，比如 VirtualBox 的 3D 加速在某些显卡驱动下会黑屏。

解决：装系统前先校验 ISO 校验和：

# 对比镜像的 SHA-256 校验和，完整性问题先排除 sha256sum /path/to/linux.iso

和下载页的官方校验和比对，不一致就重新下载。宿主机在 Windows 上蓝屏的，去「启用或关闭 Windows 功能」里关掉「虚拟机平台」和「Hyper-V」，或者改用 WSL2 跑发行版，避免两套虚拟化打架。VirtualBox 黑屏的，在设置里关闭 3D 加速、启用嵌套分页，再重新安装。蓝屏后不要急着重装，抓一下系统事件查看器里崩溃前几分钟的日志，确认是不是指向 hypervisor，这个信息能明显缩短排查时间。

虚拟机问题是 100 例里偏环境的一类，但它训练的是同一个能力：先分层缩小范围，不要看到蓝屏就整机重装。

6. 验证与提速：把题库变成每天随机抽三题的自测脚本

100 例刷完第一遍，最大的风险是「假会」：看答案秒懂，合上书全忘。我的做法是把题库变成自测工具，每天随机抽 3 题，限时完成，不许翻资料。随机抽题用 shuf 一行解决：

# 从 1 到 100 里随机抽 3 个数字，作为今天的练习编号 shuf -n 3 -e {1..100}

shuf 的作用是随机打乱输入序列，-n 3表示只输出 3 个结果，-e后面的{1..100}展开成 1 到 100 的数字列表。抽到题号后，我给自己 10 分钟，在终端里把命令写出来并执行，不看 history、不看 man、不翻笔记。十分钟内能跑出预期结果，算过关；跑不出来的，翻回 100 例对应的章节重新做一遍，第二天再抽一次同区间题目。

这里再多说一个判断掌握程度的标准：不是「敲出来了」，而是「能讲清楚为什么」。比如ss -tlnp里每一个参数不理解，下次换个场景照样卡住。自测完对照下面三个问题过一遍：能否不看文档写出完整命令；能否解释每个参数的作用；出错时能否按「ping → 端口 → 应用 → DNS」的顺序自己定位。三条都满足才是真会。

还可以把高频命令固化成 alias，减少日常敲击成本：

# 把常用排查命令固化为简短别名 alias ports='ss -tlnp' alias nginx-ok='curl -I --connect-timeout 3 http://127.0.0.1' alias untar='tar xzvf'

alias 放在 ~/.bashrc 里，重开终端生效。注意别名不要造太多，超过 10 个自己就记不住了，真正高频的才值得固化。

我自己的感受是：刷完第一遍 100 例后自我感觉非常良好，结果一次线上排查，明明该先 ping 再查端口，我直接去翻应用配置，白费了二十分钟。从那以后，我每次练题都强制走一遍「随机抽题 → 限时 → 不看资料 → 复盘」的流程，一百道题才真正从文档变成了手艺。希望帮到你。

本文还有配套的精品资源，点击获取