银星皓月兄弟们，这篇不是让你去背的，是让你用的。做运维这些年，我最大的感受就是：Linux命令这东西，关键不是你记住了多少，而是你在服务器出问题、领导盯着屏幕等着的时候，能多快想起该敲什么。所以我今天整理了一份我自己平时真正在敲的高频命令清单，覆盖文件处理、日志排查、进程管理、网络定位、用户权限这些日常离不开的场景，还顺手把一些特别容易踩的坑标了出来。不管你是刚接手服务器的新人，还是每天泡在终端里的老手，这份东西应该都能给你省点时间。
提示：文中涉及的命令我都标注了常用参数和典型场景，但不同发行版之间细节略有差异，比如包管理器有的用yum有的用apt，切到具体机器上先确认一下环境，别直接照抄。
1. 先澄清一个误区：速查表不是背出来的，是查出来的
很多人学Linux命令喜欢死记硬背，今天我告诉你：一个合格的运维不会记住所有命令，但一定知道怎么快速找到要用的命令。这就是man、help、history还有我自己整理的笔记存在的意义。
先说说man命令。man是“manual”的缩写，所有命令的详细用法都藏在里面。你遇到一个命令不太确定参数，直接man一下，比百度快而且准。有人觉得man太长了看不下去，那没问题，用man -k，它可以根据关键词搜索相关的man页面。比如你想找一个查磁盘空间的命令，但忘了是df还是du，敲man -k disk，相关的命令会列出来。同样的逻辑，命令后面接--help或-h，是更快的方式，只看参数概要，不看长篇说明。
再来说说history。这个是大家的命令历史库，也是我整理速查表的素材库。默认情况下history会把当前用户敲过的命令都记下来，然后你可以用history查看，配合grep直接过滤：history | grep ssh，看看我之前都执行过哪些ssh相关命令。更实用的是用!符号快速复用历史命令：!!表示上一条命令，!ssh表示最近一条以ssh开头的命令。有人觉得history记录太乱，那你可以在~/.bashrc里加上环境变量，让history记录时间和用户，这样排查问题的时候能看清是哪步操作触发的。加一行export HISTTIMEFORMAT="%F %T "，执行source ~/.bashrc之后，再敲history，每一条命令前面都会带上执行时间点，排查事故特别有用。
我自己还有个习惯：每次遇到一个新的冷门参数，确认有用就即时追加到个人速查文件里。放到~/cheatsheet.md或者直接在~/.bashrc写一堆alias都行。比如我常用的alias ll='ls -lh --color=auto'、alias grep='grep --color=auto'，都是提升日常操作效率的好帮手。很多人说Linux命令记不住，其实不是记不住，是你没有一个沉淀的机制。用顺手之后，你会发现常用的也就那几十条。
所以，先别急着往下翻，把手里的终端开好，接下来每一条都自己敲一遍。命令这东西，看十遍不如敲一遍。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 文件和目录操作：从日常增删改到危险操作的边界
文件操作是Linux里最基础也最常用的场景。先说目录切换那几件套：pwd查看当前路径，cd切换目录，ls列出目录内容。这三个看着简单，但越基础越有讲究。我见过不少新手在服务器上找不到自己的位置，连pwd都不敲就慌，其实先定位自己在哪里，再决定下一步怎么走，比啥都重要。
ls的常用参数建议刻进肌肉记忆：-l显示详细信息，-a显示隐藏文件，-h以人类可读方式显示大小，-t按时间排序。组合起来就是ls -lht，看哪个文件最新改过，效率极高。排查日志目录的时候我一般直接ls -lht /var/log | head，先看日志文件谁最新，心里就有数了。
然后是创建和删除。mkdir -p a/b/c这条要多说一句，-p参数会自动创建父目录，如果你要在一个深层目录里建目录，不加-p直接报错，加了它连父目录一起建好。反过来，删除目录用rm -rf，这个命令我已经看太多人出过事了。-r是递归删除，-f是强制删除不提示，组合在一起，一梭子下去目录连同内容就没了。我现在的习惯是：首先，删除前先ls确认一遍；其次，尽量用rm -ri，它会在删除每个文件前跟你确认一次，虽然慢，但安全；最后，生产环境上禁用root直接操作，用普通用户加sudo，多一层提醒总比没有好。
再说说复制和移动。cp -a保留全部属性，cp -r递归复制。做配置备份的时候我经常敲cp -a nginx.conf nginx.conf.bak.20250101，把文件连同权限和时间戳一起保留，万一回滚也不至于权限出错。mv更轻量，同一文件系统内它只是改个名字，成本几乎为零，所以改配置文件之前可以先mv一份备份。但要注意，跨文件系统mv会变成“复制+删除”，文件大的时候会有明显耗时，别在那死等，看IO才是正事。
查找文件是另一个高频操作。find的用法我之前单独写过一篇文章，这里讲最核心的。find /var/log -name "*.log" -mtime +7，这条命令的意思是找/var/log目录下所有名称以.log结尾、修改时间超过7天的文件。注意-mtime +7和-mtime 7含义不同：+7是7天以前，7是正好第7天，实际使用中大家要算清楚，不然清理日志很容易把在用的文件误删了。还有一个实用组合：find . -type f -size +100M，查找当前目录下大于100M的文件，排查谁占满了磁盘时经常用。找到之后要批量处理，可以用-exec：find . -name "*.tmp" -exec rm {} \\;，这里的{}代表找到的每个文件，\\;是命令结束的标志。不过我更推荐用find ... | xargs组合，处理大量文件时性能更好，但要特别注意文件名里带空格的情况，建议find ... -print0 | xargs -0 ...，这个组合能避开空格导致的解析问题。
目录大小统计用du，磁盘整体占用用df。这两个命令后面还会再讲，但在文件操作语境下，我优先看的是du -sh *，它会列出当前目录下每个子目录的总大小，找哪个目录最占空间一目了然。-s是汇总，-h是人类可读格式，这一对参数基本不离手。
最后提一句软链接。ln -s /data/www /www创建软链接，很多应用部署时路径和你实际存放位置不一致，就用软链接搭桥。删除软链接的时候要注意：rm /www是删除链接本身，如果你手滑写成rm -rf /www/，尾巴带了斜杠，那删除的是链接指向的目录内容，不是链接本身。这是真实翻车现场，别问我是怎么知道的。
3. 文本处理与内容检索：日志排查的三板斧
日志是运维的命脉，而文本处理命令就像是解剖日志的手术刀。日常排查日志，我基本靠三条命令组合：grep过滤、sed截取、awk取列。这三板斧用熟了，再乱的日志也能理出头绪。
先讲grep，这是最常用的。grep "ERROR" /var/log/nginx/error.log，直接过滤出包含ERROR的行。实际排查时我会加上-i忽略大小写，-n显示行号，--color高亮匹配词。grep -r "keyword" /etc/nginx/递归搜索整个目录，比一个个文件翻高效太多了。还有就是grep -v反选，比如看日志里除了健康检查之外的所有请求，grep -v "healthcheck" app.log，这个技巧在接口被轮询刷屏时特别有用。进阶一点，grep -A 5显示匹配行之后5行，grep -B 5显示匹配行之前5行，排查异常堆栈时把上下文带出来，问题根因往往就藏在那个上下文里。还有grep -c统计匹配次数，看某个错误出现了多少次，评估严重程度时第一条命令就敲它。
再说sed，它是流编辑器，对日志文件做行级别的过滤和替换。最经典的用法是sed -n '100,200p' app.log，只打印第100到200行，对付超大日志文件特别有效，不用cat整个文件了。另一个高频用法是删除匹配行：sed -i '/debug/d' app.log，把带debug的行直接删掉，生成一个干净版日志。-i是原地修改，用之前一定要确认这是副本，不然误操作就找不回原文件了。如果你想保留原文，可以先cp一份，或者不加-i，把输出重定向到新文件sed '/debug/d' app.log > app_clean.log。
awk则是列处理的王者。日志格式往往是“时间 IP 状态码 响应时间”，这时候awk '{print $1, $4, $9}'就能提取出指定列。我最常用的一个组合是统计Nginx访问日志里所有IP的访问次数：awk '{print $1}' access.log | sort | uniq -c | sort -rn，$1是日志第一列，取出来之后sort排序，uniq -c统计次数，再sort -rn按次数从大到小排。这个组合是排查CC攻击、看哪个IP异常频繁时最犀利的武器。awk还支持条件过滤，awk '$9 >= 500 {print $1, $7}'，找出所有状态码大于等于500的请求路径，一眼定位报错接口。
还有两个简单但极其常用的命令：head和tail。tail -f app.log会持续跟踪文件输出，调试进程时开着它，基本等同于给应用挂了个心电图。tail -n 200 app.log查看最后200行，head -n 100 app.log看开头100行。我还有个习惯，排查启动失败的应用时，tail -n 50直接看最后一段日志，错误原因九成都在那。
最后说说vim，命令行的文本编辑器。很多人只会在vim里打开文件、按i插入、按Esc退回命令模式、按:wq保存退出，这确实是最常用的四个操作。但从排查问题的角度看，我推荐再多记几个：/关键字搜索文件内容，搜索到之后按n跳转到下一个匹配；:set nu显示行号；:12直接跳到第12行；:q!不保存退出。还有一个特别高效的组合：vim打开日志后按Shift+g跳到文件末尾，再往上翻，找最新的报错信息。有人觉得vim难学，其实日常用到的就这几个，先用熟，形成肌肉记忆之后就离不开了。
文本处理这部分，核心思路是：过滤行用grep，截取范围用sed，提取列用awk，实时跟踪用tail，手动翻看用vim。把这套流程串起来，排查日志问题的速度会快很多。
4. 进程、资源与后台任务：让程序按你的预期跑起来
服务器上跑着几十个进程，哪一个出了问题都会影响业务。掌控进程状态是运维的基本功。首先要学会的是ps命令，查看当前进程快照。最常用的组合是ps -ef，把系统里所有进程的UID、PID、PPID、CPU占用、启动命令列出来，配合grep用：ps -ef | grep java，看看Java进程在不在。另一个ps aux也差不多，但这个格式下%CPU和%MEM列更方便看资源占用。想找某个服务的PID，还可以用pgrep nginx直接拿PID，脚本里特别常用。
有了PID之后，先别急着kill。先看看这个进程到底干了什么：top -p PID实时监控指定进程，这是定位进程CPU飙升时的第一反应。top界面里按P按CPU排序，按M按内存排序，这一排一按，谁在吃资源立刻清楚。top是动态监控界面，如果想看一次性的快照，用top -bn1，这个在脚本采集信息时很实用，适合写自动化巡检脚本。类似的方向，htop显示更友好，还能直接F9杀掉选中的进程，但一般最小化安装的服务器没有htop，需要自己装，所以我更习惯top。
看完了谁在吃资源，下一步就是管理进程生命周期。kill PID发送SIGTERM信号，让进程自己释放资源退出；kill -9 PID发送SIGKILL，强制杀掉进程。能不用-9就不用-9，因为SIGKILL不让进程做任何清理工作，可能导致数据不一致或者文件锁没释放。我处理问题时的顺序是：先kill，过几秒看进程还在不在，实在不行才kill -9。批量杀进程可以用pkill -f pattern，按命令行里的关键字匹配，比如pkill -f "app.jar"，但要注意别匹配到自己正在执行的命令本身，这个坑很隐蔽。
说完进程本身，还得说后台运行。一个程序，ssh终端一关它就停了，怎么办？两种方案。第一种，nohup command &，nohup让进程忽略SIGHUP信号，&把进程放到后台执行。日志会输出到nohup.out文件，想指定日志文件就加nohup java -jar app.jar > app.log 2>&1 &，2>&1的意思是把标准错误也重定向到同一个文件，不然错误信息会单独炸出来。第二种，用screen或tmux，它们能创建一个持久会话，即使断网重连，会话里的进程还活着。我个人推荐tmux，它的分屏和会话管理太强了，日常在服务器上干活基本离不开。
资源层面的命令，接着文件操作章节里说的df和du。df -h查看磁盘分区使用率，第一眼看根分区是不是满了，这是服务器报警最常见的源头。du -sh *看当前目录下每个子目录多大，配合du -sh+sort找出最大的目录。定位到具体的大文件之后该清理就清理，但清理之前先确认是不是日志文件，别把数据库文件给删了。free -h查看内存使用，输出里的available字段才是真正可用的内存，别看到used很高就觉得内存不够，Linux会把空闲内存用作缓存，这是正常现象。
还有一个systemctl系列，这其实是systemd提供的服务管理命令，现在各大主流发行版都在用。systemctl status nginx查看服务状态，systemctl start/stop/restart nginx启停服务，systemctl enable/disable nginx设置开机自启。服务异常时，先status看状态，再看journalctl -u nginx查看这个服务最近的日志，很多启动失败的原因在日志里直接写着呢。这套命令比直接跑nginx二进制要规范得多，服务进程由systemd托管，异常退出还会自动拉起，生产环境能用systemctl就别手动跑进程。
所以做进程管理，我的核心习惯是：先定位（ps/pgrep/top），再诊断（top/df/free/logs），最后处理（kill/systemctl restart）。这套思路把排查和修复串起来，比乱敲一通强太多。
5. 网络排查和文件传输：从端口探测到跨机器拷贝
网络是服务器另一个大命门。端口不通、连接超时、服务访问不了，这类问题排查起来如果没有一套顺手的命令，很容易在“通不通”这一步卡上半天。
通不通，最基础的先ping一下。ping -c 4 10.0.0.1，-c 4表示只发4个包，不然它会一直ping下去。ping不通，首先怀疑网络层问题，看看IP、路由、防火墙是不是有配置问题。但记住一点：ping通了只能说明主机可达，不说明具体端口服务是通的。这时候就要用telnet来探测端口。
很多人以为telnet是个远古协议，早该退休了，但在运维手里它就是个好用的端口探测工具。telnet 10.0.0.1 3306，如果端口能通，终端会显示Connected to，甚至带出服务的banner信息；如果端口不通，它会一直卡在那里会超时，或者直接显示Connection refused。这个区别能帮你快速定位：通，说明网络没问题，问题在服务端或应用层；不通，去检查服务有没有监听、防火墙有没有放行。有些最小化系统没装telnet，那就用nc -vz 10.0.0.1 3306，-z表示只扫描端口不发送数据，效果一样。另外还有一个更轻量的方案：timeout 3 bash -c '</dev/tcp/10.0.0.1/3306'，这个利用bash自身的能力，不需要额外安装任何工具，在排查环境受限的服务器上特别管用。
端口探通了，接下来要确认服务到底监听在哪个端口、哪个IP上。老一点的命令是netstat，新一点的推荐ss。ss -lntp，-l只看监听状态的端口，-n用数字显示不解析域名，-t只显示TCP，-p显示哪个进程在监听。这条命令是我每次上线服务之后必敲的第一条：确认服务真正监听了，再去测访问。排查已建立连接的并发数，用ss -s汇总显示TCP的连接状态统计，能在挂满大量连接时一眼看出是在TIME_WAIT还是ESTABLISHED积压。
请求测试就交给curl。curl -I https://example.com只看响应头，-I是HEAD请求，不下载页面正文；curl -v https://example.com会输出整个请求和响应过程，包括TLS握手细节，排查接口超时和证书问题时用这个。再配一个-w参数，可以自定义输出耗时指标：curl -o /dev/null -s -w "HTTP:%{http_code} 耗时:%{time_total}s\\n" https://example.com，这条命令把页面内容丢弃，只打印状态码和总耗时，做接口响应时间抽查时特别方便。如果接口返回了非200状态码，配合-v看返回头里的信息，定位是CDN的问题、Nginx的问题还是后端应用的问题，很快就知道往哪查了。
文件传输的场景里，scp一定是高频中的高频。scp file.txt user@10.0.0.1:/tmp/，把本地文件拷到远程；scp user@10.0.0.1:/tmp/file.txt ./，从远程拉回本地。拷整个目录加-r。这里有个特别经典的坑：scp的端口参数是大写-P，而ssh登录端口参数是小写-p，很多人习惯性打成小写，结果报错还反应不过来。如果你用的是非22端口的服务器，scp命令一定要写成scp -P 2222 file.txt user@10.0.0.1:/tmp/。还有一个比较隐蔽的坑，scp传输文件时遇到文件名带空格，需要把文件名用引号包起来，scp "my file.txt" user@host:/tmp/，不然它会按两个参数解析，直接报错。如果对大文件做传输，我建议先tar czf - dir | ssh user@host "tar xzf - -C /tmp"，用管道直接压缩并远程解包，减少临时文件占用的磁盘空间，也省了一次中转IO。
远程会话管理上，ssh本身也要讲细节。ssh user@host -p 2222登录远程服务器；公钥登录配置好之后可以免密，配置方式是把自己本地的~/.ssh/id_rsa.pub内容追加到服务器~/.ssh/authorized_keys文件里，然后本地ssh-copy-id user@host一键完成。这之后再登录就不用反复输密码了，脚本自动化跑命令也方便得多。还有一个技巧：ssh user@host "command"可以直接在远程执行单条命令而不登录交互式shell，批量巡检多台机器时，配合for循环或者pssh工具，效率提升非常多。
网络这块按我自己的排查顺序就是：ping完测端口，测完端口看监听，监听没问题再curl请求，请求不通抓包分析，传输文件用scp。这个顺序从头到尾把问题域收窄，能省掉大量无意义的猜测。
6. 用户与权限：多用户环境下的安全边界
服务器不会只有你一个用户。随着团队扩大，给同事开账号、分权限、冻结离职账号，这些都是日常操作。用户权限用得不好，轻则权限混乱，重则有人误删生产数据，所以这块必须稳。
新建用户的命令是useradd，最基础的用法是useradd zhangsan，然后passwd zhangsan设置密码。但生产环境我不会这么草率地建，一般会加参数：useradd -m -s /bin/bash zhangsan，-m自动创建home目录，-s指定默认shell为bash。如果没有指定shell，某些系统默认是sh，用户登录进去的体验会差很多，连tab补全都没有。还有-d自定义home目录路径，-G wheel把用户加入wheel组，有sudo权限。这里要特别提醒，不同Linux发行版的用户组名称不同，RHEL/CentOS系是wheel组，Debian/Ubuntu系是sudo组，加错组就sudo不了。
用户密码对应过期策略，我建议每个管理员都掌握。chage -l zhangsan查看用户的密码过期信息；chage -E 2025-12-31 zhangsan设置账号过期时间，临时外包人员的账号到期自动失效，不用手动清理。这个细节容易漏，但偏偏是安全审计时重点查的内容。用户创建之后，如果需要改用户信息，用usermod，usermod -aG docker zhangsan把用户附加到docker组，-aG是追加组，不加-a会覆盖掉用户原有的附属组列表。删除用户用userdel -r zhangsan，-r会同时删除home目录和mail spool，按需使用。
接下来是权限模型。Linux文件权限分三组：owner、group、others，每组有r（读）、w（写）、x（执行）三种权限，用ls -l查看。chmod修改权限，常用数字法：chmod 750 file，数字对应rwx的二进制组合，7=rwx、5=rx、0无权限。文件先搞清楚是文件还是目录再定权限，目录的x权限是进入目录的权限，没有x你连cd都进不去，所以目录一般至少755或750。chown修改所有者，chown zhangsan:devops file.txt同时改所有者和所属组，这一条经常在部署应用时用，把文件归属从root改成应用账号。
关于sudo，这是给普通用户提供临时提权能力的安全通道。配置在/etc/sudoers，但不要直接编辑这个文件，系统有专门的校验命令visudo来编辑，它能防止你写错语法导致sudo全部不可用。我一般配置的格式是zhangsan ALL=(ALL) ALL，表示zhangsan可以在所有主机上以所有用户身份执行所有命令。更精细的可以是zhangsan ALL=(root) /usr/bin/systemctl restart nginx，只允许他重启Nginx，其他命令没有权限。粒度越细，误操作面越小。
用户权限这块，我的实操心得就三个字：小心配。配错了，某个服务起不来还好，最怕的是权限过宽导致的数据泄露或误删。每次配置完，用刚才说的ss -lntp、ps -ef、ls -l这些命令验证一下，确认权限和用户实际吻合，再交给对方用。
7. 软件安装与系统服务：包管理器和容器命令的常见组合
最后谈一谈装软件和跑服务。这部分命令看起来杂，但只要理解包管理器的逻辑，就能举一反三。
RHEL/CentOS系用的是yum，现在新版换成了dnf，但命令基本兼容。yum install -y nginx安装软件，-y自动确认不交互；yum remove nginx卸载软件；yum update更新所有软件包；yum search nginx搜索软件包。Debian/Ubuntu系则是apt update先刷新软件源，再apt install -y nginx。如果你用的是国产Linux发行版，比如银河麒麟、统信UOS，要注意它们基于Debian还是CentOS生态，装软件前先看一下系统的包管理工具是apt还是yum，盲目照抄网上的命令经常会碰到“No package found”。不同系统的软件源配置路径也不一样，yum一般在/etc/yum.repos.d/，apt在/etc/apt/sources.list或/etc/apt/sources.list.d/，排查安装源的时候去这两个目录看准没错。
装完软件不等于装好服务，还要看它有没有真正跑起来，这时候就用到前面提到的systemctl了。以Nginx为例：systemctl start nginx启动，systemctl enable nginx设置开机自启，systemctl status nginx看状态。如果服务起不来，系统会提示你用journalctl -xn或者systemctl status nginx后面附加的日志片段来排查。我自己的排查路径是：先journalctl -u nginx --no-pager -n 50看最近50行日志，确认错误信息；如果日志没输出，再看端口ss -lntp | grep 80，确认端口是不是被占用。很多时候nginx启动失败就是端口被占用了，把占用进程找出来解决掉，再启动就通了。
再聊容器。热词里出现了containerd命令，这说明现在用容器部署的场景越来越多了。理解容器命令前，要搞清楚Docker和containerd的关系。Docker是我们日常用的客户端，而containerd是底层的容器运行时，负责真正创建和运行容器、管理镜像和容器生命周期。Docker安装之后会自带containerd，手动装containerd也常见于Kubernetes节点的场景。日常操作容器最常见的还是docker命令：docker ps查看运行中的容器，docker ps -a查看所有容器，docker logs -f <container>查看容器日志，docker exec -it <container> bash进入容器内部调试，docker restart <container>重启容器。如果是在K8s节点上排查，那会用到crictl ps和crictl logs，这是containerd提供的命令行客户端，用法和docker高度相似，只是它直连containerd的socket。crictl命令在没有Docker daemon的节点上特别重要，别到了现场发现docker ps报错就慌了，先确认节点上装的是docker还是纯containerd，再选对应的命令。
容器日志是另一个容易忽视的点。默认情况下，Docker的容器日志在/var/lib/docker/containers/<容器ID>/目录下，文件会一直增长，不清理会撑爆磁盘。配合前面的df -h和du -sh，一旦发现磁盘占用异常，先考虑清一下容器日志。日常习惯是给Docker daemon配置日志轮转，在/etc/docker/daemon.json里写上log-driver和max-size、max-file，限制单个日志文件大小和保留个数，这个配置改完要重启docker服务才生效。
最后，关于软件安装、服务管理和容器，我的经验是：先看发行版是什么，再看上层工具是什么，最后再看服务本身。整个链路清晰了，命令就是一层窗户纸。服务跑不起来，优先看日志；日志没有，检查配置；配置没错，看端口和权限。层层排查，基本没有解决不了的问题。
最后再分享一点个人习惯。我每隔一段时间就会把自己常用的命令重新整理一遍，不是背，是把它压成一张脑图：文件操作一套、文本处理一套、进程资源一套、网络排障一套、用户权限一套、软件服务一套，六套下来覆盖了日常工作的九成。你在使用中也可以把每次踩坑的教训和对应命令记下来，形成自己的速查手册。毕竟命令会变、系统会变，但你沉淀下来的排查思路和习惯，才是真正值钱的东西。