tmpfs 的重启清空是设计特性而非缺陷，适用于临时性、高性能、不落盘场景；需根据数据持久性需求选择 Volume 或 Bind Mount，而非强行绕过清空机制。
这个特性不是“问题”，而是 tmpfs 的设计目标——它本就应该重启即清空。你不需要去“解决”它，而是要确认：你真的该用 tmpfs 吗？
先判断是否选错了存储类型
tmpfs 的核心价值就是临时性+高性能+不落盘。如果你希望数据在容器重启后依然存在，那它从一开始就不适用。
- 数据库数据、用户上传文件、配置变更记录 → 必须用 Volume
- 本地开发时实时同步代码、共享宿主机日志目录 → 用 Bind Mount
- 会话缓存、临时编译中间产物、密钥文件（只读加载）→ 才是 tmpfs 的正确场景
如果确实需要“重启保留”，但又想保留内存速度，可以折中
没有纯内存方案能自动跨重启保留数据，但你可以组合使用：
- 把高频读写的热数据放 tmpfs（如 /app/cache），同时用 Volume 持久化冷数据或快照（如 /app/data）
- 应用启动时，从 Volume 加载初始状态到 tmpfs；退出前，将关键状态回写到 Volume（需代码配合）
- 对极小量配置类数据，改用环境变量或 ConfigMap（K8s）/ --env-file（Docker）注入，避免挂载
别被“清空”吓到，这恰恰是它的安全优势
比如你往 /run/secrets 加载密钥，或把 session 存在 /dev/shm，容器一停，内存里连痕迹都不留——这比误写进磁盘更可靠。很多合规要求（如 PCI DSS）明确鼓励这种做法。
强行绕过清空机制（例如用 init 容器 dump 内存、或挂载 hostPath 到 RAM 目录），反而破坏隔离性、引入竞态和权限风险。
