身边经常有同事和朋友问我，Linux到底该怎么学。市面上教程不少，但大多数人买书翻两页就吃灰，看视频跟着敲几行命令就犯困，真到工作里遇到问题，还是只会ls、cd、pwd三件套。我之前整理过一份个人Linux学习笔记，参考过尚硅谷的系列课程，也踩过不少坑，前前后后积累了两万多字，基本把日常开发和运维里能用到的常用命令都覆盖了。今天把这些笔记的核心思路、分类方法、避坑经验全部倒出来，从命令分类到实操场景，从笔记整理到问题排查，一次性讲透。

这份内容不是让你从头到尾背一遍，而是提供一个思路：把命令按功能模块拆开，配合“场景索引”来用，遇到问题知道该查哪一类、该用哪条命令。无论你是刚接触Linux的新手，还是写了几年代码但没正经学过命令行的开发者，甚至是要扛线上故障的运维朋友，都能在里面找到自己需要的东西。

1. 内容整体设计与思路拆解

1.1 为什么我不按“教程顺序”记笔记，而是按“功能模块”拆

第一次系统性学Linux的时候，我也跟着课程一节一节记笔记，从目录结构讲到文件权限，再从进程管理讲到网络配置。记了半个月，打开笔记本发现前面记的东西已经忘得差不多了，翻的时候根本不知道哪条命令在哪个章节里。

后来我换了一个思路：不再按课程大纲顺序记，而是按命令“解决什么问题”来分类。比如文件操作归文件操作，文本处理归文本处理，网络排查归网络排查。这带来的最大好处是——当你遇到“磁盘满了想查哪个目录占空间大”这种具体问题时，你不需要回忆“这到底是第几章的内容”，你只需要打开笔记找到“磁盘管理”分类，直接就能看到du、df、lsblk这些命令的用法和参数。

这套分类方式本质上是给命令建了一个“索引”。Linux命令本身有上千条，但绝大多数场景下真正高频使用的其实只有一百来条。只要把这一百多条精读、啃透，配合man、help等内置帮助机制，应付日常开发、服务器部署、故障排查完全够用。这也是那两万字笔记的核心逻辑：先用分类框架构建体系，再用高频命令填充细节。

1.2 笔记的“场景索引”思路：面试前、排障时、写脚本时怎么查

命令分类整理好之后，我还做了一步很重要的操作——在分类前面加了一个“场景速查索引”。这就像书的目录之外再加一个“附录：按需查找”。举例来说：

• 面试前速查：重点看进程管理、权限管理、软链接与硬链接、重定向与管道、systemd与定时任务这些模块。
• 线上排障：重点看CPU、内存、磁盘、网络排查相关命令，比如top、free、df、du、iostat、sar、netstat、ss、tcpdump。
• 写脚本时：重点看文本处理与文件操作部分，尤其是grep、sed、awk三件套的常用姿势。
• 容器和微服务场景：重点关注docker命令、kubectl常用命令以及nginx等服务的启停和日志查看命令。

这个索引不复杂，甚至不需要单独成文，就是在笔记开头放一段列表，写明“什么场景看哪一节”。但非常管用，因为它解决的痛点不是“学不会”，而是“找不到”。人的记忆终究有限，把“记住命令”变成“记住怎么查命令”，学习效率会高很多。

1.3 为什么用“手敲验证”代替“抄笔记”

刚开始记笔记的时候，我也犯过一个经典错误：听视频里老师敲了什么命令，我就原样抄到笔记里，留着“以后再看”。结果当然是不会。

后来我把所有命令都自己在虚拟机上敲一遍，包括故意敲错、故意不按课件来，观察报错信息长什么样。特别是rm、dd、mkfs这类危险命令，我也在虚拟机里验证过它们的破坏性行为。这个过程最大的价值不在于“我记住了命令”，而在于“我见过它的输出、报错和变化”。等真正在服务器上遇到问题时，看到的提示信息往往似曾相识，处理起来就从容很多。

所以包括这篇博客里的例子，我都建议你照着手敲一遍。笔记是给人用的，不是收藏品。你亲手敲出来的每一条命令，都会在脑子里留下一个“肌肉记忆”，这比盯着屏幕看一小时都有效。

