记得刚接触服务器那会儿，我对着屏幕上黑底白字的终端窗口一脸茫然。后来在CentOS上折腾了几年业务系统，踩了无数坑，才慢慢攒出一套真正顺手、实用的命令清单。所谓“centos 命令合集”，网上能搜到一大堆，但多数要么太零散，要么只讲参数不讲场景。这篇东西不一样，我不打算给你堆砌几百条命令，而是把日常运维、排查故障、部署应用时真正高频使用、能直接救命的那些命令拎出来，配套讲清楚“为什么这么用”“什么时候用”“踩过哪些坑”，让你拿到手就能用，用的时候心里有底。
这篇内容适合谁？刚入门Linux、准备用CentOS做服务器的小白，以及在云服务器上部署过应用、但总觉得命令不够熟练、遇到问题全靠百度的初级运维。读完你至少能独立完成服务器状态检查、服务部署、日志排查和常见故障定位，不用再遇到问题就慌。
1. 系统信息与资源监控：先搞清楚机器在干什么
1.1 CPU和内存排查，别一上来就看负载
很多人排查服务器卡顿，第一反应就是敲top看负载。方向没错，但太粗糙了。我以前就吃过亏：某个Java应用把CPU吃到200%，top显示负载很高，但具体是哪个进程、哪个线程导致的，光看默认输出根本定位不准。
top的正确打开方式是先按P键让进程按CPU使用率排序，按M键按内存排序，然后重点关注前三行。第一行的load average是过去1分钟、5分钟、15分钟的平均负载，这个数字要结合CPU核数看。比如4核机器，负载超过4就说明任务在排队了；16核机器负载8，其实还有余量。我习惯用uptime快速看负载，用top深入定位。
排查CPU异常，top里按1看每个核的使用情况，这能确认是单核打满还是多核都忙。但光看进程还不够，Java应用还得往下钻到线程级别，用top -Hp 进程PID查看线程占用，再把线程ID转成十六进制，配合jstack才能定位到代码层面的问题。这套流程我走过太多次，算是排查CPU问题的标准动作。
内存方面，free -h是最常用的，但我发现很多人会误读输出。重点在第二行-/+ buffers/cache这行的available值，那才是应用真正可用的内存。有时候free -h显示used很高，但available还剩不少，其实是文件缓存占了内存，这种情况不用慌，Linux本来就会尽量利用空闲内存做缓存。真正要担心的是available持续走低，并且top里看到进程的RES内存不断上涨，那才是内存泄漏的信号。
1.2 磁盘和IO情况，别等写满才发现
磁盘写满是个很尴尬的故障。我遇到过数据库服务器磁盘使用率到98%，导致写入直接报错，业务完全停摆。事后总结，其实磁盘监控应该提前做好。手动排查时，df -h看文件系统空间，df -i看inode使用情况——这两个要一起看。我有一次就栽在inode上：df -h显示磁盘还剩十几个G，但应用就是报“No space left on device”，查了半天才发现是/tmp目录下的小文件把inode耗尽了。
定位大文件用du -sh *配合du -h --max-depth=1 /路径逐层排查，也能用find / -size +1G -exec ls -lh {} \;一次性找出超过1G的大文件。我习惯先用du定位到目录层，再用find精确到文件，这样效率最高。
磁盘IO排查是另一套逻辑。iostat -x 1看%util和await两个指标，%util接近100%说明磁盘已经饱和，await明显高于正常值说明IO请求在排队。但要注意，%util高不一定代表磁盘坏了，有可能是某个进程在疯狂读写。这时候用iotop直接看哪个进程在消耗IO，一抓一个准。
1.3 系统版本与内核信息，兼容性问题的关键
安装软件前先确认系统版本，这是个好习惯，能避免不少兼容性问题。cat /etc/os-release查看发行版版本，uname -r查看内核版本。CentOS 7和CentOS 8的软件管理方式不同，内核版本差异也直接影响驱动兼容性。比如某些网卡驱动需要较新的内核支持，系统版本太老就只能换驱动版本。
lscpu查看CPU架构和型号，getconf LONG_BIT确认系统是32位还是64位。虽然现在64位是主流，但我在某些老旧机器上真遇到过32位系统装错软件包的情况。还有dmidecode -t memory可以查看物理内存条信息，排查硬件问题时用得上。这些基础信息看着不起眼，但在部署新应用、规划扩容时都是决策依据。
2. 文件管理：不只是ls和cd
2.1 find的几种高级用法，省时又省力
find是Linux里最强大的文件查找工具，没有之一。很多人只会用find / -name "xx"，但实际场景远比这个复杂。
按时间查找是排查日志和临时文件的利器。find /var/log -mtime +7 -name "*.log"找出7天前的日志文件，定期清理时特别好用。注意mtime是修改时间，ctime是状态改变时间（包括权限变化），atime是访问时间。排查时我常用mtime，因为绝大多数场景关心的是文件内容什么时候被改过。
按大小查找配合删除操作要格外小心。find /data -size +500M -delete这个命令能直接撑爆存储的大文件，但-delete参数千万别随意用。我见过有人把-size +500M写成了-size 500M，意思变成了找“正好500M”的文件，结果该删的没删掉，不该执行的逻辑却执行了。正确做法是先不加-delete跑一遍确认输出的文件列表，再决定是否删除。
按权限和属主查找是配合安全审计常用的。find / -perm -4000 -type f找出所有带SUID权限的文件——这类文件有安全隐患，如果被恶意利用可能导致提权。排查时先用不删除的模式确认，再处理。
2.2 grep的边界和坑，别以为匹配就是一切
grep的强大体现在配合管道和正则表达式时。grep -r "关键字" /path/递归搜索目录下所有文件，grep -i忽略大小写，grep -v反向匹配（排除特定行），这些基础参数要熟。
我踩过最大的坑是grep和pgrep的区别。想找进程时我一度用ps aux | grep 进程名，但grep本身会匹配到自己的命令行，导致结果里多出一条grep进程。后来改用pgrep -f 进程名就干净很多，或者用pgrep -af查看完整命令行并显示PID，适合脚本里判断进程是否存活。
日志排查时我常用的组合是grep -E "ERROR|Exception" app.log | head -50，用-E支持扩展正则，一次性匹配多个关键词。如果想看某个错误前后几行的上下文，用grep -A 5 -B 5 "错误信息" app.log。这些扩展参数解决了“只看到匹配行但不知道上下文”的痛点。
2.3 清理日志的正确姿势，别把服务搞挂了
日志清理是个看似简单实际很讲究的活。直接rm日志文件有时会有问题：进程已经打开了这个文件，虽然文件被删了但空间不会释放，直到进程重启。这种“删了但没完全删”的现象，df -h看空间还是满的，我刚开始干这事时遇到过好几回。
正确处理方式是用cat /dev/null > 日志文件或者truncate -s 0 日志文件清空内容而不是删除文件。这样进程持有的文件句柄不受影响，空间也能立即释放。想保留最近N天日志、自动清理旧文件的，用logrotate配置最省心。CentOS自带的/etc/logrotate.conf和/etc/logrotate.d/目录，按天、按大小切割日志、保留份数、压缩旧日志都可以配置，我通常在/etc/logrotate.d/下为每个应用建一个独立配置文件。
清理/tmp目录时也要注意，别把正在使用的临时文件清了。稳妥做法是先看文件修改时间，再用find /tmp -mtime +3 -type f列出候选文件，人为确认后再删除。
3. 进程与服务管理：让程序安分守己
3.1 systemctl的日常，以及新旧命令的对应关系
CentOS 7开始用systemd取代了旧的SysV init，systemctl就成了管理服务的标准命令。systemctl start/stop/restart/status 服务名是最基本的四件套，但我发现有个细节经常被忽略：修改了服务的配置文件后必须先systemctl daemon-reload再restart，否则新配置可能不生效。这个坑我踩过不止一次，还以为是配置写错了，其实是没重载。
systemctl enable 服务名设置开机自启，systemctl disable 服务名取消。systemctl is-enabled 服务名可以查询是否设置为开机自启。排查服务自启问题时这几个命令配合使用，很快能理清服务状态。
新旧命令对应关系记住一个原则：service 服务名 start/stop/restart在CentOS 7上依然能用，但底层也是调用的systemctl；chkconfig 服务名 on对应现在的systemctl enable 服务名。掌握新命令，会看老文档，不容易被五花八门的教程带偏。
3.2 ps、top、htop的真实差异，别混为一谈
ps看的是某个瞬间的进程快照，top是动态刷新，htop是top的增强版。日常排查我习惯先ps aux看进程列表，再用top动态观察。
ps aux字段含义要会读：USER是进程用户，PID是进程号，%CPU和%MEM是CPU和内存占用率，STAT是状态（S是睡眠，R是运行，Z是僵尸进程）。ps -ef是和ps aux类似但更标准的格式，两者的输出字段排列略有差异。检查僵尸进程用ps aux | grep 'Z'，发现异常时顺着 PPID（父进程ID）找是谁没等子进程退出，通常能定位到有问题的程序。
top里遇到状态为D（不可中断睡眠）的进程要格外留意，这种进程通常是磁盘IO卡住了，可以结合iostat一起看。定位进程卡死问题，strace -p 进程PID能查看进程当前的系统调用，确认它卡在哪个操作上。这招在排查程序假死时非常有效。
3.3 nohup和后台运行的注意事项，别让任务悄悄消失
用nohup让程序在终端关闭后继续运行，是部署脚本、启动后端服务的常用方式。但nohup只是个“忽略挂断信号”的工具，不能完全替代真正的进程守护。写全的启动命令是nohup 命令 > 日志文件 2>&1 &，这行命令里>是重定向标准输出，2>&1是把标准错误也重定向到同一个地方，&是放到后台执行。
关于输出重定向有一个大坑：如果日志文件路径写错了，或者目录不存在，程序启动时都不会报错，但日志完全没写进去，排查问题时就抓瞎了。所以我启动前都会先手动touch 日志文件确认路径可用。
nohup启动的程序在系统重启后会消失，如果需要长期运行的服务，还是得写成systemd服务单元文件，配合Restart=always实现崩溃自动拉起。写服务单元文件时注意ExecStart里要写绝对路径，工作目录用WorkingDirectory指定，很多莫名奇妙的启动失败都是相对路径导致的。
4. 网络排查工具：别只会ping
4.1 端口到底通不通，用对工具才高效
排查端口连通性，很多人第一反应是ping，但ping测的是ICMP协议，只代表主机通，不代表端口通。真正验证端口用telnet 主机IP 端口或者nc -vz 主机IP 端口。telnet能测TCP连接，但部分精简环境下没装，nc（netcat）更轻量。我日常最常用的是nc -vz -w 3 192.168.1.10 3306，-w 3意思是超时3秒，避免一直卡在那。
本机监听端口情况用ss -tlnp查看，-t是TCP协议，-l是监听状态，-n是数字显示端口不解析服务名，-p是显示对应进程。旧系统里用netstat -tlnp，但CentOS 7之后ss更快更准。结合lsof -i:端口号能确认哪个进程占用了特定端口——这个命令在排查端口被占用、决定能不能复用端口时很关键。
防火墙也要检查。CentOS默认用firewalld，firewall-cmd --list-all查看当前规则，firewall-cmd --permanent --add-port=8080/tcp开放端口后必须--reload才生效。我有一次配了防火墙规则但忘了reload，结果服务起好了外部就是访问不了，排查了半小时才发现是这问题。
4.2 流量和连接数怎么看，几个命令切中要害
看网卡流量最简单的是sar -n DEV 1，每秒刷新一次，查收发速率。如果没有sar，用ifstat或者直接看/proc/net/dev也能凑合。但流量大不代表有问题，真正要看的是连接状态。
ss -s能汇总显示当前TCP连接状态统计，ss -ant | awk '{print $1}' | sort | uniq -c能统计各类连接数。TIME_WAIT连接过多会导致端口资源紧张，高并发场景下尤其明显。排查连接数异常，重点看ESTAB（正常连接）、SYN-SENT（连接请求发出去没回应）、TIME-WAIT（连接结束后等待关闭）。
抓包定位网络问题用tcpdump。抓HTTP请求用tcpdump -i eth0 port 80 -w /tmp/http.cap，-w把抓包结果保存成文件，然后用tcpdump -r /tmp/http.cap读取分析。抓包文件能用Wireshark打开看，比直接看命令行输出直观得多。我排查过几次诡异的请求延迟问题，都是靠抓包发现是客户端在重复重传，而不是服务端处理慢。
4.3 curl不仅仅是请求工具，还有这些隐藏用法
curl是我日常调试接口最频繁的命令。curl http://localhost:8080/api/health请求接口，-I只看响应头，-v显示完整请求响应过程含TLS握手信息，-X POST指定请求方法。调试上传接口用curl -F "file=@/path/to/file" http://xx.com/upload，测试JSON接口用curl -H "Content-Type: application/json" -d '{"key":"value"}' http://xx.com/api。
检测接口耗时用curl -w "time_total: %{time_total}s\n" -o /dev/null http://xx.com，这个命令实测下来很有用——time_total是总耗时，-o /dev/null是把响应体丢弃只保留统计信息。配合time_connect、time_starttransfer可以区分是建立连接慢还是服务器响应慢。
curl也能当简易下载工具：curl -O http://xx.com/file.tar.gz下载文件并保留原文件名，-L跟随重定向，-C -断点续传。虽然不如wget功能全，但胜在几乎每个系统都有，够用就行。
5. 软件包管理：安装和卸载没那么简单
5.1 yum和dnf的关系，以及换源背后的逻辑
CentOS 7用yum，CentOS 8开始用dnf——但dnf的核心命令习惯和yum完全一致，dnf本质上就是新一代yum。yum install 包名、yum remove 包名、yum search 关键词，这些基础操作不费劲。真正讲究的是换源。
国内访问默认国外软件源速度慢，或者源失效导致更新失败，是常见问题。更换为国内镜像源的操作其实很简单：备份原repo文件，下载新的repo文件，清缓存，重新生成缓存。但这里有个细节，不同版本的系统repo文件内容和安装命令都不一样，别把CentOS 7的配置直接拿到CentOS 8上用。
yum makecache重建缓存时偶尔会报“mirrorlist”错误，通常是网络不通或DNS解析问题。先确认能通外网，再看 /etc/resolv.conf 配置，必要时手动指定一条可靠的DNS。我遇到过几次这种问题，都是DNS配置被改坏了导致源域名解析失败。
5.2 依赖冲突的处理经验，以及“强制”操作的边界
yum install最常见的报错是依赖冲突，比如两个包需要同一个库的不同版本。这时候不要一上来就用yum install --skip-broken或者加--nogpgcheck跳过验证，强行绕过依赖问题掩盖了真正的冲突，后期运行时可能出幺蛾子。
我的排查思路是先用yum deplist 包名查看包的依赖关系，再用yum list installed | grep 相关库看看本地已装的版本。本地仓库里有多版本库文件时，用yum install 包名-版本号精确指定版本安装，而不是安装默认版本。如果确实有一个依赖死活装不上，查一下这个依赖是不是在EPEL或第三方仓库里，先装好基础仓库再装额外仓库。
yum remove也有讲究：它会顺带移除依赖它的其他包。我有一次想卸载一个没用的开发库，结果它连带把某个老应用的运行库也卸了，导致应用起不来。卸载前建议用yum remove --dry-run 包名模拟一下，确认影响范围再做操作。
5.3 锁定版本避免“意外升级”，以及历史版本回滚
生产环境的依赖稳定比功能新更重要，所以锁定版本是个好习惯。yum versionlock 包名可以锁定某个包不被自动升级，需要解锁定用yum versionlock delete 包名。升级前我习惯先yum check-update看有哪些包有更新，再决定哪些值得升。
升级失败的应急回滚也要会。yum history查看安装/升级历史，找到对应的操作ID，然后用yum history undo 操作ID回滚该操作。这个命令命令用得好，能救回不少因误操作搞坏的环境。还有一个特殊情况：如果你是用rpm -ivh手动装的包，卸载时用rpm -e 包名，但要注意rpm不像yum那样自动处理依赖，卸载时如果其他包依赖它，会直接提示依赖错误，这也是很多新手困惑的地方。
6. 日志排查与常见故障速查
6.1 journalctl的使用技巧，比看日志文件更快
CentOS 7之后服务日志由systemd统一接管，journalctl查看日志比翻文件方便得多。journalctl -u 服务名查看某个服务的全部日志，journalctl -u 服务名 -f实时跟踪，这个命令配合服务启动排查特别好用。
按时间过滤也是长项：journalctl --since "1 hour ago"或journalctl --since "2025-01-01 00:00:00" --until "2025-01-01 12:00:00"。系统崩溃后想倒推原因，我会用journalctl -p err -b查看本次开机以来的错误级别日志，-p指定日志级别（err比info级别高），-b是本次启动（可以换成-b -1看上次启动）。
但journalctl日志默认存储在内存中，重启后会丢失。需要持久化时，编辑/etc/systemd/journald.conf里Storage=persistent，重启journald服务生效。否则系统一重启，之前的日志就找不回来了。
6.2 我用这套排查思路，解决过不少棘手故障
日志排查有个标准套路，很多人不知道：先看时间线、再看关键字、最后看上下文。时间上先用journalctl --since把日志范围缩小到故障爆发前后的时间段；关键字上用grep过滤如ERROR、Exception、timeout、denied这类强烈信号词；找到可疑条目后用-A-B参数看上下文。按这个顺序走，绝大多数问题都能在几分钟内定位。
分析日志时，同一条错误可能出现在多个时间点。别只看第一次出现就下结论——如果错误持续周期性出现，可能是定时任务或资源回收逻辑出了问题；如果只在某个操作后出现一次，那大概率是那次操作偶发的异常。我排查过一个“定时报错但业务无影响”的案例，最终定位是某个后台任务在空数据时抛了个WARN级别日志，业务上完全无影响但日志刷得吓人。
6.3 常见问题速查表，先对号入座再动手
| 症状 | 定位思路 | 常用命令 |
|---|---|---|
| 系统卡顿 | 看负载、CPU、内存趋势 | top、uptime、free -h |
| 磁盘满了但删不掉文件 | 看进程持有文件句柄 | lsof +L1 |
| 某个端口连不上 | 查监听状态、防火墙 | ss -tlnp、firewall-cmd --list-all |
| 服务起不来 | 看服务状态和日志 | systemctl status、journalctl -u 服务名 |
| 进程CPU爆高 | 确认具体进程和线程 | top -Hp 进程PID |
| 网络延迟高 | 分段测试连通性和耗时 | ping、curl -w、tcpdump |
| 包管理报错 | 检查源配置、DNS连通 | yum repolist、curl -I 源URL |
lsof +L1这个命令不常见但很实用：它列出所有被删除但仍被进程打开的文件。磁盘空间显示满了、df看却找不到大文件时，基本都是这类“孤儿文件”在占空间，定位到进程后重启或者重定向释放空间就行。
我自己实际排查问题，很少用高级复杂的命令组合，多半是上面这些基础命令的灵活搭配。真正起作用的不是命令数量多不多，而是你理解每个命令输出里的哪些字段是关键时刻的线索，以及排查顺序是否合理。遇到问题先别急着到处搜教程，顺着“系统状态→针对性定位→日志验证”这个思路走，慢一点但每一步都扎实。
命令这个东西，光看是学不会的。上手CentOS之后，找一台测试机把今天提到的命令挨个敲一遍，对着输出理解每个字段的含义，比抱着书背命令效率高得多。我用这套方法带过好几个新手，基本一个月左右就能独立处理常规运维问题。你踩过的坑越多，对这些命令的理解就越深，慢慢就能到达“看到现象，脑子里自然浮现排查步骤”的程度。
