1. 先搞清楚“操作系统缓存”到底在解决什么问题别再一提到缓存就只想到 Redis、Memcached 这些外部组件了。很多性能问题，尤其是高并发、大数据量读取的场景，真正的瓶颈可能不在应用层，而在你眼皮底下的操作系统。这篇文章不是要否定 Redis，而是想让你意识到，在引入任何外部缓存之前，应该先榨干操作系统自带的“隐形”缓存能力。这个“隐形缓存之王”指的就是操作系统的Page Cache（页缓存）和Buffer Cache（缓冲区缓存）。它们由 Linux 内核自动管理，核心作用是减少磁盘 I/O。当你的程序读取一个文件时，内核会把文件内容缓存在内存里；下次再读，就直接从内存返回，速度比从磁盘读取快几个数量级。对于写操作，数据也会先写入缓存，再由内核异步刷盘，提升响应速度。很多人迷信 Redis，一遇到“慢”就想着加 Redis 集群，却忽略了最基础的优化：让你的数据尽可能地被操作系统缓存命中。这适用于哪些场景？简单说，任何频繁读取静态或准静态数据的场景都适用，比如：热门的商品图片、CSS/JS 文件、视频切片（CDN 边缘节点原理与此类似）。频繁查询的数据库，如果查询模式固定且数据量小于内存，其数据文件本身就会被缓存。日志分析时对大量日志文件的顺序读取。最值得关注的点是：这是零成本的性能提升。你不需要安装、配置、维护额外的服务，只要理解它的工作原理并正确使用，就能获得巨大的收益。但滥用或误解，也会导致内存被无效数据占满，反而引发问题。2. 理解内核缓存机制：不是魔法，而是可观测、可调优的组件操作系统缓存不是黑盒魔法。在 Linux 下，我们可以清晰地观测和控制它。这比盲目调整 Redis 的maxmemory策略更有依据。2.1 核心机制：Page Cache 与 Buffer Cache简单区分：Page Cache：缓存文件内容（以内存页为单位）。比如你读一个data.json文件，内容就会进入 Page Cache。Buffer Cache：缓存磁盘块的元数据和部分内容（现在通常与 Page Cache 融合，统称 Page Cache）。比如文件系统的元数据（inode, directory entries）。对我们开发者而言，不必深究两者区别，只需知道：读写文件（包括数据库读写其数据文件）就是在和 Page Cache 打交道。2.2 如何观测缓存状态？使用free命令或cat /proc/meminfo：$ free -h total used free shared buff/cache available Mem: 15Gi 4.5Gi 2.3Gi 1.2Gi 8.2Gi 9.0Gi Swap: 2.0Gi 0.0Ki 2.0Gi关注buff/cache列，它显示了当前用于缓存的内存总量。available列则估算出可用于启动新应用的内存（已扣除缓存）。更详细的缓存信息在/proc/meminfo：$ cat /proc/meminfo | grep -E “(Cached|Buffers|Dirty|Writeback)” Cached: 8412348 kB # Page Cache 总量 Buffers: 244512 kB # Buffer Cache 量 Dirty: 1234 kB # 已被修改，待写回磁盘的缓存数据 Writeback: 88 kB # 正在