2. 高频命令分类拆解与实操要点

2.1 文件与目录操作：从ls到find，别只会用个ls

文件操作是Linux里最基础的功命，但大多数人用得很浅。ls、cd、cp、mv、rm这些命令属于“刻在DNA里”的内容，这里不展开，我重点说几个容易踩坑又特别高频的点。

先说ls的隐藏参数。ls -lh是最常用的组合，-l显示详细信息，-h把文件大小转成人类可读格式。遇到想按时间排序的场景，用ls -lt，最新修改的文件排最上面，配合head -5可以快速看一眼最近改动过哪些文件。如果是找隐藏文件，比如查看家目录下的.bashrc，得用ls -la，不加-a是看不到点开头文件的。

再说rm。这个命令在服务器上操作一定要十二分小心，rm -rf虽然好使，但也经常把整个目录都扬了。我个人的习惯是：在生产环境的服务器上，优先用mv把文件挪到一个临时目录或改名，确认没问题再删。比如想让文件“消失”，先执行mv app.py /tmp/app.py.bak，观察一段时间，确定不影响服务后再清理。这比直接rm要安全得多。

再来看find。很多初学者觉得find很难记，其实核心就是两个关键点：查找路径和匹配条件。比如想找整个/opt目录下所有日志文件：

find /opt -name "*.log"

想找最近7天内被修改过的.conf文件：

find /etc -name "*.conf" -mtime -7

想直接找到文件并删除（慎用），可以加**-exec**：

find /tmp -name "*.tmp" -exec rm {} \;

这里有个我自己的习惯：find在大量文件目录里搜索时速度并不快，因为它是实时遍历磁盘。如果只是按文件名找，可以用locate命令，它查的是系统预建的数据库，速度极大快于find。不过locate依赖updatedb定时更新索引，新创建的文件可能查不到，所以“刚创建的、立刻要找”的文件还是用find更稳妥。

2.2 文本处理三板斧：grep、sed、awk怎么配合使用

文本处理这块，我把grep、sed、awk称为“三板斧”。很多脚本和排障场景里，这三条命令组合起来能解决八成问题。

先讲grep。它最本质的能力是从文本里“筛选行”。比如从日志里查ERROR：

grep "ERROR" app.log

常用参数里，-i忽略大小写，-E支持扩展正则，-l只显示包含关键字的文件名，-A 5和**-B 5**分别显示匹配行的后5行和前5行。排查线上问题时这招特别有用，比如查某个报错前后发生了什么，直接：

grep -A 20 -B 5 "OutOfMemory" app.log

一条命令就能把异常前后的日志都拉出来。

再讲sed。它的核心是“逐行处理文本”，最常用的就是替换。比如把配置里所有8080端口改成9090：

sed -i 's/8080/9090/g' server.conf

注意这里**-i**表示原地修改，没加-i的话只会把结果输出到终端，文件本身不变。我第一次用sed就是忘了加-i，改了“半天”发现文件还是老样子，当场傻眼。另外还有一个常见场景：删除文件里的前10行：

sed -i '1,10d' access.log

最后是awk。它擅长“按列处理”。比如统计access.log里每个IP出现的次数，这是排查来源流量的经典套路：

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

这条命令流水线式地完成了“提取第一列-排序-统计去重-按次数排序”四个动作，熟练之后对日志分析帮助极大。awk默认按空格/制表符分列，如果想按其他分隔符，用**-F**指定，比如按冒号切分/etc/passwd：

awk -F: '{print $1}' /etc/passwd

grep、sed、awk三者不是替代关系，侧重点完全不同：grep挑行，sed改内容，awk切列。真正工作中它们经常连起来用，先定位，再修改，最后提取，一气呵成。

2.3 磁盘与内存排查：df、du、free的“隐藏用法”

服务器跑着跑着磁盘满了、内存不够了，这类问题几乎人人都会遇到，但很多人只知道df -h和free -m，到这里就卡住了。

先说说磁盘排查。df -h能看分区整体使用率，但“哪个目录吃掉了空间”得靠du来查。我常用的是一条组合命令，列出当前目录下占用最大的前10个目录：

