tmpfs挂载是linux下安全、标准且内核原生支持的内存盘方案，需新建挂载点并显式配置应用使用路径，支持size限制和swap回退，避免oom；禁用ramfs因其无上限风险。
Linux下用tmpfs挂载内存盘作为缓存目录
直接用 tmpfs 挂载是唯一安全、标准且无需额外工具的方式。它由内核原生支持，数据纯驻内存，读写极快，且自动受内存压力调控——不会把系统拖死。
常见错误是试图“把已有目录硬塞进内存”，比如用 mount --bind 或符号链接指向 /dev/shm，这会导致权限错乱、应用写入失败或缓存失效。必须新建挂载点并确保应用明确使用该路径。
- 先创建空目录：
mkdir -p /mnt/cache - 临时挂载（重启失效）：
mount -t tmpfs -o size=2g,mode=1777 tmpfs /mnt/cache - 永久生效需写入
/etc/fstab，例如：tmpfs /mnt/cache tmpfs size=2g,mode=1777,uid=1001,gid=1001 0 0 - 确认挂载成功：
df -h /mnt/cache应显示 size 和 used 都是内存值，mount | grep cache能看到tmpfs类型
为什么不用ramfs而选tmpfs
ramfs 不做内存上限控制，一旦写爆就触发OOM killer杀进程；tmpfs 支持 size= 限制，并能在内存紧张时交换到swap（可禁用），更可控。
性能差异在现代内核中几乎可以忽略——两者都绕过块层，直写内存页。但 tmpfs 的可配置性决定了它才是生产环境的合理选择。
-
tmpfs允许设置size、nr_inodes、mode、uid/gid等关键参数 -
ramfs无法限制大小，也无 swap 回退机制，不适用于长期运行的服务 - 即使禁用 swap（
vm.swappiness=0），tmpfs仍会通过内存回收机制（LRU）释放不活跃页，而ramfs完全不会
应用如何正确使用这个内存缓存目录
不能指望系统自动把某类文件“迁入”内存盘——tmpfs 是独立文件系统，应用必须显式把缓存路径指向它。否则所有 I/O 还走 page cache + 磁盘路径。
典型场景如构建缓存（ccache）、Web 临时文件（PHP session.save_path）、日志缓冲区（rsyslog 的 WorkDirectory）都需要手动配置。
- 检查应用是否支持自定义缓存路径，优先改配置项（如
CCACHE_DIR=/mnt/cache/ccache） - 避免用
cp或rsync定期同步到tmpfs：这引入额外开销，且重启即丢，应让应用原生写入 - 若应用强制写固定路径（如
/var/cache/app），可用mount --bind替换，但必须确保目标目录为空且无进程占用，否则挂载失败或行为未定义 - 注意
tmpfs中的文件不经过 page cache，所以sync、fsync对其无效；数据丢失风险与断电强相关，不适合存关键中间状态
容易被忽略的三个实际约束
很多人挂上 tmpfs 就以为万事大吉，结果跑几天发现服务异常或内存告警——问题往往出在边界没设清。
-
size=是硬上限，但默认单位是字节；写成size=2G有效，size=2g（小写）会被内核忽略，退化为无限制 -
tmpfs占用的是MemAvailable范围内的内存，不是单独切一块；当系统整体内存吃紧时，它的页也会被回收，表现就是目录内容“变少”甚至清空 - 重启后
tmpfs内容全部丢失，若应用没做初始化逻辑（如自动重建缓存结构），首次启动可能报错或降级运行
