btop 快速上手总览
1. 先记住一句话
btop 是一个终端里的系统资源仪表盘。日常使用时，你只需要先看四件事：CPU 是否满、内存是否吃紧、磁盘是否忙、哪个进程最可疑。
2. 最短上手路径
第一步：启动
btop如果没有安装：
brew install btop第二步：只看四块区域
| 区域 | 先看什么 | 用来判断什么 |
|---|---|---|
| CPU | 总占用、单核是否打满、负载趋势 | 是否计算压力大、是否单线程瓶颈 |
| MEM | used、available、swap | 是否内存吃紧、是否开始换页 |
| DISK | 读写速率、磁盘忙碌趋势 | 是否 IO 卡住 |
| PROC | CPU%、MEM%、命令名 | 哪个进程最消耗资源 |
第三步：用排序找到元凶
进入 btop 后，重点掌握：
- 按
p：进程按 CPU 排序。 - 按
m：进程按内存排序。 - 按
/：搜索进程名。 - 方向键或鼠标滚轮：移动进程列表。
- 按
q：退出。
只掌握这几个键，就能覆盖绝大多数日常排障。
3. 80% 高频场景
场景一：电脑突然变卡
优先判断顺序：
- 看 CPU 总占用是否长期接近 100%。
- 看某个单核是否长期打满。
- 按
p找 CPU 最高的进程。 - 如果 CPU 不高，再看内存和磁盘。
常见结论：
- CPU 高：通常是编译、索引、压缩、视频处理、异常循环。
- 单核高：可能是单线程任务卡住。
- CPU 不高但仍然卡：继续看内存、swap、磁盘 IO。
场景二：内存快满了
优先看：
- MEM 区域的 used 和 available。
- swap 是否明显增长。
- 按
m找内存占用最高的进程。
常见结论：
- available 还多：不一定有问题，系统缓存会占内存。
- swap 增长明显：说明物理内存可能不够，系统会变慢。
- 某个服务持续涨内存：可能是泄漏或缓存无限增长。
场景三：磁盘或数据库很慢
优先看：
- DISK 区域的读写速率。
- 是否持续高写入或高读取。
- 结合 PROC 看数据库、Docker、日志进程是否活跃。
常见结论：
- 高写入：日志、数据库、构建产物、下载任务可能较多。
- 高读取：索引、扫描、备份、数据库查询可能较多。
- CPU 和内存都不高但系统卡：磁盘 IO 是高概率嫌疑。
场景四：本地开发服务占资源
常用操作：
- 按
/搜索服务名，比如java、node、mysql、docker。 - 看该进程的 CPU%、MEM%。
- 再结合端口或日志确认它是不是当前项目服务。
常见判断：
- Java CPU 高：可能是编译、GC、死循环、批任务。
- Java 内存高：看是否符合 JVM 参数预期。
- Docker 相关进程高：可能是容器内服务导致，不一定是 Docker 本身的问题。
4. 先别学什么
刚上手 btop 时，先不要纠结：
- 每个颜色代表的精确定义。
- 所有设置项。
- 主题美化。
- 网络每个字段的细节。
- 进程信号操作。
这些属于后 80% 的低频知识。先把观察、排序、搜索、判断链路练熟更重要。
5. 一个实用判断公式
遇到机器卡顿时，按这个顺序看：
CPU 高？
是：按 CPU 排序找进程
否：看内存
内存吃紧或 swap 增长？
是：按内存排序找进程
否：看磁盘
磁盘读写高？
是：找数据库、日志、构建、Docker 相关进程
否：再看网络或具体应用日志6. 常见误区
| 误区 | 正确理解 |
|---|---|
| 内存 used 高就一定有问题 | 不一定，系统缓存也会占用内存，重点看 available 和 swap |
| Docker 进程高就是 Docker 坏了 | 不一定，可能是容器里的服务在消耗资源 |
| CPU 瞬间 100% 就是故障 | 不一定，持续高占用才更值得关注 |
| btop 能直接告诉根因 | btop 负责定位方向，根因还要结合日志、代码、命令进一步确认 |
7. 推荐日常习惯
- 本机变卡时，先开 btop，不要急着重启。
- 先按 CPU 排序，再按内存排序。
- 发现可疑进程后，再去看日志或项目启动参数。
- 观察趋势，不要只看一瞬间的数字。