Linux系统崩溃是多层问题传导结果，排查需按“系统状态→资源→服务→内核→硬件”顺序逐层下探，跳过任一层易误判；先确认是否真崩溃，再依序验证SSH可达性、ping连通性、控制台输出、资源占用、服务失败单元、内核日志及硬件健康。
Linux系统崩溃不是随机事件，而是资源、服务、日志、权限、硬件等多层问题传导的结果。排查的关键不在“用什么命令”，而在于“按什么顺序查”——跳过某一层，就容易把内存耗尽当成网络故障，或把内核 panic 误判为服务宕机。
先确认系统是否“真崩溃”
别一断连就默认系统挂了。先分清是“服务不可用”还是“系统失联”：
- 能 SSH 登录 → 系统活着，重点查资源占用、服务状态、应用日志
- SSH 超时但 ping 通 → 可能是 sshd 崩溃、端口被占、防火墙拦截，用 ss -tulnp | grep :22 验证
- ping 不通但带外管理（IPMI/iDRAC）可见控制台 → 进入控制台看是否卡在 GRUB、Kernel Panic 或黑屏；出现 “Out of memory”“IO error”“Kernel panic - not syncing” 是关键线索
从资源层开始逐层下探
90% 的“崩溃感”源于基础资源耗尽，优先验证再深入：
- CPU/内存：运行 top 或 htop，看 %CPU 是否持续 100%，RES 列是否有进程异常膨胀；free -h 关注 available 是否接近 0（注意 cached 高 ≠ 真缺内存）
- 磁盘空间：df -h 重点盯 /、/var、/tmp —— /var/log 打爆是高频原因
- I/O 压力：iostat -x 1（需 sysstat），持续 %util > 90% 或 await > 100ms 表明磁盘已成瓶颈
聚焦服务与内核级证据
资源正常？那就查系统是否“有组织地失败”：
- 失败服务：systemctl list-units --state=failed 一键列出所有崩溃单元，比翻日志快得多
- 内核事件：dmesg -T | grep -i "oom\|kill\|fail\|error" —— OOM Killer 日志、“Killed process” 后面跟着的就是被干掉的进程
- 启动上下文：用 journalctl -b -1 查上一次启动日志，journalctl --since "2026-03-07 10:00:00" 锁定故障时间窗，加 -p err..alert 只看错误及以上级别
排除硬件与配置干扰
软件层无明显异常？转向更底层的稳定性支撑：
- 硬盘健康：smartctl -a /dev/sda 检查 SMART 属性，关注 Reallocated_Sector_Ct、Current_Pending_Sector
- 内存问题：重启后进 memtest86+ 长时间测试；运行中可用 grep -i "hardware error" /var/log/messages 辅助判断
- 引导与挂载：若无法启动，尝试单用户模式；检查 /etc/fstab 是否存在非法条目导致挂载失败；lsblk 和 mount 确认设备识别与挂载状态
