简介这是一份系统梳理Linux命令行知识的PDF文档定位为Linux入门与进阶的常备速查手册。文档按模块展开覆盖了文件基础指令mkdir、cd、ls、cp、mv、rm、touch、vim等、进阶文本处理find、grep、sed、awk以及ssh、rpm、cron、netstat等系统管理命令同时包含vim编辑器三种模式、Linux运行级别、用户与权限管理、网络配置、shell入门与运算符、MySQL数据库系统架构等内容。全篇对Linux目录结构bin、dev、etc、home、proc、sbin、tmp、usr、var、mnt也做了清晰说明每个模块给出命令语法与典型示例适合从零开始学习命令操作的读者也便于有经验者按模块快速查阅。读者可以按章节定位所需命令在文件管理、文本处理、系统运维等常见场景中直接对照使用。资源包内仅含一个PDF文件大小约170KB目前已有1634人学习浏览。整体篇幅适中、结构清晰是一份适合边学边查的Linux命令行参考资料。1. 为什么你需要一份属于自己的“分模块”linux命令行大全“linux命令行大全”这类资料在网上一搜一大把但多数人下载之后翻几页就放回收藏夹了。问题不在资料本身而在于它是一份“别人的大全”分类是别人的工作流的命令是别人觉得常用的你很难在着急时快速定位。真正值得投入的是把它变成自己的手册——按你实际用的服务器、你常写的脚本、你的项目目录结构去重新分模块再配一套自己随时能查的索引。这份手册不用覆盖上万条命令但每一页都得经得起真实环境验证你知道它在哪台机器上能用、什么参数会踩坑、输出格式大概什么样。这篇文章适合三类人被“命令记不住”反复折磨的开发、运维想系统化重建命令行知识的学生以及总在翻聊天记录找历史命令的“CtrlR重病患者”。我会按从零搭手册、抓高频模块、整理成PDF、踩坑排查的顺序给你一套可以直接照抄的做法。2. 把命令大全当工程来做先定模块再动手2.1 分模块的价值从“收藏夹”到“可检索手册”记命令的痛点不是记不住单词而是“不知道这个场景该查什么”。grep、find、ps、awk 每个单独拿出来都认识但当你面对“日志文件越来越大想找出今天报错最多的前十个接口”大脑常常一片空白。原因在于你把命令当成了零散单词记住却没有把它们绑定到“解决问题的动作链”上。分模块恰恰是解决这个问题一个模块等于一类高频任务模块里的命令按照排查顺序排列。比如“文本处理”模块里我不会只列 grep 的单条用法而是写“从日志提取今天所有 ERROR”下面跟着grep 2025-01-20 app.log | grep ERROR。这样的组织方式更接近真实使用习惯回忆成本大幅降低。我一般在建模块时遵循三个原则。第一按“要解决的场景”分不按命令首字母分否则只是换了个排序方式的词典第二每个模块顶部放“速查清单”列出最常用的三五个组合命令第三每个命令下面至少写一行真实运行过的输出样例哪怕只是简化版这能让回看时更快建立记忆锚点。2.2 确定模块边界一份可复用的命令分类表下面的表是我常用的“地基”需要时可在此基础上增删。重要的是选定之后不要轻易大改因为索引和后续脚本都会依赖这个目录结构。模块名解决的问题代表性命令/组合备注建议文件与目录查找、复制、移动、备份ls/find/cp/rsync/tar/du所有命令都经真实环境验证文本处理日志清洗、提取、统计grep/sed/awk/sort/uniq大文件性能单独备注进程与资源定位CPU内存异常、端口占用ps/top/ss/free新老命令差异要写权限与用户文件和目录权限、账号协作chmod/chown/useradd/getfacl记录一次真实事故网络与排查连通性、DNS、连接状态ping/curl/ss/digtcpdump 常用参数单列磁盘与文件系统空间不足、inode 耗尽df/iostat/lsblk/mount存储设备单独开表软件安装各发行版包管理apt/yum/dnf/rpm注明平台差异系统与服务内核参数、systemd、定时任务journalctl/systemctl/crontab配置备份习惯选这些模块的理由是它们能覆盖日常工作中九成以上的运维操作。注意模块之间的边界比如“网络”里的 ss我也会在“进程与资源”里提一句因为排查端口占用时两者缺一不可。不要害怕命令重复出现在多个模块关键是每个位置的服务目标不同——在“进程与资源”里 ss 的作用是“查谁占着端口”在“网络”里 ss 的作用是“看监听状态与连接数”。2.3 创建手册骨架用命令搭建自己的命令大全仓库选定模块后我用一段命令初始化整个目录结构和 Git 仓库确保后续每次修改都有迹可循。以下是我的脚手架mkdir -p ~/linux-manual/commands # 创建主目录和命令模块目录 mkdir -p ~/linux-manual/cheatsheet # 速查表单独存放 cd ~/linux-manual git init # 初始化版本管理 git config user.email meexample.local # 避免后续 commit 报错按需修改 # 为每个模块创建空的 md 文件文件名用数字前缀保证稳定排序 for i in 01_files 02_text 03_process 04_perm 05_network 06_disk 07_pkg 08_system; do touch commands/$i.md echo # $i commands/$i.md done ls -R ~/linux-manual # 查看骨架结构这段代码做到了三件事。目录用“数字前缀 英文短名”命名排序稳定、路径好敲每个模块文件先写入一个标题行后面整理时直接往对应文件追加不用频繁建文件Git 从第一天就接管版本管理哪一天你改坏了一条命令git diff能帮你立刻找到改动点。后续我按“速查清单、核心命令、参数表、实际样例、坑记录”五段式更新每个模块文件。参数表只收录实际会改的参数别把 man 手册搬进来。这样手册体积一直可控而且当你需要分享给同事时这个目录本身就是一份结构化文档。每次更新完一个模块执行git add . git commit -m update text module形成版本记录这是随时能回滚的“后悔药”。3. 高频模块逐个击破文本、进程、权限与网络3.1 文本处理把grep/sed/awk按场景组合起来文本处理是命令行日常里最值得先攻下的模块。我见过不少同事把 grep、awk、sed 分别背得很熟可每次拿到新日志还是先打开脚本语言去处理速度慢不说排查问题时还不能在终端里反复试探。常见做法是先用一条管道组合快速观察确认逻辑后再固化到脚本里。下面是一个典型的“日志 Top N”场景从 application.log 里找出今天出现次数最多的前 5 个报错关键字。一次就能拿到结果grep 2025-01-20 application.log | # 先按日期圈定当天的日志 grep -oE ERROR\|[A-Z_] | # 只抽出“ERROR|模块名”这种格式 sort | # 相同内容聚到一起 uniq -c | # 统计每个内容出现次数 sort -rn | # 按次数从大到小排 head -5 # 取前5行几个参数容易被忽略。grep 的-o只输出匹配到的部分-E把正则当成扩展正则否则很多范围表达式要写一长串转义sort后面的-rn分别指“按数值排序、逆序”少一个-n会得到按字典序排出的“10小于9”这种结果head -5表示只取前五条数量可调。这条管道跑完后如果再想查某个具体报错的上下文把最后两段换成grep -C 5 具体报错就能看到前后五行。另一个高频率用法是清洗文件。比如把配置文件里的注释行和空行剥掉看有效配置grep -vE ^\s*#|^\s*$ /etc/nginx/nginx.conf # -v 反向过滤#开头和空行都去掉 sed -i s#listen 80#listen 8080#g /etc/nginx/nginx.conf # 用#代替/避免路径转义地狱 awk {print $1, $NF} access.log # 只取第一列和最后一列$NF 表示最后字段我平时习惯先少量试跑先跑 grep 看几行输出确认匹配正确再叠加后面的排序和统计。如果中间某一步输出为空立刻回退检查上一步而不是一次性写完整个管道。很多“组合命令没输出”的玄学最后都会发现是某个正则表达式里的转义没写对。3.2 进程与资源诊断“哪个进程把我机器打满了”进程和资源排查是服务器出问题时最紧张的场景不建议在这种状态下翻书找参数。所以这一节的目标是形成“肌肉记忆”顺序先用一条命令拿到全局视图再逐层缩小范围最后精确到进程。下面是我编译的一键初步诊断脚本保存在~/linux-manual/cheatsheet/diag.sh里#!/usr/bin/env bash echo 系统负载与运行时长 uptime # 1、5、15分钟负载 echo CPU与内存TOP top -bn1 | head -20 # 非交互模式跑一次抓前20行 echo CPU占用TOP5进程 ps aux --sort-%cpu | head -6 # 第一行是表头底下五行才是进程 echo 内存占用TOP5进程 ps aux --sort-%mem | head -6 echo 端口监听与连接 ss -tlnp # 查看监听端口和对应进程 echo 磁盘剩余与INODE df -hT df -i每个命令都在回答一个具体问题。uptime先确认负载数字和运行时长判断是瞬时抖动还是持续高压top用-b非交互模式配合-n1只采样一次避免在脚本里进入交互界面ps aux里的--sort-%cpu减号表示降序配合head抓出最占资源的进程。端口部分用ss而不是老旧的netstat因为新版发行版默认不再预装 net-tools-tlnp分别表示只显示 TCP、监听态、带数字端口、显示进程名。拿到端口和 PID 之后继续追查进程细节ss -tlnp | grep :8080 # 找到占用8080端口的进程 ps -p 12345 -o pid,cmd,%cpu,%mem # 按PID查看完整命令和资源占用 lsof -i :8080 # 如果没有lsof用上面的组合代替真正排查时先看端口占有情况比直接翻进程列表更准。同一程序可能起了多个实例只有结合端口才能定位到实际提供服务的那一个。脚本里再用free -h关注 Swap 是否告警如果 Swap 占用很高说明内存已经吃紧iostat -x 1 2可以进一步看磁盘繁忙度判断是磁盘瓶颈还是应用层问题。3.3 权限与用户别再用777偷懒权限命令看着简单实际是事故高发区。最常见的翻车姿势网站跑起来说没有写权限有人直接chmod -R 777项目目录当时确实不报错了但后来被扫描器发现目录也能写一挂就是大事故。权限设计的基本思路是“目录和文件分开处理”。我一般用下面的脚本组织项目权限# 项目目录结构已经存在先统一收紧基本权限 chown -R www:www /var/www/proj # 把项目整体交给运行账号 find /var/www/proj -type d -exec chmod 755 {} \; # 目录给755可穿越可读 find /var/www/proj -type f -exec chmod 644 {} \; # 文件给644只读 # 单独放开可写目录例如日志和上传目录 chmod -R 770 /var/www/proj/logs chmod -R 770 /var/www/proj/uploads # 需要临时账号协作时用ACL替代递归改属主 setfacl -m u:dev01:rwx /var/www/proj/logs getfacl /var/www/proj/logs思路是不追求“所有目录统一权限”而是让默认权限尽量收紧仅对明确需要写入的目录单独放宽。find配合-type d和-type f把目录与文件的默认权限分开设置避免目录加了执行位而文件也被加上——文件加执行位以后会有各种安全隐患。ACL 的价值在于不用修改属主就能给指定用户单独开权限适合同事临时协助的场景。再提一个我踩过的坑不要对系统目录做任何递归chown哪怕你觉得只是改一下自己创建的子目录。某次我想把某服务运行库的权限修对齐手滑少写了一级路径结果服务运行时依赖的权限全乱了最后只能重装对应软件。权限命令的正确姿势是先把目标精准到一个具体文件或目录确认生效后再考虑是否扩大范围。4. 把零散命令整理成“清晰全面”的PDF与检索体系4.1 选定承载格式Markdown 源码与本地转换的结合当你按第 2 章的骨架把命令一条条填进 md 文件后下一步是让“清晰全面”落地既要能在电脑上快速检索也要能生成一份排版统一、方便离线翻阅的 PDF。我不建议直接在一个巨大的 Word 或 PDF 文件里写命令手册因为后续增删、合并、对比改动都很难受。常见做法是“Markdown 作为唯一事实源PDF 作为报告产物”。下面是一个简单的 Makefile 脚本放在~/linux-manual根目录。它拼接多个模块文件按目录顺序合并出一份全集 Markdown再调用转换工具输出 PDFSOURCE $(shell find commands -name *.md | sort) OUT linux-command-manual.md PDF linux-command-manual.pdf all: pdf $(OUT): $(SOURCE) # 先写出主标题和目录占位 echo # Linux 命令行手册 $(OUT) echo $(OUT) # 逐个拼接模块文件并插入分页标记 for f in $(SOURCE); do \ echo $(OUT); \ echo \\newpage $(OUT); \ cat $$f $(OUT); \ done pdf: $(OUT) # 调用 Pandoc 风格的转换器把 Markdown 转成 PDF pandoc $(OUT) -o $(PDF) --toc --toc-depth2 index: bash scripts/build_index.sh clean: rm -f $(OUT) $(PDF) .PHONY: all pdf index clean这份 Makefile 的价值在“生成过程可重复”每整理完一个模块文件重新执行make pdf整本手册的 PDF 就会重新生成不会出现改了某个模块但打印件还是旧版的问题。$(OUT)里先写主标题再逐个文件拼接并插入\newpage每个模块在 PDF 里都从新一页开始翻起来比连续打印更清楚。pandoc那行的--toc让 PDF 首页自动带目录--toc-depth2把二级标题也收进去与模块和命令结构对应。如果不想安装转换工具也可以把同一份 Markdown 用浏览器打开直接打印成 PDF效果类似。坚持“直接维护 md 源文件”这个习惯后续无论分享还是离线阅读都能快速生成排版统一的手册。4.2 建立索引用命令本身来检索命令手册内容一多最难的就是找东西。有人用 CtrlF 在 PDF 里翻半天因为同一个命令经常出现在多个模块grep 出现在文本处理、也出现在日志排查直接搜会得到一大堆结果很难判断哪个才是当前要用的。常见解决方案是生成一份“命令索引”每条只写命令名、所属模块、一句话说明相当于精简版速查表。我用一个小脚本从所有模块里提取代码块中的第一个命令名集中生成索引文件scripts/build_index.sh#!/usr/bin/env bash OUTcheatsheet/command-index.md echo # 命令索引 $OUT echo $OUT echo | 命令 | 模块 | 用途 | $OUT echo | --- | --- | --- | $OUT # 遍历每个模块文件提取代码块首行命令与后面的中文简述 for f in commands/*.md; do mod$(basename $f .md) # awk: 捕获代码块第一次出现的行号记为code_start第二次记为code_end awk -v mod$mod /^/ { if (code_start 0) { code_start NR next } else { code_end NR # 取代码块内第一行非空文本作为命令 for (i code_start 1; i code_end; i) { if (lines[i] ! ) { cmd lines[i] break } } code_start 0 code_end 0 next } } { lines[NR] $0 } END { if (cmd ! ) { # 用途一般写在代码块后面的第一行 print | cmd | mod | desc | } } $f done $OUT echo 索引已生成: $OUT这段 awk 脚本逻辑略绕核心是用 行的出现次数来判断是否进入代码块单元第一次出现时把行号记下来第二次出现时取代码块范围内第一条非空内容作为命令名desc变量来自代码块后面紧跟的说明文本我通常控制在十个字以内。整体跑完后cat cheatsheet/command-index.md就能在终端里预览整本手册的命令地图。生成索引之后临时想不起来某个命令时先查索引文件而不是打开整本 PDF。比如grep 端口 command-index.md会直接看到 ss、lsof、fuser 相关命令再顺着模块号去翻对应文件。这个“用命令检索命令”的习惯比翻收藏夹快得多。4.3 站在网上海量清单的肩上但不要照单全收网上可以找到大量“linux命令行大全”类的 PDF、帖子或速查卡它们是好素材但不是好手册。我的建议是先把它们当成“查漏补缺的清单”而不是“可直接粘贴的最终答案”。具体操作上按第 2 章的模块表对照自己的日常操作列出已有内容再建一个“待验证命令”列表把从资料里看到但没用过的命令标注“未验证”等实际工作中触发了再把这个命令的真实用法和坑记录到对应模块。为什么不直接照搬因为别人的“大全”里充满环境依赖。某个命令在特定发行版才有、某个参数在老版本里含义不同、某条组合命令依赖你从未安装过的工具这些只有在自己服务器上真实跑过才知道。把命令从“见过”变成“用过”是手册从厚到薄又从薄到厚的过程筛选掉与你不相关的部分再把亲自验证过的内容补充回来。最终留下的手册体积可能只有别人的一半但每个条目的可靠性会高一个数量级。5. 命令手册翻车记5个常见坑与排查思路5.1 环境不一致在A机器能跑的命令到B机器就报错现象你把整理好的命令脚本从自己的服务器拷到另一台机器一执行就command not found或者语法错误明明命令看起来完全一样。最典型的翻车过程是脚本开头用了 bash 特性但机器默认 shell 是 sh或者命令所在路径没有配置在 PATH 里。原因首先是脚本解释器差异bash 里常见的[[ ]]、数组、$RANDOM在 sh 下可能直接报错其次是命令路径问题新机器可能没装对应软件或者安装路径不在标准 PATH 下。第三类是换行符问题Windows 下编辑过的脚本通常带\r在 Linux 上每一行都带着隐形字符shell 解析时直接抱怨$\r: command not found。解决写脚本时第一行固定#!/usr/bin/env bash而不是只写#!/bin/sh执行前用command -v和file快速检查命令是否存在、文件编码与换行是否异常。下面是一段环境自检脚本片段# 检查关键命令是否存在缺失时给出安装提示 for cmd in git jq curl; do if ! command -v $cmd /dev/null 21; then echo 缺少 $cmd fi done # 检查文件格式输出 CRLF 时说明存在 Windows 换行残留 file myscript.sh # 若有 CRLF用 sed 去掉行尾的回车符再运行 sed -i s/\r$// myscript.shcommand -v是“命令是否存在”的可靠检查方式比which更适合脚本中使用它是 POSIX 内置命令。file输出里出现 “CRLF line terminators” 就要小心了我第一次见这个提示完全摸不着头脑后来才知道是换行符问题。sed -i s/\r$//用正则删除每行末尾的回车符是快速修复办法但最好还是在编辑器里把换行统一改成 LF避免每次拷文件都出问题。5.2 老命令依赖症ifconfig 和 netstat 已经缺席现象你照着网上的老教程敲ifconfig提示command not found敲netstat -tlnp也提示没有这个命令。很多手册还在用这些命令导致你怀疑是不是系统没装全。原因新版发行版默认不再预装 net-tools 包ifconfig、netstat、route这些命令被ip、ss等 iproute2 工具取代。两类工具体系完全不同ifconfig只显示已配置接口而ip addr会把接口、地址、状态以层级方式完整输出。解决手册网络模块里写清楚新旧命令对照避免每次现查。对照关系如下旧命令新命令说明ifconfigip addr / ip link查看接口与IP地址ifconfig eth0 down/upip link set eth0 down/up启用或禁用接口netstat -tlnpss -tlnp查看TCP监听端口route -nip route查看路由表arp -aip neigh查看邻居解析表建议在新机器上优先掌握ip和ss旧命令能看懂输出即可不必花时间背参数。手册更新时把这条对照表放在网络模块最前面能少走很多弯路。5.3 权限chmod -R 777 带来的安全感错觉现象项目跑不起来日志目录写不进去你顺手chmod -R 777整个项目服务恢复正常了你也没再管它。直到某天同事告诉你网站被植入了一个可疑脚本。原因777 意味着所有用户对目录和文件拥有完全权限。对 Web 服务来说这意味着整站可以被任何本地账号、也可以被漏洞利用后的进程改写。权限事故大多是“当时的错误被表面的稳定掩盖”真正爆发时要付出更大代价。解决权限上没有后悔药。正确做法是回到 3.3 节的原则目录统一 755、普通文件 644只有明确需要写的目录单独放开 770并用 ACL 精确授权。修复方式如下把已经改坏的目录按“目录/文件分开”重新收紧find /var/www/proj -type d -exec chmod 755 {} \; find /var/www/proj -type f -exec chmod 644 {} \; chmod -R 770 /var/www/proj/logs ls -l /var/www/proj # 抽查确认结果如果目录树不小可以分模块执行避免权限命令长时间锁住生产读写。每次改完权限后用ls -l抽查几个关键文件不要只看服务能不能跑。5.4 中文日志乱码导致 grep 匹配不到任何内容现象日志文件里明明有“操作失败”四个字你用grep 失败去搜结果一条都搜不到但用less打开文件中文显示正常。原因大多数系统 grep 在处理非 UTF-8 编码文件时因为 locale 设置不一致或文件本身是 GBK 编码会把中文字节当成非法字符直接跳过。less能显示是因为它自己做了编码猜测而 grep 不会自动做这个转换。解决先查看文件真实编码再用iconv把内容转为 UTF-8 后检索。不改原文件直接用管道完成转换file app.log # 查看编码常见输出为 ISO-8859 或 GBK iconv -f GBK -t UTF-8 app.log | grep 失败 # 转换后再搜 export LC_ALLC.UTF-8 # 如果原文件已是 UTF-8但 grep 仍异常时使用如果文件是 UTF-8 但 locale 有问题可以显式export LC_ALLC.UTF-8再执行 grep。这个坑在网上下载的日志压缩包、老系统备份文件里非常常见遇到“明明有却搜不到”的情况优先怀疑编码。5.5 手册越攒越厚反而不好用现象你按网上的大全整理了自己的手册半年后积累了上千条命令但每次查找都要花很久最后又回到搜索引擎。越“全”越用不起来这是大多数人整理命令笔记的最终归宿。原因没有分层和索引地把所有内容塞进一个文件导致“全面的手册”变成“没有入口的仓库”。目录本身失去了导航意义你甚至不记得某个模块里放的是什么。解决给手册立规矩。第一层是“速查清单”每条最多十来个字反应“遇到什么场景用什么命令”第二层是“常用命令详解”只展开真实用过的命令第三层是“外部素材归档区”放网上看到、还没验证的命令统一标上“未验证”状态。每次要用命令时先查速查清单没有结果再进入第二层。同时结合第 4 章的自动索引脚本让命令检索从“翻目录”变成“输入关键词过滤”。整理到最后会发现把命令分为“每周必用”和“参考存证”两类就不再纠结于什么都要掌握了。6. 把手册变成自己的高频面板别名、函数与自检索到了这个阶段我对命令手册最大的期待不只是“能查到”而是“在被需要时直接跳到我面前”。我会把第 2 章的速查清单收进 shell 配置里用几个精心设计的函数把手册变成命令行里随时可以唤出的高频面板。# ~/.bashrc 或 ~/.zshrc 中加入以下内容 # 快速查看某个模块的速查表 qmod() { local mod${1:-files} # 默认查看文件模块 grep ^|.*| $mod | ~/linux-manual/cheatsheet/command-index.md 2/dev/null } # 查某个命令先看手册速查表再看本地man qman() { local cmd$1 echo 速查索引 grep -i ^| .*$cmd.*| ~/linux-manual/cheatsheet/command-index.md echo 手册详解 grep -rn $cmd ~/linux-manual/commands/ --include*.md | head -20 echo 系统手册前几行 man $cmd 2/dev/null | head -30 }qmod函数的作用是“按模块过滤索引行”快速看到某个模块下我已经记了哪些命令。qman函数把“检索索引、翻我在手册里的详解、看系统原版手册”三步合一让我只记得一个函数就能走完“确认命令是否可用、查看经验笔记、再看官方定义”的完整链路。这两个函数最大的价值不是省了几次输入而是把“搜索的过程”固化成一套固定动作思考负担小了很多。我还习惯在qman的输出末尾加一条“我踩过的坑”备注提示自己看命令时先扫一眼。比如中文乱码、新版工具替代旧命令、某些参数在不同发行版行为不一致都在备注里写十几二十个字下次再查时就不用重新踩一遍。回头看看这份手册的养成过程与其说我在整理命令大全不如说我在给自己建一套“命令行肌肉记忆的训练系统”。开始阶段花一晚上搭好骨架之后每周花十分钟补充一条真实用过的命令远比下载一份别人的大全放在收藏夹里更有意义。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/11 1:22:19 · 阅读 1.2k 打造属于自己的分模块Linux命令行手册：从命令到PDF
简介这是一份系统梳理Linux命令行知识的PDF文档定位为Linux入门与进阶的常备速查手册。文档按模块展开覆盖了文件基础指令mkdir、cd、ls、cp、mv、rm、touch、vim等、进阶文本处理find、grep、sed、awk以及ssh、rpm、cron、netstat等系统管理命令同时包含vim编辑器三种模式、Linux运行级别、用户与权限管理、网络配置、shell入门与运算符、MySQL数据库系统架构等内容。全篇对Linux目录结构bin、dev、etc、home、proc、sbin、tmp、usr、var、mnt也做了清晰说明每个模块给出命令语法与典型示例适合从零开始学习命令操作的读者也便于有经验者按模块快速查阅。读者可以按章节定位所需命令在文件管理、文本处理、系统运维等常见场景中直接对照使用。资源包内仅含一个PDF文件大小约170KB目前已有1634人学习浏览。整体篇幅适中、结构清晰是一份适合边学边查的Linux命令行参考资料。1. 为什么你需要一份属于自己的“分模块”linux命令行大全“linux命令行大全”这类资料在网上一搜一大把但多数人下载之后翻几页就放回收藏夹了。问题不在资料本身而在于它是一份“别人的大全”分类是别人的工作流的命令是别人觉得常用的你很难在着急时快速定位。真正值得投入的是把它变成自己的手册——按你实际用的服务器、你常写的脚本、你的项目目录结构去重新分模块再配一套自己随时能查的索引。这份手册不用覆盖上万条命令但每一页都得经得起真实环境验证你知道它在哪台机器上能用、什么参数会踩坑、输出格式大概什么样。这篇文章适合三类人被“命令记不住”反复折磨的开发、运维想系统化重建命令行知识的学生以及总在翻聊天记录找历史命令的“CtrlR重病患者”。我会按从零搭手册、抓高频模块、整理成PDF、踩坑排查的顺序给你一套可以直接照抄的做法。2. 把命令大全当工程来做先定模块再动手2.1 分模块的价值从“收藏夹”到“可检索手册”记命令的痛点不是记不住单词而是“不知道这个场景该查什么”。grep、find、ps、awk 每个单独拿出来都认识但当你面对“日志文件越来越大想找出今天报错最多的前十个接口”大脑常常一片空白。原因在于你把命令当成了零散单词记住却没有把它们绑定到“解决问题的动作链”上。分模块恰恰是解决这个问题一个模块等于一类高频任务模块里的命令按照排查顺序排列。比如“文本处理”模块里我不会只列 grep 的单条用法而是写“从日志提取今天所有 ERROR”下面跟着grep 2025-01-20 app.log | grep ERROR。这样的组织方式更接近真实使用习惯回忆成本大幅降低。我一般在建模块时遵循三个原则。第一按“要解决的场景”分不按命令首字母分否则只是换了个排序方式的词典第二每个模块顶部放“速查清单”列出最常用的三五个组合命令第三每个命令下面至少写一行真实运行过的输出样例哪怕只是简化版这能让回看时更快建立记忆锚点。2.2 确定模块边界一份可复用的命令分类表下面的表是我常用的“地基”需要时可在此基础上增删。重要的是选定之后不要轻易大改因为索引和后续脚本都会依赖这个目录结构。模块名解决的问题代表性命令/组合备注建议文件与目录查找、复制、移动、备份ls/find/cp/rsync/tar/du所有命令都经真实环境验证文本处理日志清洗、提取、统计grep/sed/awk/sort/uniq大文件性能单独备注进程与资源定位CPU内存异常、端口占用ps/top/ss/free新老命令差异要写权限与用户文件和目录权限、账号协作chmod/chown/useradd/getfacl记录一次真实事故网络与排查连通性、DNS、连接状态ping/curl/ss/digtcpdump 常用参数单列磁盘与文件系统空间不足、inode 耗尽df/iostat/lsblk/mount存储设备单独开表软件安装各发行版包管理apt/yum/dnf/rpm注明平台差异系统与服务内核参数、systemd、定时任务journalctl/systemctl/crontab配置备份习惯选这些模块的理由是它们能覆盖日常工作中九成以上的运维操作。注意模块之间的边界比如“网络”里的 ss我也会在“进程与资源”里提一句因为排查端口占用时两者缺一不可。不要害怕命令重复出现在多个模块关键是每个位置的服务目标不同——在“进程与资源”里 ss 的作用是“查谁占着端口”在“网络”里 ss 的作用是“看监听状态与连接数”。2.3 创建手册骨架用命令搭建自己的命令大全仓库选定模块后我用一段命令初始化整个目录结构和 Git 仓库确保后续每次修改都有迹可循。以下是我的脚手架mkdir -p ~/linux-manual/commands # 创建主目录和命令模块目录 mkdir -p ~/linux-manual/cheatsheet # 速查表单独存放 cd ~/linux-manual git init # 初始化版本管理 git config user.email meexample.local # 避免后续 commit 报错按需修改 # 为每个模块创建空的 md 文件文件名用数字前缀保证稳定排序 for i in 01_files 02_text 03_process 04_perm 05_network 06_disk 07_pkg 08_system; do touch commands/$i.md echo # $i commands/$i.md done ls -R ~/linux-manual # 查看骨架结构这段代码做到了三件事。目录用“数字前缀 英文短名”命名排序稳定、路径好敲每个模块文件先写入一个标题行后面整理时直接往对应文件追加不用频繁建文件Git 从第一天就接管版本管理哪一天你改坏了一条命令git diff能帮你立刻找到改动点。后续我按“速查清单、核心命令、参数表、实际样例、坑记录”五段式更新每个模块文件。参数表只收录实际会改的参数别把 man 手册搬进来。这样手册体积一直可控而且当你需要分享给同事时这个目录本身就是一份结构化文档。每次更新完一个模块执行git add . git commit -m update text module形成版本记录这是随时能回滚的“后悔药”。3. 高频模块逐个击破文本、进程、权限与网络3.1 文本处理把grep/sed/awk按场景组合起来文本处理是命令行日常里最值得先攻下的模块。我见过不少同事把 grep、awk、sed 分别背得很熟可每次拿到新日志还是先打开脚本语言去处理速度慢不说排查问题时还不能在终端里反复试探。常见做法是先用一条管道组合快速观察确认逻辑后再固化到脚本里。下面是一个典型的“日志 Top N”场景从 application.log 里找出今天出现次数最多的前 5 个报错关键字。一次就能拿到结果grep 2025-01-20 application.log | # 先按日期圈定当天的日志 grep -oE ERROR\|[A-Z_] | # 只抽出“ERROR|模块名”这种格式 sort | # 相同内容聚到一起 uniq -c | # 统计每个内容出现次数 sort -rn | # 按次数从大到小排 head -5 # 取前5行几个参数容易被忽略。grep 的-o只输出匹配到的部分-E把正则当成扩展正则否则很多范围表达式要写一长串转义sort后面的-rn分别指“按数值排序、逆序”少一个-n会得到按字典序排出的“10小于9”这种结果head -5表示只取前五条数量可调。这条管道跑完后如果再想查某个具体报错的上下文把最后两段换成grep -C 5 具体报错就能看到前后五行。另一个高频率用法是清洗文件。比如把配置文件里的注释行和空行剥掉看有效配置grep -vE ^\s*#|^\s*$ /etc/nginx/nginx.conf # -v 反向过滤#开头和空行都去掉 sed -i s#listen 80#listen 8080#g /etc/nginx/nginx.conf # 用#代替/避免路径转义地狱 awk {print $1, $NF} access.log # 只取第一列和最后一列$NF 表示最后字段我平时习惯先少量试跑先跑 grep 看几行输出确认匹配正确再叠加后面的排序和统计。如果中间某一步输出为空立刻回退检查上一步而不是一次性写完整个管道。很多“组合命令没输出”的玄学最后都会发现是某个正则表达式里的转义没写对。3.2 进程与资源诊断“哪个进程把我机器打满了”进程和资源排查是服务器出问题时最紧张的场景不建议在这种状态下翻书找参数。所以这一节的目标是形成“肌肉记忆”顺序先用一条命令拿到全局视图再逐层缩小范围最后精确到进程。下面是我编译的一键初步诊断脚本保存在~/linux-manual/cheatsheet/diag.sh里#!/usr/bin/env bash echo 系统负载与运行时长 uptime # 1、5、15分钟负载 echo CPU与内存TOP top -bn1 | head -20 # 非交互模式跑一次抓前20行 echo CPU占用TOP5进程 ps aux --sort-%cpu | head -6 # 第一行是表头底下五行才是进程 echo 内存占用TOP5进程 ps aux --sort-%mem | head -6 echo 端口监听与连接 ss -tlnp # 查看监听端口和对应进程 echo 磁盘剩余与INODE df -hT df -i每个命令都在回答一个具体问题。uptime先确认负载数字和运行时长判断是瞬时抖动还是持续高压top用-b非交互模式配合-n1只采样一次避免在脚本里进入交互界面ps aux里的--sort-%cpu减号表示降序配合head抓出最占资源的进程。端口部分用ss而不是老旧的netstat因为新版发行版默认不再预装 net-tools-tlnp分别表示只显示 TCP、监听态、带数字端口、显示进程名。拿到端口和 PID 之后继续追查进程细节ss -tlnp | grep :8080 # 找到占用8080端口的进程 ps -p 12345 -o pid,cmd,%cpu,%mem # 按PID查看完整命令和资源占用 lsof -i :8080 # 如果没有lsof用上面的组合代替真正排查时先看端口占有情况比直接翻进程列表更准。同一程序可能起了多个实例只有结合端口才能定位到实际提供服务的那一个。脚本里再用free -h关注 Swap 是否告警如果 Swap 占用很高说明内存已经吃紧iostat -x 1 2可以进一步看磁盘繁忙度判断是磁盘瓶颈还是应用层问题。3.3 权限与用户别再用777偷懒权限命令看着简单实际是事故高发区。最常见的翻车姿势网站跑起来说没有写权限有人直接chmod -R 777项目目录当时确实不报错了但后来被扫描器发现目录也能写一挂就是大事故。权限设计的基本思路是“目录和文件分开处理”。我一般用下面的脚本组织项目权限# 项目目录结构已经存在先统一收紧基本权限 chown -R www:www /var/www/proj # 把项目整体交给运行账号 find /var/www/proj -type d -exec chmod 755 {} \; # 目录给755可穿越可读 find /var/www/proj -type f -exec chmod 644 {} \; # 文件给644只读 # 单独放开可写目录例如日志和上传目录 chmod -R 770 /var/www/proj/logs chmod -R 770 /var/www/proj/uploads # 需要临时账号协作时用ACL替代递归改属主 setfacl -m u:dev01:rwx /var/www/proj/logs getfacl /var/www/proj/logs思路是不追求“所有目录统一权限”而是让默认权限尽量收紧仅对明确需要写入的目录单独放宽。find配合-type d和-type f把目录与文件的默认权限分开设置避免目录加了执行位而文件也被加上——文件加执行位以后会有各种安全隐患。ACL 的价值在于不用修改属主就能给指定用户单独开权限适合同事临时协助的场景。再提一个我踩过的坑不要对系统目录做任何递归chown哪怕你觉得只是改一下自己创建的子目录。某次我想把某服务运行库的权限修对齐手滑少写了一级路径结果服务运行时依赖的权限全乱了最后只能重装对应软件。权限命令的正确姿势是先把目标精准到一个具体文件或目录确认生效后再考虑是否扩大范围。4. 把零散命令整理成“清晰全面”的PDF与检索体系4.1 选定承载格式Markdown 源码与本地转换的结合当你按第 2 章的骨架把命令一条条填进 md 文件后下一步是让“清晰全面”落地既要能在电脑上快速检索也要能生成一份排版统一、方便离线翻阅的 PDF。我不建议直接在一个巨大的 Word 或 PDF 文件里写命令手册因为后续增删、合并、对比改动都很难受。常见做法是“Markdown 作为唯一事实源PDF 作为报告产物”。下面是一个简单的 Makefile 脚本放在~/linux-manual根目录。它拼接多个模块文件按目录顺序合并出一份全集 Markdown再调用转换工具输出 PDFSOURCE $(shell find commands -name *.md | sort) OUT linux-command-manual.md PDF linux-command-manual.pdf all: pdf $(OUT): $(SOURCE) # 先写出主标题和目录占位 echo # Linux 命令行手册 $(OUT) echo $(OUT) # 逐个拼接模块文件并插入分页标记 for f in $(SOURCE); do \ echo $(OUT); \ echo \\newpage $(OUT); \ cat $$f $(OUT); \ done pdf: $(OUT) # 调用 Pandoc 风格的转换器把 Markdown 转成 PDF pandoc $(OUT) -o $(PDF) --toc --toc-depth2 index: bash scripts/build_index.sh clean: rm -f $(OUT) $(PDF) .PHONY: all pdf index clean这份 Makefile 的价值在“生成过程可重复”每整理完一个模块文件重新执行make pdf整本手册的 PDF 就会重新生成不会出现改了某个模块但打印件还是旧版的问题。$(OUT)里先写主标题再逐个文件拼接并插入\newpage每个模块在 PDF 里都从新一页开始翻起来比连续打印更清楚。pandoc那行的--toc让 PDF 首页自动带目录--toc-depth2把二级标题也收进去与模块和命令结构对应。如果不想安装转换工具也可以把同一份 Markdown 用浏览器打开直接打印成 PDF效果类似。坚持“直接维护 md 源文件”这个习惯后续无论分享还是离线阅读都能快速生成排版统一的手册。4.2 建立索引用命令本身来检索命令手册内容一多最难的就是找东西。有人用 CtrlF 在 PDF 里翻半天因为同一个命令经常出现在多个模块grep 出现在文本处理、也出现在日志排查直接搜会得到一大堆结果很难判断哪个才是当前要用的。常见解决方案是生成一份“命令索引”每条只写命令名、所属模块、一句话说明相当于精简版速查表。我用一个小脚本从所有模块里提取代码块中的第一个命令名集中生成索引文件scripts/build_index.sh#!/usr/bin/env bash OUTcheatsheet/command-index.md echo # 命令索引 $OUT echo $OUT echo | 命令 | 模块 | 用途 | $OUT echo | --- | --- | --- | $OUT # 遍历每个模块文件提取代码块首行命令与后面的中文简述 for f in commands/*.md; do mod$(basename $f .md) # awk: 捕获代码块第一次出现的行号记为code_start第二次记为code_end awk -v mod$mod /^/ { if (code_start 0) { code_start NR next } else { code_end NR # 取代码块内第一行非空文本作为命令 for (i code_start 1; i code_end; i) { if (lines[i] ! ) { cmd lines[i] break } } code_start 0 code_end 0 next } } { lines[NR] $0 } END { if (cmd ! ) { # 用途一般写在代码块后面的第一行 print | cmd | mod | desc | } } $f done $OUT echo 索引已生成: $OUT这段 awk 脚本逻辑略绕核心是用 行的出现次数来判断是否进入代码块单元第一次出现时把行号记下来第二次出现时取代码块范围内第一条非空内容作为命令名desc变量来自代码块后面紧跟的说明文本我通常控制在十个字以内。整体跑完后cat cheatsheet/command-index.md就能在终端里预览整本手册的命令地图。生成索引之后临时想不起来某个命令时先查索引文件而不是打开整本 PDF。比如grep 端口 command-index.md会直接看到 ss、lsof、fuser 相关命令再顺着模块号去翻对应文件。这个“用命令检索命令”的习惯比翻收藏夹快得多。4.3 站在网上海量清单的肩上但不要照单全收网上可以找到大量“linux命令行大全”类的 PDF、帖子或速查卡它们是好素材但不是好手册。我的建议是先把它们当成“查漏补缺的清单”而不是“可直接粘贴的最终答案”。具体操作上按第 2 章的模块表对照自己的日常操作列出已有内容再建一个“待验证命令”列表把从资料里看到但没用过的命令标注“未验证”等实际工作中触发了再把这个命令的真实用法和坑记录到对应模块。为什么不直接照搬因为别人的“大全”里充满环境依赖。某个命令在特定发行版才有、某个参数在老版本里含义不同、某条组合命令依赖你从未安装过的工具这些只有在自己服务器上真实跑过才知道。把命令从“见过”变成“用过”是手册从厚到薄又从薄到厚的过程筛选掉与你不相关的部分再把亲自验证过的内容补充回来。最终留下的手册体积可能只有别人的一半但每个条目的可靠性会高一个数量级。5. 命令手册翻车记5个常见坑与排查思路5.1 环境不一致在A机器能跑的命令到B机器就报错现象你把整理好的命令脚本从自己的服务器拷到另一台机器一执行就command not found或者语法错误明明命令看起来完全一样。最典型的翻车过程是脚本开头用了 bash 特性但机器默认 shell 是 sh或者命令所在路径没有配置在 PATH 里。原因首先是脚本解释器差异bash 里常见的[[ ]]、数组、$RANDOM在 sh 下可能直接报错其次是命令路径问题新机器可能没装对应软件或者安装路径不在标准 PATH 下。第三类是换行符问题Windows 下编辑过的脚本通常带\r在 Linux 上每一行都带着隐形字符shell 解析时直接抱怨$\r: command not found。解决写脚本时第一行固定#!/usr/bin/env bash而不是只写#!/bin/sh执行前用command -v和file快速检查命令是否存在、文件编码与换行是否异常。下面是一段环境自检脚本片段# 检查关键命令是否存在缺失时给出安装提示 for cmd in git jq curl; do if ! command -v $cmd /dev/null 21; then echo 缺少 $cmd fi done # 检查文件格式输出 CRLF 时说明存在 Windows 换行残留 file myscript.sh # 若有 CRLF用 sed 去掉行尾的回车符再运行 sed -i s/\r$// myscript.shcommand -v是“命令是否存在”的可靠检查方式比which更适合脚本中使用它是 POSIX 内置命令。file输出里出现 “CRLF line terminators” 就要小心了我第一次见这个提示完全摸不着头脑后来才知道是换行符问题。sed -i s/\r$//用正则删除每行末尾的回车符是快速修复办法但最好还是在编辑器里把换行统一改成 LF避免每次拷文件都出问题。5.2 老命令依赖症ifconfig 和 netstat 已经缺席现象你照着网上的老教程敲ifconfig提示command not found敲netstat -tlnp也提示没有这个命令。很多手册还在用这些命令导致你怀疑是不是系统没装全。原因新版发行版默认不再预装 net-tools 包ifconfig、netstat、route这些命令被ip、ss等 iproute2 工具取代。两类工具体系完全不同ifconfig只显示已配置接口而ip addr会把接口、地址、状态以层级方式完整输出。解决手册网络模块里写清楚新旧命令对照避免每次现查。对照关系如下旧命令新命令说明ifconfigip addr / ip link查看接口与IP地址ifconfig eth0 down/upip link set eth0 down/up启用或禁用接口netstat -tlnpss -tlnp查看TCP监听端口route -nip route查看路由表arp -aip neigh查看邻居解析表建议在新机器上优先掌握ip和ss旧命令能看懂输出即可不必花时间背参数。手册更新时把这条对照表放在网络模块最前面能少走很多弯路。5.3 权限chmod -R 777 带来的安全感错觉现象项目跑不起来日志目录写不进去你顺手chmod -R 777整个项目服务恢复正常了你也没再管它。直到某天同事告诉你网站被植入了一个可疑脚本。原因777 意味着所有用户对目录和文件拥有完全权限。对 Web 服务来说这意味着整站可以被任何本地账号、也可以被漏洞利用后的进程改写。权限事故大多是“当时的错误被表面的稳定掩盖”真正爆发时要付出更大代价。解决权限上没有后悔药。正确做法是回到 3.3 节的原则目录统一 755、普通文件 644只有明确需要写的目录单独放开 770并用 ACL 精确授权。修复方式如下把已经改坏的目录按“目录/文件分开”重新收紧find /var/www/proj -type d -exec chmod 755 {} \; find /var/www/proj -type f -exec chmod 644 {} \; chmod -R 770 /var/www/proj/logs ls -l /var/www/proj # 抽查确认结果如果目录树不小可以分模块执行避免权限命令长时间锁住生产读写。每次改完权限后用ls -l抽查几个关键文件不要只看服务能不能跑。5.4 中文日志乱码导致 grep 匹配不到任何内容现象日志文件里明明有“操作失败”四个字你用grep 失败去搜结果一条都搜不到但用less打开文件中文显示正常。原因大多数系统 grep 在处理非 UTF-8 编码文件时因为 locale 设置不一致或文件本身是 GBK 编码会把中文字节当成非法字符直接跳过。less能显示是因为它自己做了编码猜测而 grep 不会自动做这个转换。解决先查看文件真实编码再用iconv把内容转为 UTF-8 后检索。不改原文件直接用管道完成转换file app.log # 查看编码常见输出为 ISO-8859 或 GBK iconv -f GBK -t UTF-8 app.log | grep 失败 # 转换后再搜 export LC_ALLC.UTF-8 # 如果原文件已是 UTF-8但 grep 仍异常时使用如果文件是 UTF-8 但 locale 有问题可以显式export LC_ALLC.UTF-8再执行 grep。这个坑在网上下载的日志压缩包、老系统备份文件里非常常见遇到“明明有却搜不到”的情况优先怀疑编码。5.5 手册越攒越厚反而不好用现象你按网上的大全整理了自己的手册半年后积累了上千条命令但每次查找都要花很久最后又回到搜索引擎。越“全”越用不起来这是大多数人整理命令笔记的最终归宿。原因没有分层和索引地把所有内容塞进一个文件导致“全面的手册”变成“没有入口的仓库”。目录本身失去了导航意义你甚至不记得某个模块里放的是什么。解决给手册立规矩。第一层是“速查清单”每条最多十来个字反应“遇到什么场景用什么命令”第二层是“常用命令详解”只展开真实用过的命令第三层是“外部素材归档区”放网上看到、还没验证的命令统一标上“未验证”状态。每次要用命令时先查速查清单没有结果再进入第二层。同时结合第 4 章的自动索引脚本让命令检索从“翻目录”变成“输入关键词过滤”。整理到最后会发现把命令分为“每周必用”和“参考存证”两类就不再纠结于什么都要掌握了。6. 把手册变成自己的高频面板别名、函数与自检索到了这个阶段我对命令手册最大的期待不只是“能查到”而是“在被需要时直接跳到我面前”。我会把第 2 章的速查清单收进 shell 配置里用几个精心设计的函数把手册变成命令行里随时可以唤出的高频面板。# ~/.bashrc 或 ~/.zshrc 中加入以下内容 # 快速查看某个模块的速查表 qmod() { local mod${1:-files} # 默认查看文件模块 grep ^|.*| $mod | ~/linux-manual/cheatsheet/command-index.md 2/dev/null } # 查某个命令先看手册速查表再看本地man qman() { local cmd$1 echo 速查索引 grep -i ^| .*$cmd.*| ~/linux-manual/cheatsheet/command-index.md echo 手册详解 grep -rn $cmd ~/linux-manual/commands/ --include*.md | head -20 echo 系统手册前几行 man $cmd 2/dev/null | head -30 }qmod函数的作用是“按模块过滤索引行”快速看到某个模块下我已经记了哪些命令。qman函数把“检索索引、翻我在手册里的详解、看系统原版手册”三步合一让我只记得一个函数就能走完“确认命令是否可用、查看经验笔记、再看官方定义”的完整链路。这两个函数最大的价值不是省了几次输入而是把“搜索的过程”固化成一套固定动作思考负担小了很多。我还习惯在qman的输出末尾加一条“我踩过的坑”备注提示自己看命令时先扫一眼。比如中文乱码、新版工具替代旧命令、某些参数在不同发行版行为不一致都在备注里写十几二十个字下次再查时就不用重新踩一遍。回头看看这份手册的养成过程与其说我在整理命令大全不如说我在给自己建一套“命令行肌肉记忆的训练系统”。开始阶段花一晚上搭好骨架之后每周花十分钟补充一条真实用过的命令远比下载一份别人的大全放在收藏夹里更有意义。希望帮到你。本文还有配套的精品资源点击获取