tmpfs将/tmp等路径完全映射至内存，零落盘、无写放大；overlay2则强制写入upperdir，触发copy-on-write并持续磨损ssd/emmc。关键区别在于写入目标是否落盘，而非能否写入。
tmpfs 挂载和 overlay2 可写层在处理临时文件时路径看似相同（比如都写入 /tmp），但底层行为截然不同：前者绕过磁盘、零写入闪存；后者触发 copy-on-write，持续磨损 ssd/emmc。关键区别不在“能不能写”，而在“写到哪里、是否落盘”。
tmpfs：内存即存储，彻底避开 overlay2 写放大
使用 --tmpfs /tmp:rw,size=64m 启动容器后，所有对 /tmp 的读写操作都发生在主机内存中：
- 不经过
/var/lib/docker/overlay2/<id>/upper</id>，完全跳过 overlay2 的 upperdir 写入流程 - 无 copy-on-write 开销，不复制镜像层中的同名文件，也不生成 whiteout 文件
- 容器退出后自动清空，无残留、无垃圾回收压力
- 即使应用反复创建/删除千个小文件，宿主机磁盘 I/O 计数器（如
iostat -x中的 %util）几乎无变化
overlay2 可写层：看似方便，实为高频写盘陷阱
若未挂载 tmpfs，容器内任何写入 /tmp、/var/log 或工作目录的行为，都会落入 overlay2 的 upperdir：
- 首次写
/tmp/cache.bin：overlay2 复制基础镜像中可能存在的同名路径（哪怕为空），再写入 upperdir —— 一次小文件写 + 元数据更新 - 追加日志或轮转缓存：每次
open()+write()+close()都可能触发 fsync，默认策略下强制刷盘，加剧写放大 - 频繁修改同一文件：upperdir 中持续覆盖，但旧数据块不会立即回收，占用额外闪存页
- 容器重启后，upperdir 仍保留，下次启动继续沿用 —— 数据未清理，磨损已发生
性能与寿命影响的量化差异
以一个每秒生成 50 个 4KB 临时日志文件的微服务为例（运行 1 小时）：
- tmpfs 方式：内存分配约 2MB，磁盘写入量 ≈ 0 KB，SSD 写入寿命损耗可忽略
- overlay2 默认方式：实际落盘量常达 15–30MB（含元数据、journal、copy-on-write 副本），eMMC 设备在长期部署中可能提前出现坏块
- 叠加 journal 日志（如 systemd-journald 默认启用）：overlay2 场景下额外增加 8–12MB/小时写入，而
--tmpfs /run/log/journal可直接归零
选型不是非此即彼，而是分层隔离
生产环境不建议全盘禁用 overlay2，而应按数据属性分流：
-
纯临时、可丢弃（如 session 缓存、编译中间产物）→
--tmpfs，大小按峰值预估（例：size=128m） -
需保留但非强一致性（如应用级缓存、离线队列）→ named volume + ext4
noatime,nodiratime挂载 - 必须持久、强一致（如数据库 WAL、配置快照）→ 绑定宿主机路径或专用块设备，绕过联合文件系统
- 日志输出→ 不落容器内文件，走 stdout/stderr 或 syslog，由 Docker 日志驱动统一处理
