简介「linux实战100例」是一份面向Linux初学者与运维开发人员的实例型学习资料围绕100个经典代码案例组织内容重点覆盖网络调用命令、Apache参数配置、Linux错误代码解析以及常见应用故障的排查与解决方法适合希望通过动手实践巩固命令行操作、服务配置与问题定位能力的学习者。压缩包共204个文件约40.19MB主体为195个html页面便于按知识点浏览与检索另配3个pdf、少量zip/rar资料包及doc、exe补充材料形成从命令说明到配置详解的参考结构。已有2180人学习说明其在Linux入门与实战查漏方面具有一定参考价值。读者可从中获得功能调用过程的细致说明、典型实例的操作思路、服务参数配置要点以及针对常见报错的解决线索适合作为日常运维查询和系统学习Linux的辅助材料。1. Linux 实战100例先别急着背命令先把“现场”补齐linux 实战100例这个资源名字听着像一本命令速查表真拆开更像一本场景剧本合集它不按 man 手册的字母序排而是把运维现场拆成一例一解从日志里捞 Top IP 到磁盘写满后三分钟定位每一例都带着“先看什么、再看什么”的顺序。适合两类人刚学完基础命令、一上生产机就发怵的新手以及干了几年但排查全靠直觉、想把手感整理成套路的老手。它解决的不是“不知道有这个命令”而是“知道命令却不知道先敲哪个”。2. 拆开这 100 例案例颗粒度、演练环境与刷法拿到一份案例集最怕的是从上往下顺着敲一遍敲完只记住了ls -l的输出长什么样。这一章先把案例按颗粒度分类再搭一台可以随便破坏的演练机最后给一个能落地的刷题节奏。这三件事做完后面的内容才吃得进去。2.1 三类颗粒度单命令、组合管道、场景剧本案例集里的 100 例并不是同一个难度层级。按我拆下来的经验大致能分三层三层对应的能力和复现成本完全不同颗粒度典型例子复现成本真正练到的能力单命令find按时间/大小/权限筛文件、ss看监听、stat看元数据一分钟随时可跑认参数、认输出字段组合管道awksortuniq统计 Top N、findxargs批量处理需要先造样本数据数据流思维、字段切分场景剧本磁盘写满、服务起不来、403、定时任务不执行需要快照机 故意造故障排查顺序、收敛思路第一层最容易产生错觉命令敲出来了输出也对就以为会了。实际上单命令的价值在于“认输出”比如ss -lntp里Recv-Q不为 0 意味着什么df -hT里-i和普通模式差在哪这些细节在生产现场才是决定性的。第二层是分水岭。很多人卡在“知道awk能切列但不知道该切第几列”。案例集里的组合管道例子基本都基于固定格式的文本访问日志、ps输出、/proc下的文件练的是“先确认字段分隔符再数第几列”这个动作。这个动作练熟了后面看任何日志都不慌。第三层才是真正值钱的部分。场景剧本类案例不是教你一条命令而是给你一条路径现象是什么、第一个命令敲什么、看到什么结果就换方向。这类案例必须配合可破坏的环境在真机上试是要出事的。提示如果时间有限优先把第三层吃透。前两层随时能查手册补第三层的排查顺序查不到。2.2 演练环境一台可以随便破坏的快照机场景类案例的第一步不是敲命令而是准备一台“砸了不心疼”的机器。常见做法是虚拟机加快照或者用容器起一个临时环境。虚拟机更适合练磁盘、分区、systemd这类碰内核状态的案例容器起得快但systemd、/proc的部分信息会受限只适合练文本处理和权限。我一般会先在演练机上建一个专用目录把案例需要的样本数据一次性造好避免每次都要临时拼测试文件# 建一个只用来造破坏的演练目录和生产路径彻底隔离 sudo mkdir -p /lab/cases sudo chown $USER:$USER /lab/cases cd /lab/cases # 造 200 个测试文件供 find / xargs / 通配符相关案例使用 for i in $(seq 1 200); do printf case-%s\n $i file_$i.log done # 造一份假的访问日志字段顺序对齐常见 combined 格式 for i in $(seq 1 500); do printf 10.0.0.%s - - [10/Oct/2024:13:%02d:00 0800] GET /a HTTP/1.1 %s 512\n \ $((RANDOM % 20 1)) $((RANDOM % 60)) $((RANDOM % 2 ? 200 : 503)) done access.log ls | wc -l这段脚本干了三件事建隔离目录、批量生成小文件、生成一份字段可预测的假日志。chown $USER:$USER是为了后面练权限案例时不用一直sudoseq 1 200的数量不要太大两百个文件足够让find和xargs的输出有可读性假日志里刻意混了200和503是为了后面统计状态码比例时能看到明显差异全是 200 的日志练不出手感。快照策略也要提前想好。我的习惯是装完系统、配好网络、建完/lab目录之后打第一个快照标记为“干净态”。每练完一组破坏性案例分区、fstab、systemd单元、sudoers回滚一次。血泪经验是练fstab那组案例时没打快照写错一行挂载参数重启直接进救援模式一晚上就没了。注意涉及分区、fstab、grub、sudoers的案例一律在快照机上做回滚成本是几十秒真机上就是几小时。2.3 刷法与时序先猜输出再敲命令案例集最容易浪费的地方是把它当小说看。看的时候觉得“哦这个我会”合上就忘。有效的刷法是给每一例加一个“预测”动作读题之后先别敲用纸或者注释写下“我猜输出会是什么样”然后再敲对比差异。差异出现的地方就是你真正没掌握的地方。节奏上我建议分三段总量 100 例三周左右阶段案例范围每天量阶段目标认输出1–40 例6–8 例看到输出能立刻指出哪一列是关键字段串管道41–75 例5 例三步管道内拼出想要的结果演剧本76–100 例2–3 例从现象推到根因路径不跑偏第一阶段的 40 例基本都是单命令别嫌简单重点是把--help和man对着看一遍尤其是find的-mtime、-perm、-newer这几个参数参数含义记混了后面全是坑。第二阶段开始上管道每一例都要求自己先写出字段位置再动手awk {print $1}里的$1是怎么数出来的必须能说清。第三阶段最慢一天两三例就够因为每一例都要经历“造故障 → 观察 → 收敛 → 回滚”四步快不起来。刷的过程中建一个自己的速查文件只记“我踩过的”而不是“手册上有的”。比如“du -sh /*会跨挂载点要加-x”“grep -r遇到二进制文件会打印乱码加-I”这类条目攒到三十条比任何速查表都好用。3. 高频案例抄作业文本三件套、权限定位与服务托管100 例里出现频率最高的三类基本覆盖了日常八成的工作量从文本里捞信息、判断“为什么访问不了”、把脚本变成一个能被托管的服务。这一章把这三类的典型解法展开代码可以直接抄到演练机上跑。3.1 文本三件套grep 定位行awk 切字段sed 改配置三个工具的分工要分清grep负责“哪几行”awk负责“第几列、怎么算”sed负责“改成什么”。混着用没问题但心里要有这个分工不然写出来的管道自己第二天都读不懂。先看统计类案例这是案例集里出现最多的一类# 统计访问量 Top 10 的来源 IP awk {print $1} access.log | sort | uniq -c | sort -rn | head -n 10 # 按小时聚合 5xx 数量$4 形如 [10/Oct/2024:13:05:00按冒号切第 2 段是小时 awk $9 ~ /^5/ { split($4, t, :); print t[2] } access.log | sort | uniq -c第一行拆开看awk {print $1}取第一列默认按空白切分日志里第一列就是 IPsort排序让相同 IP 相邻uniq -c把相邻重复项合并并计数sort -rn按数字倒序head -n 10取前十。顺序不能换uniq只认相邻重复跳过sort直接uniq -c会得到一堆计数为 1 的行。第二行的关键是字段位置。$9是状态码$4是带方括号的时间串split($4, t, :)把它按冒号切成数组tt[2]就是小时段。这里有个坑如果日志时间格式不是方括号包起来的字段位置会整体前移$4就可能变成请求行。动awk之前先head -n 3 access.log确认格式比事后 debug 省事。再看改配置类案例。生产上改配置文件最忌讳直接sed -i# 先看会被改到哪几行确认匹配范围 grep -nE ^[[:space:]]*Listen[[:space:]]80$ /etc/nginx/nginx.conf # 确认无误后再原地改-i.bak 留一份后悔药 sudo sed -i.bak -E s/^([[:space:]]*)Listen[[:space:]]80$/\1Listen 8080/ /etc/nginx/nginx.conf # 改完做语法校验别直接 reload sudo nginx -t-i.bak会在改之前生成一个同名.bak文件这是最便宜的后悔药。正则里用^和$锚定整行避免把注释行#Listen 80也改掉[[:space:]]*保留原有缩进配置文件的缩进乱了以后排查很痛苦。最后一步nginx -t是必须的配置语法错了直接 reload 会把正在跑的服务带下去。参数上还有两个细节值得记sed -E开启扩展正则省掉一堆反斜杠grep -n输出行号配合sed -n 12,20p可以只改某一段。批量改多个文件时用grep -rl先列出文件清单再套xargs sed -i.bak比find -exec更可控。3.2 权限与属主一条 403 的完整定位链“文件明明在就是访问不了”是案例集里最经典的剧本之一。多数人的第一反应是chmod 777这是典型的治标不治本。正确的顺序是从路径最外层往里看。# 逐级列出路径上每一层目录/文件的权限、属主、属组 namei -l /var/www/site/uploads/2024/report.pdf # 以服务实际运行的账号身份验证到底能不能读 sudo -u www-data test -r /var/www/site/uploads/2024/report.pdf \ echo readable || echo denied # 看有没有 ACL 在捣乱getfacl 比 ls -l 多出一层信息 getfacl -p /var/www/site/uploads/2024/report.pdfnamei -l是这条链上最值钱的命令它把路径上每一层的权限一次性摊开。常见的 403 根因是“文件是 644但中间某一层目录少了x位”——目录的x表示“可以穿过”没有x就算文件本身可读也进不去。这个知识点看十遍书不如namei -l输出一次。sudo -u那行是排除法以服务的真实身份去test -r返回 denied 就说明问题在权限返回 readable 就说明问题不在文件系统往 SELinux、服务配置、上游转发去查。getfacl用于兜底。有些环境用 ACL 给单个账号开过权限ls -l看到的是号具体规则要看getfacl。ACL 和普通权限是叠加关系排查时两边都要看。修复动作要按最小权限来。目录给755、文件给644、属主改成服务账号这三步能解决绝大多数问题# 目录补上 x 位文件保持 644属主交给服务账号 sudo chmod 755 /var/www/site/uploads /var/www/site/uploads/2024 sudo chmod 644 /var/www/site/uploads/2024/report.pdf sudo chown -R www-data:www-data /var/www/site/uploadschmod -R 777之所以危险不只是安全问题。有些服务对权限过宽的文件会直接拒绝比如密钥文件权限不是600就会被判定为不安全而拒绝加载改完反而更糟。权限这组案例的正确练法是在演练机上故意把某一层目录改成700、属主改成别的账号然后只用namei和sudo -u两个工具把根因找出来。3.3 systemd 托管把脚本变成能自启、能重启的服务案例集里有一组专门讲“脚本手动能跑一关终端就死”。答案是别用nohup硬扛写成systemd单元。这是从“会用命令”到“会交付”的分界线。# /etc/systemd/system/demo-app.service [Unit] Descriptiondemo app Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple Userappuser WorkingDirectory/opt/demo EnvironmentAPP_ENVprod ExecStart/opt/demo/run.sh Restarton-failure RestartSec5 LimitNOFILE65535 StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target几个参数值得逐个说清。Typesimple表示ExecStart启动的进程就是主进程适合前台运行的脚本如果程序自己会fork到后台要用Typeforking并配PIDFile配错了systemctl stop会停不干净。After和Wants一起写保证网络就绪后再启动只写After不写Wants时如果目标单元没被其它服务拉起来顺序保证就落空。Restarton-failure只在非零退出时重启RestartSec5防抖动避免程序启动即崩导致反复拉起刷日志。LimitNOFILE是文件描述符上限高并发服务不设这个跑一段时间就会遇到Too many open files。写完单元文件后的动作是固定的四步sudo systemctl daemon-reload # 改了 unit 文件必须重载 sudo systemctl enable --now demo-app # 开机自启 立即启动 systemctl status demo-app --no-pager # 看 Active 和最近几行日志 journalctl -u demo-app -f # 跟踪日志排错时盯着这个daemon-reload是最容易漏的一步。改完 unit 不重载systemctl restart用的还是旧配置会出现“我明明改了但没生效”的玄学现象。enable --now是enable加start的合并写法省一条命令。练这组案例时建议故意制造三种失败ExecStart路径写错、User写成一个不存在的账号、脚本里exit 1。然后只用systemctl status和journalctl -u把原因读出来。status输出里Process: ... status203/EXEC表示执行文件不可执行或路径不对status217/USER表示账号不存在这两个错误码记住能省很多时间。4. 现场取证三连磁盘写满、端口占用、日志暴涨的排查顺序这三个剧本在案例集里占了不小的篇幅也是真实环境里最常被叫去处理的。它们的共同点是现象很吓人根因往往很小。区别在于排查顺序不能乱顺序错了会白跑很多冤枉路。4.1 磁盘写满先分清是块满了还是 inode 满了看到“No space left on device”第一步不是删文件是分清哪种满df -hT / # 看块使用率 df -i / # 看 inode 使用率 du -xh --max-depth1 / 2/dev/null | sort -rh | head -n 10df -hT带-T是为了看到文件系统类型overlay、xfs、ext4在处理方式上不一样。df -i容易被忽略小文件特别多的场景缓存目录、会话文件、邮件队列会出现块还剩很多但 inode 耗尽此时删大文件完全没用要删的是数量。du -xh里的-x表示不跨挂载点不加这个参数会跑到/proc、/mnt下面去输出一堆无关内容还慢。定位到具体目录后最常见的坑是“文件删了但空间没回来”# 找出被进程持有、但目录项已删除的文件 sudo lsof L1 2/dev/null | head -n 20 # 日志类文件正确的清空方式保留 inode只清内容 sudo truncate -s 0 /var/log/demo/big.loglsof L1列出 link count 小于 1 的打开文件也就是“已经rm了但进程还拿着句柄”。这类文件空间不会释放直到进程退出或重新打开。解决方式两种重启对应进程或者用truncate -s 0清空前提是还有目录项。日志文件不要用rm删用truncate -s 0或者: file前者更明确后者更短效果一样。参数上还有两个细节du和df结果对不上时先查lsof L1再查挂载点是否被覆盖有东西挂到了非空目录上。df显示的空间是整个文件系统的du只统计当前能看到的目录项这个差值就是被删文件或者被覆盖目录占用的部分。4.2 端口占用与进程假死从端口反查到进程现场“端口被占用”这类报错正确做法是反查而不是猜# -l 监听态 -n 不解析 -t TCP -p 显示进程 sudo ss -lntp | grep :8080 # 拿到 PID 后看它的启动时间、父进程、完整命令行 ps -o pid,ppid,etime,cmd -p 12345 # 看它实际用的是哪个工作目录、哪份配置文件 sudo ls -l /proc/12345/cwd /proc/12345/exe sudo tr \0 \n /proc/12345/environ | grep -iE CONF|ENVss -lntp比netstat快得多-p需要 root 才能看到别人的进程。拿到 PID 之后ps -o etime看运行时长很有用如果这个进程已经跑了三个月那它大概率是正常服务你新起的那个才该换端口。/proc/PID/cwd是指向工作目录的软链很多“配置改了不生效”的问题根源是进程的工作目录和你想的不是同一个。/proc/PID/environ是启动时的环境变量快照用tr \0 \n转成可读格式后grep能确认它加载的是哪套配置。进程状态也要看。ps输出里D状态不可中断睡眠通常卡在 IO 上kill -9都杀不掉这时候要去看存储和内核日志Z状态是僵尸说明父进程没回收杀它没用要处理父进程。停进程的顺序是有讲究的先kill -TERM等几秒确认退出再考虑kill -KILL。直接上-9会让进程没机会刷缓冲、没机会删锁文件数据库类进程还可能损坏数据文件。案例集里专门有一例演示这个差别值得动手复现一次写个脚本捕获TERM信号打印一行再退出对比-9的表现印象会深很多。4.3 日志暴涨logrotate 配置与 journald 限额日志把磁盘吃满事后再清是下策事前配置才是正解。文件类日志交给logrotate# /etc/logrotate.d/demo-app /var/log/demo/*.log { daily rotate 14 maxsize 200M missingok notifempty compress delaycompress copytruncate }逐项说明daily按天切maxsize 200M是保险丝——没到一天但超过 200M 也切两个条件满足其一就触发这是防止单日暴涨把盘打满的关键rotate 14保留 14 份compress压缩历史文件delaycompress让最新一份不压缩因为程序可能还在往里写copytruncate适用于不支持重新打开日志文件的程序先复制再清空原文件代价是切换瞬间可能丢几行。如果程序支持USR1信号重开日志用postrotate发信号更干净不会丢行。# 干跑一次看它打算怎么切不实际执行 sudo logrotate -d /etc/logrotate.d/demo-app # 强制切一次做验证 sudo logrotate -f /etc/logrotate.d/demo-app-d是 dry run只打印不执行配置写错时靠它发现问题。-f强制执行用于验证配置是否真的生效别在生产高峰期跑。系统日志走journald它有自己的容量控制默认上限和所在发行版的配置有关不设的话长期运行会稳定吃掉几个 G# 查看当前 journal 占用 journalctl --disk-usage # 立刻收缩到 500M sudo journalctl --vacuum-size500M持久化配置在journald.conf里SystemMaxUse1G控制总上限SystemMaxFileSize控制单个文件改完systemctl restart systemd-journald生效。--vacuum-size是应急手段治标配置文件才是治本。这组案例的正确练法是在演练机上用dd或循环写日志把盘填到 90%然后分别在“有 logrotate”和“没 logrotate”两种配置下观察一天差别一目了然。5. 避坑清单这 5 个案例我建议你先看翻车记录再动手案例集里有些例子看着简单实操时翻车率极高。下面五条是我自己以及身边人真实踩过的按“现象 → 原因 → 解决”写动手前扫一遍能省不少时间。5.1rm -rf拼变量目录被清空的经典写法现象脚本里rm -rf /data/app/$DIR/执行后/data/app/下的内容全没了包括不该删的。原因$DIR为空或者没定义时路径变成/data/app//等于删掉整个目录。加上脚本里有set -e也没用因为rm本身返回成功。解决三件事一起做——脚本开头set -u让未定义变量直接报错用${DIR:?DIR is empty}强制非空执行前先echo预览。#!/usr/bin/env bash set -euo pipefail DIR${1:?usage: cleanup.sh subdir} TARGET/data/app/${DIR} echo [dry-run] would remove: ${TARGET} rm -rf -- ${TARGET:?}${1:?}的冒号表示“未设置或为空都报错”比${1?}严格。路径变量统一加双引号防空格和通配符展开。--让rm停止解析后续参数避免目录名以-开头时被当成选项。5.2 在/tmp下跑服务重启后文件凭空消失现象程序放/tmp下能跑机器重启或者过一段时间后服务起不来报“文件不存在”。原因/tmp在多数发行版上是tmpfs内存盘或带定期清理策略systemd单元里如果开了PrivateTmptrue服务看到的/tmp是独立命名空间和你手动登录看到的不是同一个。解决可执行文件和配置一律放/opt或/usr/local下临时文件放到/var/tmp或自建目录确认 unit 文件里没有多余的PrivateTmp。# 确认 /tmp 是不是内存盘以及清理策略 findmnt /tmp systemctl show demo-app -p PrivateTmpfindmnt的输出里tmpfs就是内存盘重启必丢。systemctl show能看到单元的最终生效属性比翻 unit 文件可靠因为还有 drop-in 目录里的配置会叠加。5.3 用kill -9代替正常停止锁文件与数据文件遭殃现象进程停不掉就用-9之后重启报“端口已被占用”或者数据文件损坏。原因SIGKILL不可捕获进程没机会执行清理逻辑——锁文件不删、缓冲不刷盘、子进程变孤儿。端口处于TIME_WAIT或者子进程还占着监听。解决先TERM再等待最后才KILL确认没有子进程残留清理遗留锁文件前先确认没有同类进程在跑。PID12345 kill -TERM $PID for i in $(seq 1 10); do kill -0 $PID 2/dev/null || break sleep 1 done kill -0 $PID 2/dev/null kill -KILL $PID || echo graceful exitkill -0只做存在性检查不发信号适合用来轮询。循环 10 次、每次 1 秒给进程 10 秒的优雅退出窗口这个时长对多数服务够用。5.4 习惯性chmod -R 777越改越连不上现象为了省事把目录递归改成 777结果 SSH 免密登录失效或者某个服务直接拒绝启动。原因部分程序对权限有强校验密钥文件权限过宽会被判定为不安全而拒绝使用目录加了w位还可能被其它账号篡改。解决按最小权限恢复——目录755、普通文件644、私钥600、.ssh目录700改完用namei -l逐级复核。chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys ~/.ssh/id_ed25519 chmod 644 ~/.ssh/known_hosts ~/.ssh/config namei -l ~/.ssh/authorized_keys改权限时不要用-R一把梭.ssh下每类文件的正确权限不一样递归会把该600的也变成644。5.5 crontab 手动能跑、定时不执行现象命令行里执行脚本一切正常加到crontab后毫无动静日志里也看不到报错。原因cron的环境变量极简PATH通常只有/usr/bin:/bin脚本里用的python3、node、docker可能根本不在这个路径里另外%在 crontab 里是换行符命令里带日期格式化会被截断。解决命令全用绝对路径脚本开头自己source环境输出重定向到日志文件%用\%转义。# crontab -e SHELL/bin/bash PATH/usr/local/bin:/usr/bin:/bin 30 2 * * * /opt/demo/backup.sh /var/log/demo/backup.log 21SHELL和PATH写在 crontab 顶部对所有条目生效这比在每个脚本里硬编码更集中。 ... 21把标准输出和错误都落到文件不然失败时连线索都没有。排查时先看/var/log/cron或者journalctl -u crond确认任务到底有没有被触发再区分是“没触发”还是“触发了但命令失败”。6. 把 100 例压成一页 runbook验证脚本与自检习惯案例刷完不等于会用中间差的是一层“验证”。我的做法是把 100 例收敛成一页纸的检查清单每条只写三样东西什么现象、第一个命令、判断标准。然后在演练机上用脚本把能自动验证的部分跑一遍跑不通的就是没真会。下面这个骨架可以在每次改完系统配置后跑一遍输出一份体检报告#!/usr/bin/env bash # 系统体检把案例里最常用的几项检查串成一次执行 set -uo pipefail echo 磁盘 df -hT -x tmpfs -x devtmpfs | awk NR1 || $60 80 df -i -x tmpfs -x devtmpfs | awk NR1 || $50 80 echo 被删除但被占用的文件 lsof L1 2/dev/null | awk NR1 {print $1, $7, $NF} | head -n 10 echo 失败的单元 systemctl --failed --no-legend --no-pager echo 监听端口 ss -lntp | awk NR1 {print $4, $6} | sort -uset -uo pipefail去掉了-e因为体检脚本要允许某一项检查失败后继续跑完pipefail保证管道中间出错时整体返回非零不会被最后一个awk的成功掩盖。df那句用awk过滤使用率大于 80 的行输出为空就说明没风险。--failed只看失败单元--no-legend去掉表头方便肉眼扫。验证效果的标准也很简单把同一条命令在故障前后各跑一次两次输出必须有肉眼可见的差异。比如磁盘满的案例修复前df -i的使用率接近 100%修复后掉回个位数端口占用的案例修复前ss -lntp有两条记录抢同一个端口修复后只剩一条。如果跑完看不出差异说明这一例还没真正复现。案例类型验证方式通过标准文本处理换一份格式相同但内容不同的日志重跑结果仍正确字段位置不变权限问题用sudo -u以服务身份访问返回 readable 且服务能实际取到文件服务托管手动kill主进程后观察5 秒内自动拉起status显示新 PID磁盘问题修复前后各跑一次df -hT和df -i使用率明显回落被删文件条目消失定时任务临时改成每分钟执行一次日志里有输出无command not found表格里最有价值的是“文本处理”那一行。很多人练完案例只验证了当前这份样本换个日志格式或者换个字段位置就崩。真正过关的标志是换数据源还能跑。最后是一个习惯所有涉及删除、权限、挂载、单元文件的操作先在演练机上敲一遍把输出贴到自己的 runbook 里再上真机。从那以后我每次动生产机的配置都强制走一遍“快照 → dry run → 校验命令 → 观察五分钟”这个流程多花三分钟少熬三个晚上。这份 linux 实战100例的资源我按场景分了目录对着上面这套刷法从第一例开始敲比自己从头翻手册快得多希望能帮到你。本文还有配套的精品资源点击获取
