3、基础检查清单：网络连通性、端口监听、进程存活、CPU/内存使用率
服务无响应了，别慌。
我个人的习惯是，先做一轮「基础四连」检查。说白了，就是看看网络通不通、端口开没开、进程在不在、资源够不够。这四个点，能筛掉至少 70% 的常见故障。
你想想看，很多时候问题其实没那么复杂。可能就是网络断了，或者进程挂了，结果我们绕了一大圈去查代码。嗯，先做基础检查，这是性价比最高的操作。
3.1 网络连通性：先确认「路」通不通
服务无响应，第一个要排除的就是网络问题。我遇到过好几次，大家围着服务器查了半天，最后发现是网线松了。尴尬不？
怎么查？
- ping 命令：最直接。从客户端 ping 服务端 IP，看丢包率和延迟。
- telnet 或 nc：ping 通不代表端口通。用
telnet IP 端口或nc -vz IP 端口测试。 - traceroute：如果 ping 不通，用这个看路由在哪断了。
核心要点：
网络连通性检查，不只是看 ping。ping 通只说明 ICMP 协议通，不代表应用层端口通。我建议你养成习惯：先 ping，再 telnet。
# 检查网络连通性
ping -c 4 192.168.1.100
# 检查端口是否可达
telnet 192.168.1.100 8080
nc -vz 192.168.1.100 8080
# 路由追踪
traceroute 192.168.1.100我的小技巧：
如果 ping 通但 telnet 不通，别急着怀疑防火墙。先看看服务端本机能不能连自己的端口。有时候是服务根本没监听。
3.2 端口监听：服务「开门」了没？
网络通了，接下来看端口。服务要对外提供服务，必须有一个端口在监听。如果端口没开，客户端当然连不上。
怎么查？
- ss 命令：现代 Linux 推荐用
ss -tlnp。比 netstat 快，信息也更全。 - netstat 命令：老牌工具，
netstat -tlnp也能看。 - lsof 命令：
lsof -i :端口号，看哪个进程占用了端口。
注意：
我曾经遇到过一个情况，端口明明在监听，但客户端就是连不上。查了半天，发现服务只监听了 127.0.0.1，没监听 0.0.0.0。所以，看端口监听时，一定要看它绑定的 IP 地址。
# 查看所有监听中的 TCP 端口
ss -tlnp
# 查看特定端口（比如 8080）
ss -tlnp | grep 8080
# 用 netstat 查看
netstat -tlnp | grep 8080
# 用 lsof 查看端口占用
lsof -i :8080重点关注：
看 LISTEN 状态。如果端口状态是 LISTEN，说明服务在正常监听。如果是 CLOSE_WAIT 或 TIME_WAIT，那是连接关闭的问题，不是端口监听的问题。
3.3 进程存活：服务「活着」吗？
端口在监听，不代表进程就健康。有时候进程卡死了，端口还在，但已经不处理请求了。所以，我们要确认进程确实在运行，而且状态正常。
怎么查？
- ps 命令：
ps -ef | grep 进程名，看进程是否存在。 - top 或 htop：看进程的实时状态，是不是在运行（R）、睡眠（S）、还是僵尸（Z）。
- systemctl status：如果服务是用 systemd 管理的，直接
systemctl status 服务名。
我的经验：
用 ps -ef 看到进程在，不代表它活着。我遇到过进程变成「僵尸」状态，PID 还在，但已经不干活了。这时候要看 top 里的状态列，如果是 Z，那就是僵尸进程，需要 kill 掉父进程才能清理。
# 查看进程是否存在
ps -ef | grep nginx
# 查看进程状态（R=运行，S=睡眠，Z=僵尸）
top -bn1 | grep nginx
# 用 systemd 查看服务状态
systemctl status nginx避坑指南：
我曾经用 ps -ef | grep java 查到进程在，就以为服务正常。结果发现是旧版本的进程没杀掉，新版本根本没启动。所以，我建议你同时检查进程的启动时间和 PID，确认是你要的那个进程。
3.4 CPU/内存使用率：资源够不够？
网络通、端口开、进程在，但服务还是慢？那多半是资源不够了。CPU 跑满、内存耗尽，服务自然无响应。
怎么查？
- top 命令：看整体 CPU 和内存使用率，以及每个进程的资源占用。
- free 命令：专门看内存使用情况，
free -h以人类可读格式显示。 - vmstat 命令：看系统整体的 CPU、内存、IO 状况。
- uptime 命令：看系统负载（load average），快速判断系统是否过载。
核心指标：
| 指标 | 正常范围 | 告警阈值 |
|---|---|---|
| CPU 使用率 | < 70% | > 90% |
| 内存使用率 | < 80% | > 90% |
| 系统负载 (load) | < CPU 核心数 | > CPU 核心数 * 1.5 |
| Swap 使用率 | 0 | > 0 |
# 查看 CPU 和内存使用率
top
# 查看内存使用情况
free -h
# 查看系统负载
uptime
# 查看 CPU 核心数
nproc我的判断方法：
如果 CPU 使用率 100%，但 load average 不高，说明 CPU 在密集计算，可能只是某个任务占满了。如果 load average 很高（比如 4 核 CPU，load 到了 8），说明系统在排队，大量进程在等待 CPU，这时候服务肯定会变慢。
另外，内存不够时，系统会开始用 Swap。一旦 Swap 开始被使用，性能会急剧下降。我建议你监控 Swap 使用率，只要大于 0，就要警惕了。
避坑指南：
我曾经遇到一个情况，CPU 和内存看起来都正常，但服务就是慢。后来发现是磁盘 IO 满了。所以，资源检查不能只看 CPU 和内存，还要看磁盘 IO 和网络带宽。不过那是后面章节的内容了，这里先记住：CPU 和内存只是基础，不是全部。
好了，基础检查清单就这些。网络连通性、端口监听、进程存活、CPU/内存使用率，这四个点，你每次排查服务无响应问题时，都应该先过一遍。我敢说，大部分问题在这一步就能定位到原因。
下一章，我们会深入聊一聊日志分析。毕竟，基础检查只能告诉我们「出了什么问题」，而日志能告诉我们「为什么出问题」。