/tmp用于短期临时文件，重启或10天未访问即清理；/dev/shm是POSIX共享内存挂载点，由内核自动管理，进程退出即释放、重启全清，二者语义不同、不可混用。
/tmp 和 /dev/shm 都是 Linux 中高频使用的临时存储路径，但用途、生命周期和安全风险完全不同。直接混用或统一清理，容易引发应用异常、性能下降甚至权限越界。关键不是“清得快”，而是“清得准、控得住”。
/tmp 的清理逻辑与实际行为
/tmp 是 POSIX 标准定义的通用临时目录，设计目标是“短期存放”，但具体保留多久，取决于系统配置：
- systemd 系统默认通过 systemd-tmpfiles-clean.timer 每日触发清理，依据
/usr/lib/tmpfiles.d/tmp.conf中的规则（如d /tmp 1777 root root 10d），删除 10 天未访问的文件 - 若 /tmp 被挂载为 tmpfs（内存文件系统），重启即清空；此时清理机制只影响运行中未被及时删除的文件
- Debian/Ubuntu 还额外启用 tmpreaper，支持跳过特定后缀（如
.pid、.lock）或保护挂载子目录下的文件 - 注意：/var/tmp 不在此列——它专用于跨重启的临时数据，标准建议保留至少 30 天，通常不被自动清理覆盖
/dev/shm 的清理机制本质不同
/dev/shm 不是普通目录，而是内核通过 tmpfs 实现的 POSIX 共享内存挂载点。它的“清理”不是靠定时脚本，而是由内核自动管理：
- 进程正常退出且无其他引用时，对应共享内存段由内核立即释放
- 异常崩溃或未调用
shmdt()/shm_unlink()的程序，可能残留 shm 段；可用ipcs -m查看，ipcrm -m <shmid>手动清理 - 重启后全部清空，无需人工干预；但容器场景下（如 Docker 默认仅 64MB），空间不足会导致
No space left on device错误，需通过--shm-size=2g显式扩容 - inode 数量限制易被忽略：默认仅几千个，高并发小对象（如 session 缓存）会快速耗尽，挂载时加
nr_inodes=1M可支撑百万级文件
安全性差异与加固要点
两者都开放读写，但攻击面和缓解方式差异显著：
- /tmp 面临竞态创建、权限泄露、恶意执行等风险：必须设 sticky bit（chmod 1777 /tmp），并推荐挂载时启用
noexec,nosuid,nodev；敏感操作应改用$XDG_RUNTIME_DIR或PrivateTmp=yes隔离 - /dev/shm 默认
mode=1777，所有用户可读写，但因内容纯内存、重启即失，主要风险是内存耗尽或信息泄露；避免在其中存放长期凭证，也不宜替代持久化缓存 - 不建议将 /dev/shm 当作 /tmp 的“加速版”来硬替换——它们语义不同：/tmp 是进程临时工件区，/dev/shm 是 IPC 通信通道；强行把日志、上传文件塞进 /dev/shm，反而增加 OOM 风险
- 审计建议：对 /tmp 启用
auditd监控异常写入（如非 root 用户创建可执行文件），对 /dev/shm 则重点监控shmget/shmat系统调用频次突增
实用配置检查清单
运行以下命令，快速确认当前状态：
-
findmnt /tmp和findmnt /dev/shm—— 确认是否为 tmpfs 及挂载参数 -
systemctl is-enabled systemd-tmpfiles-clean.timer—— 查看自动清理是否启用 -
ls -ld /tmp—— 验证 sticky bit 是否生效（末位应为 t） -
ipcs -m | wc -l—— 统计残留 shm 段数量，超百需排查 -
df -h /tmp /dev/shm—— 对比使用率，/dev/shm 接近上限时优先查进程而非删文件