du -sh * 2>/dev/null | sort -rh | head -10

-s表示汇总每个目录的总大小，-h是人类可读格式，2>/dev/null是屏蔽无权限访问目录的报错信息，sort -rh按数值倒序排序，head -10取前10。这一条命令基本成了我上服务器必敲的“开场白”。

再往下排查大文件，可以用find找到大于1G的文件：

find / -type f -size +1G -exec ls -lh {} \;

注意find /会遍历整台机器，如果服务器特别大，建议锁到具体目录，比如find /home -type f -size +500M。

内存这块，free -h看整体内存时，很多人容易把“available”和“free”搞混。free列指的是完全没被使用的内存，available列才是估算的“还能给新进程用多少”的内存，后者往往比前者大不少，判断内存够不够主要看available。更深入一点，可以用top进入交互界面按P（CPU排序）、M（内存排序）、E（扩展内存显示）快速定位是哪个进程占资源。

2.4 进程管理与后台运行：别让任务跟着终端“陪葬”

用SSH连服务器跑任务，最讨厌的就是终端一关，任务就断了。这背后涉及Linux的进程生命周期知识，也是很多新手第一次理解“前台进程”“后台进程”“守护进程”这些概念的场景。

最简单的后台运行方法是加个**&**：

python train.py > train.log 2>&1 &

这条命令的意义是把标准输出和错误输出都重定向到train.log，然后放到后台执行。但这里有个隐患：如果直接关闭SSH会话，使用某些终端模拟器时进程会收到SIGHUP信号而被终止。所以更稳妥的方式是用nohup：

nohup python train.py > train.log 2>&1 &

nohup全称是“no hang up”，调整了进程对挂断信号的处理，通常配合&使用。后来我尝试了更强力的方案——screen和tmux。这两个是“终端复用器”，允许你创建多个虚拟会话，断网了重新连回去还能看到之前的界面。我习惯用tmux，个人感觉快捷键比screen顺滑。新建会话、脱离会话、重连会话，只需记住三组快捷键：

tmux new -s work # 新建名为work的会话 tmux detach # 脱离当前会话（或者按 Ctrl+B 再按 D） tmux attach -t work # 重新挂到work会话

排查进程本身用ps，但要会挑参数。ps -ef是完整格式输出，ps aux是BSD风格输出，四舍五入差不多。配合grep可以快速定位某个服务：

ps -ef | grep nginx

如果想知道nginx进程到底监听了哪些端口，别用ps猜，直接ss -lntp（如果系统没有ss就用netstat -lntp）。这条命令能列出所有监听中的TCP端口，配合-p参数可以查到进程PID和名称，排查端口占用比对着ps逐个猜快得多。

2.5 权限管理：chmod、chown、sudo的“度”怎么把握

权限问题是Linux新手最容易挂掉的一环。关于权限，必须理解三套角色（owner、group、others）和三种权限（读r、写w、执行x）。r值4、w值2、x值1，这是八进制的本质来源。比如chmod 755 file，含义是owner拥有读写成权限（4+2+1=7），group和其他人只读+执行（4+1=5）。

实际工作中，最常犯的错误是无脑chmod 777。这在学习环境里无所谓，生产环境就是很大的安全隐患。任何用户都可以修改这个文件，意味着如果服务器上跑着被攻破的Web服务，攻击者可以直接篡改你的脚本或配置。正确的思路是：按“谁需要什么权限”来最小化授权。比如文件属于下面运行的用户，那就chown指定专属用户，group只给需要协作的组，其他人一律不给写权限。

修改属主和属组用chown，最常用的是递归修改目录属主：

chown -R www:www /var/www/html

这条命令会把目录及目录下所有内容的属主改为www用户、www组。另外再提一个容易被忽略的场景：想给某个普通用户临时提权执行管理命令，并不是直接把用户加入sudoers就能完事，更安全的做法是visudo编辑配置文件，给特定用户或用户组授权特定命令。

visudo

然后在文件末尾加上：

ops ALL=(ALL) NOPASSWD: /usr/bin/systemctl

这样ops用户执行systemctl命令时不需要输密码，但也仅限这一条命令可用。用白名单方式控制sudo权限，既能满足日常运维操作需要，又不会把整个服务器置于风险中。

