秒级销毁的内存执行环境需精准控制tmpfs挂载路径、大小（如/tmp设100m、/run设32m、/app/cache按需设64m–128m）及安全策略（必加noexec,nosuid），禁用size将致内存耗尽oom。

直接用 tmpfs 搭建秒级销毁的内存执行环境，核心不是“堆内存”，而是精准控制挂载路径、大小和安全策略，让临时数据只活在内存里，容器一停就清空，不残留、不落盘、不争资源。

明确哪些目录适合 tmpfs 匿名执行

不是所有路径都适合。真正需要“秒级销毁+高并发响应”的场景，集中在三类路径：

• /tmp：通用临时文件（如编译中间产物、上传解压缓存），建议 size=100m，noexec,nosuid 强制启用
• /run：进程运行时状态（socket、pid 文件、健康探针缓存），建议 size=32m，只读可选 ro，避免误写
• /app/cache 或 /var/cache/xxx：应用专属缓存（如模板编译结果、API 响应压缩缓冲），按实际峰值预估，例如 64m–128m

必须显式设置 size，否则等于开闸放水

默认不设 size 时，Linux 内核将允许 tmpfs 占用物理内存的 50%，高并发下多个容器同时写入 /tmp，几秒内就能吃光主机内存，触发 OOM Killer 杀死随机进程——这不是理论风险，是生产环境高频事故。

正确做法是：每个 --tmpfs 都带 size= 参数，单位用 m 或 g，例如：

• --tmpfs /tmp:rw,noexec,nosuid,size=128m
• --tmpfs /run:rw,noexec,nosuid,size=32m
• --tmpfs /app/cache:rw,noexec,nosuid,size=96m

配合 noexec + nosuid 实现真隔离执行

仅靠内存存储还不够安全。攻击者可能上传恶意二进制到 /tmp 并执行；或利用 setuid 程序提权。tmpfs 的安全价值必须通过挂载选项兑现：

• noexec：彻底禁止该挂载点下任何可执行文件运行（即使 chmod +x 也无效）
• nosuid：忽略所有 setuid/setgid 位，断掉常见提权链
• 不推荐加 mode=777 —— 容器内 root 默认已有全部权限，宽松权限反而扩大攻击面

Docker Compose 和 Kubernetes 中的落地写法

生产环境极少单容器运行，需确保编排工具也继承该策略：

• Docker Compose：
  tmpfs:
    - "/tmp:rw,noexec,nosuid,size=128m"
    - "/run:rw,noexec,nosuid,size=32m"
• Kubernetes（使用 emptyDir + sizeLimit）：
  volumeMounts:
    - name: tmp
     mountPath: /tmp
  volumes:
    - name: tmp
     emptyDir:
      medium: Memory
      sizeLimit: 128Mi

注意：Kubernetes 的 emptyDir medium=Memory 就是 tmpfs 的封装，sizeLimit 必须带单位（Mi/Gi），不写单位会失效。