做测试的兄弟们肯定都遇到过：刚才还好好的接口，突然超时报错；测试环境突然像死机一样，命令都敲不动。这时候别慌，不用马上喊运维，用这套“急救”命令清单，3分钟快速定位是代码Bug还是资源耗尽。
作为测试工程师，掌握这套排查逻辑，不仅能提交更有说服力的Bug报告，关键时刻还能帮你“救火”。
🚨 场景一：系统像死机一样卡顿（CPU 飙升 100%）
症状速写：命令延迟极高，网页打不开，输入完回车半天没反应。
第一步：用top找出“捣乱分子”
直接输入top，你会看到如下动态视图（简化示意）：
top - 11:30:00 up 10 days, 1:20, 3 users, load average: 2.45, 2.10, 1.95 Tasks: 120 total, 2 running, 118 sleeping, 0 stopped, 0 zombie %Cpu(s): 85.0 us, 10.0 sy, 0.0 ni, 5.0 id, 0.0 wa, 0.0 hi, 0.0 si MiB Mem: 8000.0 total, 1000.0 free, 6000.0 used, 1000.0 buff/cache PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1234 root 20 0 400000 350000 5000 R 80.5 4.3 0:15.30 java <- 罪魁祸首 5678 deploy 20 0 120000 50000 2000 S 5.0 0.6 0:02.10 nginx🔍 如何看：
- 看第一行
load average：如果数字超过CPU核心数，说明负载很重。 - 看
%Cpu(s)：us（用户空间）高 ➜程序死循环或计算密集。wa（等待I/O）高 ➜硬盘读写瓶颈，CPU在干等。
- 操作：按键盘
P（大写），可以让进程按 CPU 使用率排序。记下第一位的PID（比如上面的 1234）。
第二步：查户口，它是谁？
拿到 PID，还不知道它是哪个服务？用ps确认：
# -ef 显示所有进程，| grep 管道过滤ps-ef|grep1234输出示例：
root 1234 1 99 11:25 pts/0 00:03:15 java -jar /opt/app/backend.jar这就知道了，是/opt/app/backend.jar这个 Java 服务在抽风。
💾 场景二：服务被莫名杀掉，越来越慢（内存溢出 OOM）
症状速写：程序运行一段时间后突然消失；或者系统极慢，甚至鼠标都动不了。
第一步：看内存余额free
不要只凭感觉，直接看数据：
free-h输出示例：
total used free shared buff/cache available Mem: 7.7Gi 6.5Gi 200Mi 1.0Mi 1.0Gi 500Mi <- 注意这列 Swap: 2.0Gi 1.5Gi 500Mi🔍 如何看：
- 看
available：这是真正能用的内存。如果接近 0，系统极度危险。 - 看
Swap：如果used变大（比如这里用了 1.5G），说明物理内存不够用，被迫把数据搬到了硬盘。这会导致性能呈指数级下降。
第二步：揪出内存大户
还是用top，这次按M（大写）按内存排序。
或者使用这条命令直接找出 Top 5 的贪吃蛇：
ps-aux --sort=-%mem|head-n5可视化排查思路：
💽 场景三：报错“No space left on device”（磁盘满了）
症状速写：无法写入日志，程序报错退出，但用df查看好像还有空间（可能是 Inode 满了）。
第一步：宏观检查df
df-h输出示例：
Filesystem Size Used Avail Use% Mounted on /dev/sda1 40G 38G 2G 95% / <- 危险！根目录满了 /dev/sdb1 200G 50G 150G 25% /data第二步：精确打击du
知道/目录满了，但不知道是哪个子目录搞的鬼？一层层剥洋葱：
# 查看根目录下一级文件夹大小，并排序du-h --max-depth=1/|sort-hr输出示例：
3.5G /var/log <- 罪魁祸首 2.0G /usr 1.5G /opt ...发现/var/log占用最大，进去再执行du -h --max-depth=1 /var/log，就能定位到具体的日志文件。
第三步：查隐形杀手 Inode
如果df -h显示Use%正常，但依然报错磁盘满，请检查 Inode（文件节点数）：
df-i输出示例：
Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda1 262144 262100 44 100% / <- IUse% 100%，说明小文件太多撑爆了📝 总结：急救速查卡
建议收藏这张表，贴在工位旁，故障发生时照着敲：
| 故障现象 | 核心排查命令 | 关键指标 | 解决思路 |
|---|---|---|---|
| CPU 飙升 | top(按P) | %us> 80% 或load高 | 找到对应PID，排查死循环代码 |
| 内存溢出 | free -h | available接近 0 | 找内存占用最高的进程，检查配置 |
| Swap 飙升 | vmstat 2 | si/so频繁变动 | 说明物理内存不足，需加内存或优化 |
| 磁盘满 | df -h/du -sh | Use%= 100% | 清理日志文件或临时文件 |
| Inode 满 | df -i | IUse%= 100% | 清理海量小文件（如session碎片） |
写在最后：
学会这些命令，我们测试就不再是黑盒测试的“点点点”机器，而是具备了白盒排查能力的工程师。下次环境再挂，先把这串命令跑一遍，截图甩给开发，绝对是Bug定级的最强证据！
)