2.6 远程操作与容器集群：ssh、scp、docker、nginx、git一起来

这部分主要面向实际开发和部署场景。远程登录Linux服务器，最常用的就是ssh。记住一个实用参数**-p指定端口，-i**指定私钥文件。比如：

ssh -i ~/.ssh/id_rsa -p 22022 root@8.8.8.8

传文件用scp，语法和cp差不多，区别在于要写远程主机地址。把本地代码推到服务器：

scp -P 22022 -r ./web root@8.8.8.8:/opt/www

注意scp指定端口是大写**-P**，ssh指定端口是小写**-p**，这个大小写坑过我两回。另外如果文件特别多，或者要做增量同步，优先用rsync，它的断点续传和增量传输能力比scp强太多：

rsync -avz --progress -e "ssh -p 22022" ./web root@8.8.8.8:/opt/www

再说容器环境。Docker的常用命令其实就十几个，核心是“镜像-容器-网络-数据卷”四个维度。拉镜像、跑容器、看状态、看日志、进容器，这五个动作覆盖了八成的日常操作：

docker pull nginx:latest docker run -d --name web -p 8080:80 nginx docker ps -a docker logs -f --tail 100 web docker exec -it web bash

卷和网络方向，docker volume和docker network的常用子命令其实也不复杂，关键是理解“容器是不稳定的”这个理念——容器随时可能删除重建，因此有状态的数据必须放到volume或挂载目录里，否则一删容器数据全没。我再补一句：线上排查容器问题时，别一上来就进容器，先看docker logs，再docker inspect查配置，最后才考虑进容器操作。

Kubernetes相关命令，kubectl是核心。部署应用、看pod状态、看日志、进pod调试，这几个场景的常用命令：

kubectl apply -f deployment.yaml kubectl get pods -n my-namespace kubectl logs -f --tail 50 pod-name -n my-namespace kubectl exec -it pod-name -n my-namespace -- bash

nginx是反向代理和Web服务里绕不开的组件。查配置、校验配置、平滑重启，这三个动作一定要熟练：

nginx -t # 校验配置语法 nginx -s reload # 平滑加载新配置 systemctl status nginx # 查看服务状态

关于git，虽然很多人GUI用得多，但命令行依然是最高效的方式。日常提交、分支切换、远程推送这些动作背后，建议把git status、git add -p、git commit --amend、git rebase -i、git log --oneline --graph这几条高阶用法用熟，配合编辑器插件能极大提升日常开发效率。

3. 如何把笔记变成“随手可搜”的个人工具库

3.1 给自己的笔记搭一个目录树

笔记记得再全，如果检索不方便，价值直接减半。我的目录结构大致是这样的：

linux-notes/ ├── 01-文件与目录.md ├── 02-文本处理三剑客.md ├── 03-用户与权限.md ├── 04-磁盘与内存.md ├── 05-进程与systemd.md ├── 06-网络排查.md ├── 07-软件包管理.md ├── 08-远程登录与文件传输.md ├── 09-shell脚本与正则.md ├── 10-docker与集群命令.md └── README.md

README.md里写的是“场景速查索引”，比如“服务器CPU高怎么查”、“磁盘满了怎么清理”、“怎么快速看端口被谁占用”这样的常见问题，每个问题对应到某个md文件的具体小节。平时有新的心得就往对应文件里补充，始终保证笔记是“活”的。

工具层面，我用的是VS Code加Markdown插件。Windows和macOS都可以免费使用，配合Markdown All in One插件可以生成目录、快速折叠，搜索也很流畅。如果更追求极客风格，也可以用Obsidian，双链和标签功能确实方便，但个人感觉维护成本略高。

3.2 把常用命令做成alias和函数，让笔记“环境化”

笔记的价值不只是用来“看”，还可以变成“环境”。我习惯把非常高频的命令配置成alias，写进~/.bashrc或~/.zshrc里，这样每次打开终端直接就生效。比如我自己一直在用的几个：

alias ll='ls -alF' alias la='ls -A' alias grep='grep --color=auto' alias tf='tail -f' alias ..='cd ..' alias ...='cd ../..'

