简介这份《Linux操作系统基础教程》是一份面向零基础小白的入门级总结以PDF文档承载将Linux学习路径中的核心知识点做了高度浓缩语言平实、示例清晰适合自学或作为教学辅助。内容从Linux与GNU的关系讲起对比四种安装类型帮助读者选择适合自己的部署方式随后梳理mkdir、mv、cd、rm、ls等高频命令的用法剖析/home、/dev、/bin、/etc、/lib、/usr、/var等系统目录各自的作用再深入inode硬链接与软链接、mount磁盘挂载、用户组管理、chmod/chown权限设置以及bash/shell脚本编写。同时讲解grep、find、tee等查找、统计、甄别工具并覆盖makefile构建、ssh远程连接、samba共享和gcc编译等实用场景使初学者能形成从命令操作到系统管理的完整知识链条。资源仅有1个PDF文件整体大小约915KB体量虽小但信息密度高目前已有4409人学习下载经过大量读者验证是一份口碑良好的Linux入门精品。1. 拿到《Linux操作系统基础教程.pdf》之后真正决定水平的是你怎么用很多人手里都存过一份《Linux操作系统基础教程.pdf》下载后从第一章翻到最后一章命令抄了满满几页合上文件站到终端前还是不敢敲、不知道从哪里下手。反直觉的结论是这份 PDF 的价值不在“看懂了”而在“能不能照着做完一个又一个动作”。它解决的是 Linux 的基础认知——文件系统、权限、进程、Shell 与常用命令——但真正让这些变成你能力的是你为每个章节准备一个可重复验证的练习环境。它适合刚接触命令行的同学、刚转运维的开发者以及被图形界面“保护”太久、想真正理解操作系统底层逻辑的人。把这份教程当地图而不是当小说你才可能在一个周末之后真的敢打开终端。2. 从 PDF 到终端先把环境搭好再读这份 Linux 教程2.1 环境选型虚拟机、容器、真机别在第一步就劝退自己拿到教程第一件事不是翻页而是先决定“在哪练”。我见过太多人兴致勃勃打开教程看完用户管理就开始在真机上乱试结果把系统搞坏再也没碰过 Linux。常见做法是先准备一个可以随便折腾、坏了能恢复的环境。虚拟机是最稳的选择。常见虚拟机软件装一个 Linux 发行版比如 Ubuntu 或 CentOS 的 LTS 版本分配 2 核 4G 内存、40G 磁盘装好后立刻做一次快照。快照就是后悔药后面无论你把系统弄成什么样恢复快照就回到原点。权限、用户、systemd 服务、网络配置这些实验虚拟机都能完整覆盖这也是我首选它的原因。容器环境则更轻量适合反复练习命令和文件操作。用一条命令就能进入一个独立的 Linux 环境docker run -it --name linux-basic ubuntu bash这条命令的含义是用 ubuntu 镜像创建一个名为 linux-basic 的容器-i保留输入流-t分配一个伪终端最后面的bash表示进入容器后直接打开 Shell。如果本地没有这个镜像它会自动拉到本地再启动。容器和虚拟机的本质区别在于共享内核容器里的进程直接跑在宿主机的内核上只是做了命名空间隔离。所以容器能练命令、练文件结构、练文本处理但像 systemd 这类需要完整内核权限的系统服务实验容器里经常跑不起来需要在宿主机或虚拟机里做。环境适合练习范围资源占用后悔成本虚拟机全部基础实验含 systemd 与服务管理较高快照可随时回滚容器命令、文件、权限、文本处理低删容器重建即可云主机/真机真实网络与应用场景视配置而定误操作影响真实环境提示容器做得越多越要在虚拟机里补 systemd 实验否则服务管理这块始终是空白。2.2 别按页码顺序读把 PDF 拆成三个时间段学一份 Linux 基础教程通常是按“命令介绍”组织的每个命令一个小节。如果按页码线性读读到中间会发现前面的命令已经忘了一半。我一般会把整份教程按依赖关系切成三段每一段配一个明确的“完成标志”。第一段是文件、目录、用户与权限。先搞懂你站在哪里、谁能碰哪些文件这是后面所有命令的地基。完成标志是你能不假思索地用ls、cd、mkdir、touch、chmod、chown完成一次多用户协作的目录设置。第二段是文本处理与 Shell 基础。重点练管道、重定向、grep、awk、sed这是 Linux 命令行效率的核心。完成标志是给你一份日志文件能在一行命令里提取出想看的信息并解释每个参数的作用。第三段是进程、网络、服务与日志。重点练ps、ss、systemctl、journalctl把命令连成一套排查问题的思路。完成标志是一个服务起不来时你有一套固定的检查顺序而不是漫无目的地乱试。时间段核心内容典型命令完成标准第 1 段文件与权限ls、chmod、useradd独立设置多用户目录第 2 段文本流与 Shellgrep、awk、sed、管道用一行命令分析日志第 3 段进程与服务ps、ss、systemctl独立排查一次服务启动失败这样切的原因很简单内容是层层依赖的。如果不懂文件权限后面看服务启动失败原因时会完全摸不着头脑如果不懂管道和重定向写脚本时每步都要上网查。每段学完立刻用下一节的实验去验证比从头翻一遍有用得多。2.3 边读边记建立一套「场景-命令-坑」格式的 Linux 速查笔记读这类 PDF 最容易出现的问题是笔记抄了命令解释但没抄使用场景遇到实际问题还是不知道用哪条。我自己的习惯是每学完一个单元用自己的话写一条笔记统一按“场景、命令、坑”三段记录存到本地 Markdown 文件里。mkdir -p ~/notes/linux cat ~/notes/linux/file-permission.md EOF # 场景让两个账号协作维护网站目录 ## 命令 chown -R web_dev:web_dev /srv/www/demo chmod -R 750 /srv/www/demo ## 坑 - 750 对“其他用户”没有任何权限写文件会被拒绝 - 父目录缺权限时子目录权限再宽松也进不去 EOFmkdir -p会递归创建不存在的目录cat 文件 EOF是往文件里写入多行内容直到遇到结束标记EOF。这里的EOF加引号表示内容里的特殊字符不做展开原样写入。这种笔记格式的好处是当你第二次遇到同类场景时不需要翻完整本 PDF只需要grep -r 场景名 ~/notes/linux就能找到自己的踩坑记录。笔记不是说明书是给未来自己看的备忘所以每条尽量控制在 10 行以内记录“当时让我卡住的那个点”就够了。3. 把 Linux 基础命令练成肌肉4 个值得反复做的本地实验3.1 实验一建一个多用户网站目录理解权限为什么存在权限章节是基础教程里最容易“看懂但没感觉”的部分。rwx是三个字母但真正体会它在协作中的约束力最好亲手搭一个多用户共享目录。我在练习时通常会模拟一个网站项目开发人员负责更新网页文件运维人员负责备份和发布两边各用一个账号。# 1. 建三层目录结构 mkdir -p /srv/www/demo/{html,logs,backup} # 2. 新建两个不同职责的用户 useradd -m -s /bin/bash web_dev useradd -m -s /bin/bash web_ops # 3. 设置属主和权限位 chown -R web_dev:web_dev /srv/www/demo chmod -R 750 /srv/www/demo ls -l /srv/www/demomkdir -p的-p会递归创建不存在的父目录{}是 Shell 的花括号展开等价于一次创建三个目录。useradd -m同时创建用户家目录-s /bin/bash指定登录 Shell。chown -R的-R递归修改目录内所有文件的属主chmod 750表示属主有读、写、执行权限属组有读和执行权限其他用户没有任何权限。验证实验很简单切换成 web_dev 账号写文件会成功切换成 web_ops 写文件会被拒绝sudo -u web_dev touch /srv/www/demo/html/dev.html sudo -u web_ops touch /srv/www/demo/html/ops.html第二条命令会输出Permission denied这就是权限位在真实协作里的作用。你可以试着把目录改成777再切回 web_ops会发现文件能创建了但这也意味着任何其他用户都能改这个目录。这个实验做完你对“为什么不能用 777 解决问题”会有远比看书深刻的印象。3.2 实验二用 Python 起一个服务复现“端口被占用”排查端口问题在基础教程里通常只讲一条ss -ltn但实际排查顺序比命令本身更重要。这个实验的目标是自己制造一个网络监听然后假装系统里出现了一个“莫名占用端口”的进程练习从端口反查进程。# 在 8080 端口启动一个最简单的 HTTP 服务 python3 -m http.server 8080 # 查看当前监听端口和对应进程 ss -ltnp | grep 8080 # 从输出里记录 PID然后尝试结束它 kill -TERM PIDpython3 -m http.server 8080是 Python 自带的静态文件服务表示放到后台运行。ss -ltnp的-l只看监听中的连接-t限制为 TCP-n不做域名解析-p显示进程信息grep 过滤出 8080。你会看到类似LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:((python3,pid1234,fd3))的输出。这里要养成的习惯是先查端口拿到 PID再往下去看进程。而不是一上来就ps aux | grep python瞎猜。生产环境里同一个程序可能跑了多个实例端口是唯一定位线索。排查完记得把它杀掉kill -9 $(pgrep -f http.server 8080)pgrep -f是按完整命令行匹配进程配合kill -9用于强制结束。但正式环境里不要直接套这种组合先把 PID 和进程名看清楚再动手不然很容易误杀同名进程。3.3 实验三用 awk、sort、uniq 从访问日志里统计接口热度文本处理是 Linux 基础里最值得花时间的部分也是新手最容易产生“看懂了但写不出来”的地方。这个实验直接拿日志当素材先用head看前几行确认字段位置再用awk提取、sort排序、uniq去重最后统计出访问次数最多的接口。head -5 /var/log/nginx/access.log awk {print $7, $9} /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20第一条命令先观察日志格式确认第 7 列是请求路径第 9 列是状态码。不同发行版、不同 Nginx 配置下日志格式会有差异所以先看再写是必须的习惯。第二条命令里awk默认以空格分割列$7是路径、$9是状态码sort把相同内容聚在一起uniq -c统计每行重复次数并把次数加到行首后面的sort -rn按数字逆序把出现最多的排到最前head -20只显示前 20 条。你会看到类似120 /api/login 200这样的输出说明路径/api/login在日志里出现了 120 次其中 200 状态记录了 120 次。这个信息在做接口压测、排查异常流量时非常实用。如果想按接口平均耗时排序可以把$9换成记录耗时的字段比如 Nginx 日志里的$request_time通常靠后用$NF表示最后一列用awk的数组做累加求平均。这一步各发行版字段不一致建议先只做访问量统计跑通了再扩展。3.4 实验四写一个备份脚本并用 crontab 调度服务和脚本是基础教程里的“进阶区”但也是工作中最常用到的一块。这个实验把前面学的命令串起来写一个脚本把实验一的网站目录打包再用crontab定时执行。先写脚本文件#!/bin/bash # 备份脚本把 html 目录压缩到 backup 目录文件名带时间戳 backup_dir/srv/www/demo/backup stamp$(date %Y%m%d_%H%M%S) tar -czf $backup_dir/demo_$stamp.tar.gz /srv/www/demo/html echo done: $backup_dir/demo_$stamp.tar.gz脚本第一行#!/bin/bash声明解释器路径是脚本能被执行的前提。stamp$(date %Y%m%d_%H%M%S)用命令替换把当前时间拼成类似20250101_120000的字符串保证每次备份文件名不重复。tar -czf的-c创建归档-z用 gzip 压缩-f指定输出文件名。保存为/usr/local/bin/demo_backup.sh后需要先赋予执行权限再打开用户级定时任务配置chmod x /usr/local/bin/demo_backup.sh crontab -e在打开的编辑器里写入这一行*/3 * * * * /usr/local/bin/demo_backup.sh /tmp/demo_backup.log 21crontab 的五个字段依次是分钟、小时、日、月、周*/3表示每 3 分钟触发一次。后面的 /tmp/demo_backup.log 21把标准输出和错误输出都追加到日志文件方便脚本出错时追溯。字段范围示例分钟0-59*/3 表示每 3 分钟小时0-230 表示午夜日1-3115 表示每月 15 号月1-121 表示一月周0-70 和 7 都是周日0 表示周日注意crontab 执行脚本时的环境变量很少PATH 可能不含/usr/local/bin以外的路径所以脚本内部尽量写绝对路径。如果发现定时任务没跑先检查脚本能不能手动执行再看日志文件和crontab -l里的配置。4. Linux 基础避坑指南5 个常见翻车现场与排查思路4.1 rm 配通配符删完了才发现路径不对现象在某个目录下执行rm *.log原本想清理当前项目的日志结果发现上级目录里的文件也被删了或者因为一个空格把不该删的文件带了进去。原因Shell 会先把*.log展开成匹配的文件列表再交给rm处理。如果你不在目标目录内或者文件名里有空格展开后的列表可能和你预期完全不同而rm本身不关心这些文件当初是怎么被匹配到的。解决删除前先用echo *.log看一遍展开结果确认无误再删。更稳妥的写法是rm /var/log/app/*.log把路径写进通配符里减少误伤范围。脚本里批量删除建议用find /path -name *.log -delete并且先跑一遍不带-delete的命令查看匹配列表。如果想要交互确认rm -i会逐个询问慢但安全。4.2 遇到权限就 sudo、chmod 777后面排查无从下手现象普通用户访问文件报权限错误第一反应是sudo chmod 777 -R一切或者干脆sudo -i进 root 操作。结果过几天服务起不来日志里全是权限报错你根本不知道是哪个文件被改出了什么问题。原因没搞清楚 Linux 权限模型。777 代表所有用户可读、可写、可执行等于把访问控制的职责完全交了出去。服务以什么用户运行、需要哪些目录的读或写权限这些信息被一条 777 全部抹掉了。解决先ls -l看当前权限和属主想清楚谁在读、谁在写再用最小权限方案。网站目录常见的做法是属主可读写、属组可读可执行其他用户无权限也就是755数据目录需要写时用750把运维账号加入目录的属组。排查路径权限时可以用ls -l /srv/www/demo namei -l /srv/www/demo/htmlnamei -l会解析路径每一级目录的权限能定位到“权限不足”到底发生路径的哪一环。这比一条 777 之后再到处试要快得多。4.3 脚本在 Windows 上写完拿到 Linux 运行报 $\r 错误现象在一台 Windows 机器上用文本编辑器写的脚本传送到 Linux 后执行报错bash: ./backup.sh: /bin/bash^M: bad interpreter看起来像是解释器路径出了问题。原因Windows 的文本文件默认用 CRLF回车换行作为行尾Linux 只识别 LF。^M就是回车符\r它被解析成命令或路径的一部分导致脚本无法执行。解决用sed把行尾的回车符删掉即可sed -i s/\r$// backup.shsed -i表示原地修改文件s/\r$//是替换命令\r匹配回车符$表示行尾整体效果是删除每行末尾的回车。处理后用cat -A backup.sh检查正常行尾应该看到$而不是^M$。习惯上以后在 Windows 里写脚本时把编辑器默认行尾改成 LF或者统一到 Linux 环境里写文件。4.4 管道一接到底该读文件时绕路 cat该交互时又卡死在管道里现象写了cat file | grep keyword其实grep本身就能直接读文件又比如echo select 1 | mysql这类的交互命令执行后卡住不动似乎管道会吞掉后续的输入。原因对管道适用的场景理解不够。cat file | grep没有错但它多起了一个进程没有任何收益。真正的问题是有些人习惯性给所有命令接管道却没意识到管道左侧命令的输出必须是以流的形式结束的右侧命令也必须能消费标准输入。解决能用命令直接读文件时就不需要cat。写成grep keyword file、awk {print $1} file更清晰也更快。需要用管道做二次筛选时再上比如ls -l | grep ^d这种没法让ls直接完成的场景。交互式程序不建议放进管道里先用mysql -e select 1这种方式传参避免进程互相等待。判断标准很简单如果你发现命令不退出八成是某个进程在等输入按CtrlC终止重新设计命令。4.5 systemd 服务启动失败光看 status 找不到原因现象写好一个 service 文件执行systemctl start xxx后提示失败systemctl status xxx只显示Main process exited, codeexited, status1/FAILURE看不到具体原因。原因service 文件的 ExecStart 指向了一个脚本但脚本没有执行权限或者脚本内部用了相对路径服务启动时的工作目录和脚本预期不一致还有一种常见情况是脚本依赖网络而服务启动时网络还没就绪。解决别只盯着 status直接看日志systemctl status demo_backup.timer journalctl -u demo_backup.timer -n 50 --no-pager ls -l /usr/local/bin/demo_backup.shjournalctl -u指定查看某个服务的日志-n 50只显示最近 50 行--no-pager让输出直接打到当前终端避免卡在 less 分页里。看到日志里的具体报错后再回头检查 ExecStart 指向的文件权限和脚本内部路径。很多情况下chmod x加在脚本上服务立刻就能起来。排查顺序我一般固定为先看日志、再看执行权限、最后看脚本里有没有相对路径依赖。5. 学完基础怎么验证一段自测脚本与三条进阶方向5.1 一份自测脚本10 分钟检查基本功学完基础教程不等于学会 Linux你需要一个客观的检查方式。我自己会用一段自测脚本把核心能力串起来跑完没有意外报错说明基础命令已经形成了肌肉记忆。把它复制到你的练习机里跑一遍#!/bin/bash # 自测每段输出 [n] 通过 才说明对应能力过关 test_dir/tmp/linux_self_test mkdir -p $test_dir cd $test_dir # 文件创建与内容匹配 echo hello linux hello.txt grep -q linux hello.txt echo [1] grep 通过 # 权限位识别输出应该包含 rw-r--r-- ls -l hello.txt # 用户与组查询 getent passwd web_dev /dev/null echo [2] 用户查询通过 # 端口监听查看80 没监听也正常 ss -ltn | grep -q :80 echo [3] 80 端口有监听 || echo [3] 80 端口无监听 # 打包与解包 tar -czf hello.tar.gz hello.txt echo [4] tar 打包通过 echo 自测完成set -e没加是故意的因为像端口检查这种步骤不应该中断整个流程。表示前一条命令成功才执行后一条||表示失败时执行后面兜底命令自测脚本里用它们做分支很常见。能顺畅读懂每一行说明你已经有能力自己写排查脚本了。5.2 三条进阶方向怎么选自测通过后下一步不是再去翻教程而是从三条方向里挑一个深入。适合当前工作的优先。方向要补的内容适合谁Shell 自动化变量、循环、函数、参数解析批量处理文件与日志想转运维、做批处理的人服务与安全systemd、日志审计、账号策略、防火墙规则负责项目部署上线的人网络排障IP 路由、抓包工具、连接状态分析后端开发、性能排查场景多的人我自己的习惯是每个阶段只选一个方向沉进去至少独立完成一个真实任务再换方向。三个都浅尝辄止等于每个都没用熟。某次线上问题排查时网络不通我就是靠基础教程里学到的按链路逐层检查的习惯一步步定位到网卡配置才发现当年那些“简单命令”其实都是排障的底层能力。基础这东西没有捷径但也不需要天赋多敲、多试、多记坑一个多月就能见效。希望帮到你。本文还有配套的精品资源点击获取