tmpfs 是专为临时存储设计的内存文件系统，数据随容器停止而清空，不可用于持久化；需严格区分 tmpfs、volume 和 bind mount 的用途，避免路径冲突，并通过应用层机制实现临时数据的跨重启恢复。
tmpfs 本身的设计目标就是“临时性”——数据只存内存，容器一停就清空。它和“持久化”不是一对矛盾，而是分工明确：你需要持久化的数据，就不该放 tmpfs；需要临时、高速、安全的存储，才用 tmpfs。关键在于别混用、别误用。
明确 tmpfs 的定位：不为持久，只为临时
tmpfs 是内存文件系统，生命周期绑定容器运行时。重启、停止、重建容器，里面的数据必然消失——这不是缺陷，是特性。所以解决“冲突”的第一步，是放弃让 tmpfs 自己持久化的想法。
- 敏感临时数据（如 token、session cache）适合放 tmpfs，清空反而是安全优势
- 日志、上传文件、数据库状态等必须保留的数据，绝不能写入 tmpfs 挂载路径
- 若应用默认往 /tmp 写关键数据，应修改其配置，指向 volume 或 bind mount 路径
正确分离挂载路径，避免静默覆盖
常见错误是把 tmpfs 和 volume 挂到同一个容器目录（比如都挂 /tmp），结果后加载的 tmpfs 直接覆盖 volume，导致原有数据“看不见”。Docker 不报错，但数据已不可访问。
- 检查 docker run 或 docker-compose.yml，确保同一路径只有一种挂载类型
- 推荐做法：/tmp 用 tmpfs（临时缓存），/app/data 用 volume（用户数据），/app/config 用 bind mount（可编辑配置）
- 在 compose 中显式区分：tmpfs 字段只用于内存临时目录，volumes 字段专用于持久数据
需要“类 tmpfs 性能 + 持久化”？换方案，不硬改
如果业务既要高速读写，又要重启不丢数据，说明你真正需要的不是 tmpfs，而是高性能持久层：
- 用 volume + SSD 存储：Docker volume 本身支持挂载到高性能本地盘或 NVMe 设备，I/O 延迟远低于传统 HDD
- 对极敏感场景，可结合 加密 volume（如使用 LUKS 封装的宿主机目录）+ 容器内定期 dump 到 tmpfs 做加速缓存
- 数据库类服务（MySQL、PostgreSQL）必须用 volume，并启用 WAL 日志与定期备份，而非依赖 /tmp 存状态
真要“保 tmpfs 数据”？只能靠外部机制兜底
极端情况下，若某些临时数据确实需跨重启恢复（如预热缓存），只能靠应用层主动管理：
- 容器启动时，从 volume 或远程存储（如 Redis、S3）自动加载初始缓存到 tmpfs
- 运行中定时将 tmpfs 中的关键缓存快照写回 volume（注意加锁防竞态）
- 利用 entrypoint 脚本实现“恢复-运行-备份”闭环，而不是指望 tmpfs 自身持久