稍微复杂一点的用法，可以用函数封装。比如一条命令快速查看最近改动过的文件：

recent() { ls -lt "$1" | head -10 }

再比如一条命令快速杀掉占用某个端口的进程：

killport() { lsof -i :"$1" | awk 'NR==1{next}{print $2}' | xargs kill -9 }

这样配置好之后，实际使用时就不需要打开笔记查命令了，终端本身就是“活索引”。但这要求平时把命令反复用熟，配置alias只是把最常用的动作压缩成肌肉记忆。

3.3 让man、--help和笔记互为补充

笔记没法覆盖所有命令的每一个参数，遇到不认识的命令或参数，最好的老师其实就在系统里。man是manual的缩写，里面是完整的命令文档；--help是多数命令自带的简要帮助；在bash里输入命令名再按两下Tab，还能自动补全所有可执行文件。

我个人查命令遵循一个优先级：先用**--help快速扫一眼常用参数，不够用再开man**，最后才去翻笔记。笔记的价值是把“最容易出错的点”和“日常最高频的参数”标注出来，而不是让你背全部内容。比如清屏命令clear，man文档有一大堆说明，但我只需要记住“Ctrl+L”这个快捷键就够了。

3.4 用cheatsheet模板做“一页速查”

针对特别高频的命令，我还做了一个“一页速查”的习惯。比如tar命令各种格式的压缩和解压参数经常记混，就单独建一页tar速查：

打包不压缩： tar cvf archive.tar dir/ 解包： tar xvf archive.tar 打包并压缩： tar czvf archive.tar.gz dir/ 解压tar.gz： tar xzvf archive.tar.gz 解压tar.bz2： tar xjvf archive.tar.bz2 解压tar.xz： tar xJvf archive.tar.xz

这类速查页不求全面，只求“看到就能想起”。我在每页顶部都写清楚“适用场景”和“最容易踩的坑”，这样复习成本极低。以后看到同事在命令行里反复翻历史记录，我直接把速查表发过去，特别省时。

4. 常见问题与排查技巧实录

4.1 解压zip文件中文乱码，怎么办

这个问题在搜索热词里也出现过。Linux下用unzip解压Windows环境打出来的zip包，中文文件名经常变成乱码，根源是压缩包里的文件名编码是GBK，而系统默认用的是UTF-8。

常规的unzip没有编码转换功能，最常见的方式是安装unar，它能自动识别编码并转换：

unar 中文名.zip

如果是老系统没有unar，也可以用convmv做批量转换，但整体流程麻烦很多。这几年新版本的zip也逐步改进了文件名编码处理，但最稳妥的还是安装unar，一行命令全搞定。

4.2 文件明明存在，find却查不到

这个坑我踩过好几次。如果是刚创建的文件，但find不到，先确认文件所在目录是否包含在搜索路径里，再确认find的匹配条件没写错。如果文件在/root下，用**find / -name "xxx"**搜索，会因为没有权限遍历某些目录而报错，把关键信息淹没在错误流里。这时候要养成习惯，在find命令后面重定向错误信息：

find / -name "app.conf" 2>/dev/null

把错误信息丢进/dev/null，剩下显示的就是真正匹配到的结果。另外如果确认文件名没拼错但一直找不到，可以用locate试试，前提是系统安装并更新了数据库：

updatedb locate app.conf

不过也别忘了再检查一下是不是有软链接或路径跳转问题，比如你的实际文件在一个软链接目录里，find默认搜索时不跟随软链接，也会导致查不到结果。

4.3 命令提示“command not found”，但工具确实装了

这种情况通常不是文件丢了，而是PATH环境变量里没包含可执行文件所在目录。刚安装某些软件时，安装目录没有被自动加到PATH里，就会出现“装了但敲不了命令”的情况。可以用which或find先定位可执行文件到底在哪：

which java find /usr -name java -type f 2>/dev/null

确认路径后，把目录加入到PATH。临时生效可以直接执行：

export PATH=$PATH:/usr/local/java/bin

永久生效就写到~/.bashrc或/etc/profile里，之后source一下。需要说明的是，修改PATH要谨慎，不要覆盖原有内容，用**$PATH**把原路径拼回来是最安全的做法。

