Buffer 是块设备I/O同步的元数据与裸设备数据缓存，Cache 是文件读取加速的page cache；二者功能不同、大小悬殊，且均属可回收内存，不应被free的used值误导。
Buffer 是块设备的“待办清单”，Cache 是文件数据的“常用抽屉”
Linux 中的 buffers 和 cached（准确说是 Cached 字段，对应 page cache）根本不是同类东西：前者专为**块设备 I/O 同步**服务，后者专为**文件读取加速**服务。你用 free -h 看到的 buffers 值通常很小（几 MB 到几十 MB），它只存两类东西：ext4 的 superblock、inode 表等元数据缓存，以及直接对裸设备（如 /dev/sda）write() 时暂存的原始块数据；而 Cached 可能占数 GB，它缓存的是你 cat 过的文本、grep 过的日志、vim 打开过的配置文件——所有通过 VFS 层读取的普通文件页。
别被 free 的 used 值吓到：Buffer 和 Cache 都算在“已用内存”里，但随时可被回收
这是最常引发误判的地方：free 输出的 used 包含了 buffers + cache，但它不等于“程序正在争抢的内存”。只要进程申请新内存，内核会立刻把 page cache（Cached）里的冷页踢掉——哪怕 free 显示 “available: 200M”，只要 Cached 还有 4GB，系统就几乎不会 OOM。真正危险的是 MemAvailable 持续低于 100MB 或 SwapUsed 快爆了。常见错误现象：free 显示 “used 90%” 就去杀进程，结果发现 top 里没几个大进程——大概率是 cache 占着，但完全无害。
drop_caches 不是“清内存”，而是“清缓存预期”，慎用
执行 echo 3 > /proc/sys/vm/drop_caches 并不会释放 buffer（它只清 page cache + dentries/inodes），也不会让系统变快；相反，下次你 ls /var/log 或 tail -f /var/log/syslog 会明显变慢，因为刚清掉的缓存要重新加载。它的合理使用场景极窄：
• 做 I/O 性能压测前，确保 cache 不干扰基准值
• 排查某个进程是否真因内存不足卡顿（先 drop 再观察）
• 调试 page cache 相关内核行为
日常运维中手动触发基本等于自找麻烦。顺带一提：drop_caches 默认是关闭的（/proc/sys/vm/drop_caches 值为 0），写入后不会持久化，重启即失效。
看懂 /proc/meminfo 才算真正看懂内存
free 是个简化视图，关键细节藏在 /proc/meminfo 里：
• Buffers: 真实的 buffer 大小（单位 kB），对应块设备层缓存
• Cached: page cache 主体（不含 slab）
• SReclaimable: 可回收的 slab 对象（如 dentry、inode 缓存），和 Cached 一起构成广义 cache
• MemAvailable: 内核估算的“此刻可立即分配给新进程的内存”，比 free + buffers + cached 更靠谱
一个典型误操作：用 awk '/^Cached:/ {print $2}' /proc/meminfo 当作“可用内存”，却忽略了 SReclaimable 和 MemAvailable 的存在——这会让你低估系统真实余量。
Buffer 和 Cache 的边界在现代 Linux（5.4+）里其实越来越模糊，比如某些元数据也会进 page cache；但理解它们最初的设计意图（buffer 保写一致性，cache 保读性能），才能在 vmstat 1 看到 bi/bo 突增时，快速判断是磁盘写风暴还是文件遍历导致的 cache 淘汰压力。
