Appearance
Linux 进程、端口与资源查看:top、netstat、lsof 实用组合
更新: 8/23/2026 字数: 0 字 时长: 0 分钟
开篇:这些坑,你大概率都踩过
作为前端/JS 全栈开发者,你不必成为运维专家,但下面这些场景,你几乎一定遇到过:
npm run dev启动报错EADDRINUSE: address already in use :::3000,你只想知道到底是谁占了这个端口,然后干掉它;- 线上 Node 服务突然变慢,监控告警 CPU 飙到 100%,你 SSH 上去却不知道从哪查起;
- Node 进程内存越跑越大,怀疑内存泄漏,想确认到底吃了多少;
- 服务日志说连不上数据库,你想确认这个进程到底建立了哪些网络连接。
这些问题的答案,几乎都藏在三个命令里:top(看资源)、netstat(看端口和连接)、lsof(看进程打开了什么)。它们就像你排查线上问题时的"F12 开发者工具"——单独用能解决一部分,组合起来用才能从现象一路追到根因。本文只讲和 Web 开发强相关的高频用法,不深挖运维底层。
三者的分工可以一图看清:
核心思路:先确定现象类型,选对入口命令,拿到关键的 PID(进程 ID),再用另外两个命令交叉验证。 PID 就是串起这三个命令的"主键"。
一、top:实时看谁在吃 CPU 和内存
top 是最常用的资源监控命令,直接敲 top 回车,就进入一个每几秒刷新一次的实时面板。对前端来说,重点看两块:顶部的系统概览和下方的进程列表。
关键指标怎么看
顶部第一行的 load average(如 load average: 0.8, 1.2, 1.5)是过去 1/5/15 分钟的平均负载。经验判断:这个数字如果长期超过你的 CPU 核心数,说明系统在过载。比如 4 核机器负载稳定在 8,就是明显吃紧了。
进程列表里,前端最该盯的三列:
| 列名 | 含义 | 前端场景 |
|---|---|---|
%CPU | 该进程占用的 CPU 百分比 | Node 服务死循环、正则回溯会飙到 100%+ |
%MEM | 占用物理内存百分比 | 内存泄漏时会持续增长 |
RES | 实际占用的物理内存大小 | 看 Node 进程真实吃了多少内存 |
高频交互按键(进入 top 后直接按)
bash
top # 启动 top
# 进入后按这些键(区分大小写):
# P → 按 CPU 使用率排序(找 CPU 杀手,默认就是它)
# M → 按内存使用率排序(找内存大户)
# c → 显示进程的完整启动命令(能看清是哪个 node 脚本)
# k → 输入 PID 杀掉进程
# q → 退出一个实用参数:只看某个特定进程(比如你只关心 Node):
bash
top -p 12345 # 只监控 PID 为 12345 的进程小提示:
top里的%CPU可能超过 100%,因为它是按"单核 100%"计算的。多核机器上一个进程占满 2 个核,就会显示 200%,这是正常的,不是 bug。
二、netstat:看端口和网络连接
netstat 用来回答"哪些端口被监听了、哪些网络连接正在进行"。对前端最有价值的就是排查端口占用。
黄金组合参数:-tulnp
这五个字母是前端最该背下来的组合:
bash
netstat -tulnp
# -t 显示 TCP 连接
# -u 显示 UDP 连接
# -l 只看正在监听(listening)的端口 —— 找"谁开着服务"就靠它
# -n 用数字显示地址和端口(不做 DNS 反解,更快更清晰)
# -p 显示占用端口的进程 PID 和名字 —— 关键!直接告诉你是谁输出里你会看到类似这一行:
tcp6 0 0 :::3000 :::* LISTEN 12345/node翻译一下:PID 为 12345 的 node 进程,正监听在 3000 端口。占用 3000 端口的元凶,一目了然。
查看具体某个端口
配合 grep 精确定位(前端最常用):
bash
netstat -tulnp | grep 3000 # 谁占用了 3000 端口?
netstat -anp | grep ESTABLISHED # 看当前所有已建立的连接(排查连接数过多)三、lsof:进程到底打开了什么
lsof = list open files。在 Linux 哲学里"一切皆文件",所以端口、网络连接、日志文件、socket 全都算"打开的文件"。它是排查端口占用最直接的工具。
前端最高频的一条命令
bash
lsof -i :3000
# -i :3000 查看占用 3000 端口的进程输出直接给出 COMMAND、PID、USER,比 netstat 更聚焦。拿到 PID 后一键干掉:
bash
kill -9 $(lsof -t -i:3000)
# lsof -t 只输出 PID(方便传给 kill)
# -9 强制杀死
# 一行命令:释放被占用的 3000 端口(前端救命神器)其他实用姿势
bash
lsof -p 12345 # 看 PID 12345 这个进程打开了哪些文件/连接
lsof -i tcp # 看所有 TCP 相关的打开项
lsof -u $(whoami) # 看当前用户打开的所有文件
lsof +D /var/log # 看某个目录下被哪些进程占用的文件(排查"文件删不掉")四、组合技:从现象到根因的完整实战
单个命令是"点",组合起来才是"线"。下面是三个高度还原真实开发的场景。
场景 1:端口被占,启动失败(最高频)
现象:npm run dev 报 EADDRINUSE :::3000。
bash
# 第一步:找出占用 3000 端口的进程
lsof -i :3000
# 输出示例:COMMAND=node PID=12345
# 第二步:确认这个进程到底是什么(避免误杀)
ps -p 12345 -o pid,command
# 看清是不是你上次没关干净的 dev server
# 第三步:确认无误后干掉它
kill -9 12345
# 或一步到位:
kill -9 $(lsof -t -i:3000)关键在第二步先确认再杀,别盲目 kill -9,以免误杀了别的重要服务。
场景 2:线上 Node 服务 CPU 飙高
现象:告警 CPU 100%,页面响应慢。
bash
# 第一步:top 找出吃 CPU 的进程,按 P 排序,记下 PID(假设是 12345)
top
# 看到 node 进程 %CPU 高达 180%
# 第二步:确认这个进程是哪个服务、监听什么端口
lsof -p 12345 | grep LISTEN
# 或用 netstat 反查
netstat -tulnp | grep 12345
# 确认是哪个业务服务在异常
# 第三步:看它建立了哪些连接(排查是不是被刷/死循环调用外部)
lsof -p 12345 -i
# 若发现大量对某个外部地址的连接,可能是重试风暴或被攻击这套组合能帮你快速回答:是哪个服务、对外开着什么端口、正在和谁通信——定位方向立刻清晰。
场景 3:怀疑内存泄漏 / 连接数暴涨
现象:Node 进程内存持续增长,或数据库连接数报警。
bash
# 第一步:top 按 M 排序,盯住目标进程的 RES,观察是否持续上涨
top -p 12345 # 只盯这个进程,看 RES 是否只增不减
# 第二步:看它到底建立了多少条连接(连接泄漏最常见)
lsof -p 12345 -i | wc -l # 统计该进程的网络连接总数
netstat -anp | grep 12345 | grep ESTABLISHED | wc -l # 已建立连接数
# 第三步:按状态分类统计连接(排查 CLOSE_WAIT 堆积——典型的连接没关)
netstat -anp | grep 12345 | awk '{print $6}' | sort | uniq -c
# 若看到大量 CLOSE_WAIT,基本可断定代码里连接没有正确关闭CLOSE_WAIT 大量堆积,是 Node 后端"忘记关闭数据库/HTTP 连接"的经典信号,这个组合能一眼看穿。
五、拓展:更现代的工具与 Docker 注意事项
ss:netstat 的现代替代品
很多新系统默认不再预装 netstat(它属于已废弃的 net-tools),取而代之的是 ss(socket statistics),用法几乎一样但更快:
bash
ss -tulnp # 等价于 netstat -tulnp,查看监听端口
ss -tnp | grep 3000 # 查看 3000 端口相关连接
ss -s # 快速看连接数统计摘要建议:遇到 netstat: command not found 时,直接换成 ss,参数照抄即可。
htop:更好用的 top
htop 是 top 的增强版,彩色界面、支持鼠标点击、可视化每核 CPU 占用,对不熟悉命令行的前端更友好:
bash
htop # 若没有,用 apt install htop / brew install htop 安装
# 支持方向键选中进程、F9 杀进程、F6 排序,无需记快捷键Docker 环境下的关键注意事项
如果你的 Node 服务跑在容器里,直接在宿主机上查会对不上号,这是前端最容易困惑的点:
- 宿主机
top看到的进程名可能不是你熟悉的样子,且容器内的 PID 和宿主机 PID 不同。推荐直接用 Docker 命令:
bash
docker stats # 实时看每个容器的 CPU/内存/网络占用(最直观)
docker top <容器名> # 看某个容器内部的进程列表
docker exec -it <容器名> sh # 进容器内部,再用 top/lsof(需容器内装了这些工具)- 端口要区分"容器内端口"和"宿主机映射端口"。容器内服务监听 3000,但宿主机可能映射到 8080。在宿主机上应查映射后的端口:
bash
docker port <容器名> # 查看容器的端口映射关系
lsof -i :8080 # 查宿主机上映射出来的端口- 精简镜像(如 alpine)里往往没有
top/lsof/netstat,进容器发现命令不存在很正常,可临时安装(apk add procps lsof)或直接用宿主机的docker stats。
六、高频排查场景速查清单
收藏这份清单,遇到问题照着抄:
bash
# ========== 端口占用(前端最高频) ==========
lsof -i :3000 # 谁占用了 3000 端口
kill -9 $(lsof -t -i:3000) # 一键释放 3000 端口
netstat -tulnp | grep 3000 # 备选:用 netstat 查
ss -tulnp | grep 3000 # 备选:新系统用 ss
# ========== CPU / 内存异常 ==========
top # 进入后按 P 排 CPU,按 M 排内存
top -p <PID> # 只盯某个进程
htop # 更友好的可视化版本
# ========== 网络连接排查 ==========
netstat -tulnp # 看所有监听端口 + 对应进程
lsof -p <PID> -i # 看某进程建立的所有网络连接
netstat -anp | grep <PID> | awk '{print $6}' | sort | uniq -c # 按连接状态统计
# ========== 进程详情 ==========
lsof -p <PID> # 某进程打开的所有文件/连接
ps -p <PID> -o pid,command # 确认进程的完整启动命令(杀之前先确认)
# ========== Docker 环境 ==========
docker stats # 各容器资源占用
docker top <容器名> # 容器内进程
docker port <容器名> # 端口映射关系一句话方法论:先用 top 或 lsof/netstat 抓到 PID,再拿 PID 交叉查资源、端口、连接,三者互为印证,现象就能追到根因。 把这三个命令练成肌肉记忆,你处理线上服务问题的底气会完全不一样。