4.4 端口被占、网络不通，按什么顺序排查

网络排查是有套路的，别一上来就乱试。我自己的固定流程是：

第一，确认服务有没有起。ps -ef | grep 服务名，或者systemctl status 服务名，先确保进程存在。

第二，确认端口有没有监听。ss -lntp | grep 端口号，如果端口没在LISTEN状态，说明服务可能没监听或配置文件里的端口和命令行参数不一致。

第三，本机访问一下测试。比如是HTTP服务，就curl -v http://127.0.0.1:8080，如果本机都不通，问题出在服务配置层面；本机通而外网不通，就要看看防火墙和云平台安全组。

第四，检查防火墙。常见的是firewalld和iptables：

systemctl status firewalld iptables -L -n

如果防火墙是开着的，考虑放行对应端口，或者临时关闭测试（生产环境慎用）。

第五，远程不通的问题，可以同时考虑目标机器的网络状态和中间链路。ping测连通性，telnet 目标IP 端口测端口可达性，traceroute看路由中间是否有丢包。这一套流程走下来，百分之八九十的网络问题都能定位出来。

4.5 服务器CPU飙升，怎么快速定位元凶

排查CPU问题，我用的是“三步法”。先top按大写P键让进程按CPU使用率排序，找到异常高CPU的进程PID。再用ps看这个进程的具体信息：

ps -fp PID

如果进程是Java应用，还要进一步用jstack导出线程栈，看看每个CPU占用高的线程在干什么：

jstack PID > thread_dump.txt

用top -H -p PID查看该进程内各线程的CPU占比，再把线程ID转成十六进制：

printf "%x\n" 线程ID

在thread_dump.txt里搜这个十六进制线程ID，就能定位到出问题的代码段。这套流程对Java服务特别有效。如果是Python或其他脚本，用py-spy dump --pid PID这类工具也能拿到调用栈。总之排查CPU问题不能只盯着“哪个进程”，一定要细化到“进程里哪个线程、线程里哪段代码”，才能对症处理。

4.6 日志刷得太快，怎么优雅地查看

用tail看日志，最怕日志量太大，几秒钟就刷出新的一屏。这个时候tail -f会很难受。我一般配合grep过滤来用，比如只关心ERROR级别的日志：

tail -f app.log | grep --line-buffered "ERROR"

--line-buffered参数很关键，保证grep的输出是逐行实时输出的，否则在管道场景下可能出现延迟。另一种情况是日志文件特别大，用less打开再按Shift + F也能实现类似tail -f的效果，同时还能随时Ctrl + C停下来搜索。less管理大文件比tail -f更优雅，因为可以前后翻页、搜索关键词、标记位置，排查历史日志时优势更明显。

5. 一份能坚持下来的Linux学习路径

说回学习本身。很多人问过我怎么把一份两万字的笔记真正消化掉，我的答案其实很简单：把命令用到真实场景里，而不是停留在“看”和“记”上。

如果你现在还是新手，我建议按照这个节奏来走：

第一，先搭一个虚拟环境，无论是本机装个虚拟机还是云服务器都可以。第二，把那份笔记当字典用，不要从第一页读到最后一页，而是遇到什么问题、查什么问题。第三，每学一条命令，就找一个实际的使用情境把它用进去。比如学完find，就把服务器上查找旧日志的任务派给它；学完awk，就用它统计一下访问日志里的IP分布。这样命令不是背出来的，而是“用”出来的。

踩过几次坑之后我的体会是，Linux命令学习的真正门槛不在命令本身，而在“有没有解决问题的真实需求”。只要你在真实需求里反复调它、用烂它，那些参数和用法自然就长在脑子里了。第一回用sed改错文件、第一次find把整个系统扫得卡顿、第一次rm删掉重要文件这些惨痛教训，其实比任何笔记都更能让你记住——但前提是你得动手去操作，去犯错，再从错误里捞经验。

到最后你会发现，那份两万字笔记真正的价值已经不是“记忆库”，而是一个“索引系统”。你不再需要背下来所有东西，而是知道什么场景该去哪里查找、哪些命令组合能解决什么问题。这种检索能力和解决问题的能力，才是Linux学习最核心的收获。