Buffer是块设备的待办清单，存未写盘的原始块数据；Cache是文件数据的速查手册，存已读入的文件内容页；二者分属block layer和page cache子系统。
Buffer 是块设备的“待办清单”，Cache 是文件数据的“速查手册”
Buffer 存的是还没写进磁盘的原始块（block）数据，比如文件系统元数据（superblock、inode）、或进程刚 write() 过但还没刷盘的脏页；Cache 存的是已经从磁盘读上来的文件内容页（page），供后续 read() 快速命中。二者都走内核内存管理，但归属不同子系统：Buffer 属于 block layer，Cache 属于 page cache（即文件系统层）。
- 你执行
dd if=/dev/zero of=test bs=4k count=1000后立刻看free -h，Buffers会上升，Cached不一定变——因为数据还在缓冲区，没真正落盘也没被当作“文件内容”缓存 - 你用
cat largefile > /dev/NULL读一遍大文件，Cached显著增长；再读一次，time cat largefile > /dev/null耗时明显下降——这就是 page cache 在起作用 -
/proc/meminfo中的Buffers值通常很小（几 MB 到几十 MB），而Cached可达数 GB，尤其在空闲内存多时会自动膨胀
别信 free 的 “used” —— Buffer 和 Cache 都算进去，但它们不是“被占着不放”的内存
linux 内核的设计哲学是：“有空闲就拿来缓存，有需要就立刻让出”。所以 free -h 输出里的 used 包含了 Buffers + Cached + 应用实际占用，但这不等于内存紧张。只要 Available 列数值健康（大于几百 MB），就说明系统随时能腾出足够内存给新进程。
- 老版本
free（如 procps-ng Available，只靠free和cached容易误判——这是最常踩的坑 -
Buffers在内存压力下几乎不会被回收（它关联着 pending I/O），而Cached会在OOM前被大量回收，优先级更低 - 观察真实压力请看
cat /proc/meminfo | grep -E "^(MemAvailable|Buffers|Cached|SReclaimable)"，注意SReclaimable（slab 可回收部分）也属于广义 cache
手动清理？只在调试或基准测试时做，且必须分清 drop_caches 级别
生产环境禁止无脑执行 echo 3 > /proc/sys/vm/drop_caches。这不是“释放内存”，而是强制丢弃本可加速 I/O 的缓存，会导致后续读写性能骤降。
-
echo 1 > /proc/sys/vm/drop_caches：只清Page Cache（即Cached主体），不影响 Buffer -
echo 2 > /proc/sys/vm/drop_caches：只清Buffers（即块设备缓冲区），实际极少用，因 Buffer 通常很快自动刷盘 -
echo 3 > /proc/sys/vm/drop_caches：清两者，等价于1+2，但会连带清掉部分slab缓存（如 dentry/inode），副作用更大 - 执行前确认已同步脏页：
sync && echo 3 > /proc/sys/vm/drop_caches，否则可能丢数据（尤其在echo 2时）
监控和排障时，盯住 /proc/meminfo 而非 free 的表头文字
free 是个友好封装，但它的列名容易误导人。“buffers” 和 “cached” 在不同内核版本含义略有漂移，而 /proc/meminfo 字段定义稳定、无歧义。
-
Buffers= 块设备层缓冲区（raw block I/O metadata + pending writes） -
Cached=page cache数据页（不含 slab），即文件内容缓存主体 -
SReclaimable= slab 中可安全回收的部分（如dentry,inodecache），也属于广义缓存，但free不单独列出 - 真要判断是否缺内存，看
MemAvailable；怀疑缓存污染或测试冷启动性能，才看Buffers与Cached的变化趋势
Buffer 和 Cache 的边界在现代内核中越来越模糊（比如某些元数据也进 page cache），但理解它们最初的设计意图——一个为“写聚合”，一个为“读加速”——比死记字段值更重要。运维时最该警惕的，从来不是数字本身，而是数字背后那个没被 sync 的 Buffer。