一台双核服务器上，htop左上角的load average显示1.0。很多人会下意识地换算成"CPU用了一半"，然后放心地去做别的事。这个换算是错的——load average统计的不是CPU占用率，而是处于运行或等待运行状态的进程数，两者只在特定条件下才能对上。
这个误解流传很广，从Linux新手到干了多年运维的人都可能踩。原因也简单：htop和top展示的每一个字段，看起来都像是"性能百分比"，但它们背后其实是内核/proc文件系统里最原始的计数器，需要人自己做一层翻译。
load average到底在数什么
load average的三个数字来自/proc/loadavg，分别对应过去1分钟、5分钟、15分钟的平均负载。它统计的是两类进程：处于R状态（运行或排队等待CPU）和处于D状态（不可中断睡眠，通常是在等磁盘或网络IO）的任务数量。
这意味着一台机器完全可能CPU占用很低，但load average很高——一堆进程卡在磁盘IO上排队，CPU反而很闲。这也是原文只讲字段定义、没讲到的关键点：load高不等于CPU忙，得看是R在堆积还是D在堆积。
- 结论.load average高、CPU使用率低，大概率不是CPU瓶颈，而是IO等待或锁竞争堆积在D状态。
htop/top里进程状态列的字母含义也值得记住：R是可运行，S是可中断睡眠，D是不可中断睡眠（常见于等磁盘），Z是僵尸进程（已终止但父进程没回收），T是被任务控制信号暂停，t是被调试器暂停。T和t看起来像大小写变体，实际触发原因完全不同——一个是kill -STOP之类的信号，一个是gdb之类的调试器挂起。混着看容易误判进程到底卡在哪一步。
VIRT、RES、SHR别相加
内存字段里最容易踩坑的是VIRT和SHR。VIRT是进程申请的虚拟地址空间大小，很多时候远超实际物理内存占用，一个进程VIRT显示几个G很正常，不代表它真吃了那么多内存。RES是常驻物理内存，SHR是其中被多个进程共享的部分（比如动态链接库）。
SHR是RES的子集，不是额外叠加的内存量。把RES和SHR加起来当作"总占用"去估算内存压力，是个常见的算错方式，容易把服务器内存判断得比实际情况更紧张。
陌生服务器上，为什么老手先敲top而不是htop
htop交互体验更好，颜色分级、鼠标操作、树状视图都比top直观，日常排障用它效率更高。但top几乎是所有Linux发行版的标配，不需要额外安装。
在临时登录的陌生服务器、老旧生产环境、资源紧张的容器里，运维习惯先用top探个底，确认没问题再决定要不要装htop。这不是审美选择，是对"这台机器我到底有没有权限装东西、装了会不会影响性能"的保守判断。
会读一个数字是知识，会组合读多个数字才是排障能力。
还有一个尚未有定论的变量：容器化环境下，htop和top读到的load average、内存数据是否还准确。cgroup对CPU和内存做了限制，但/proc/loadavg这类文件在容器里读到的常常还是宿主机的全局数据，而不是容器自己的实际负载。这意味着在Kubernetes或Docker环境里，光看htop面板可能会得出和真实资源限制脱节的结论——这一点，还需要结合cgroup自身的统计文件交叉验证，不能只信一个界面。