<p>先用df -h确认/tmp等分区使用率异常高，再用du -sh /tmp/* | sort -hr对比发现df与du差值巨大，说明存在已删未释放的临时文件；接着执行sudo lsof +L1 /tmp精准定位被进程持有的“幽灵文件”，结合grep筛选命名特征锁定PID；最后通过echo > /proc/PID/fd/FD号清空句柄内容并验证df回落。</p>
应用频繁创建临时文件却未释放，本质是进程打开了文件但没关描述符，或写入后没清理路径——这类问题常导致磁盘悄悄被占满、df和du严重不符，甚至触发只读文件系统错误。排查关键不是找“谁建的”，而是锁定“谁还在攥着它”。
先确认是不是临时文件真没释放
别急着查代码，先验证现象是否属实：
- 运行
df -h查磁盘使用率（比如/tmp或/var/tmp已用 95%） - 再跑
du -sh /tmp/* 2>/dev/null | sort -hr | head -10看真实目录大小 - 如果
df显示用了 40G，du加起来才 8G，差值大概率就是被删但未关闭的临时文件占的
用 lsof 找出“幽灵临时文件”
临时文件常带 tmp、XXXXXX、picture_、.tmp 等特征，但直接 grep tmp 容易误伤。更准的做法是：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 限定路径搜：
sudo lsof +L1 /tmp（只看/tmp下已删仍占空间的） - 结合命名特征筛：
sudo lsof /tmp | grep -E "(picture_|\.tmp|XXXXXX)" | grep deleted - 重点关注输出里的
PID、COMMAND、FD（如12w）、SIZE/OFF和末尾(deleted)
定位到进程后判断行为模式
光知道 PID 不够，得搞清它是怎么用临时文件的：
- 查进程命令行：
ps -fp PID，看是否含java -jar、python、node等典型应用启动方式 - 看它打开了哪些文件：
lsof -p PID，重点扫/tmp、/var/tmp下的REG类型文件，尤其带DEL或(deleted)的 - 检查 fd 大小：
ls -lh /proc/PID/fd/ | grep -E "(tmp|deleted)"，确认单个句柄是否已达 GB 级
安全释放并验证修复效果
不建议直接 kill 进程，优先选低影响方式：
- 若进程支持重载（如某些 Java 应用监听
SIGHUP）：kill -HUP PID - 应急清空内容（需 root）：
echo > /proc/PID/fd/FD号（例如echo > /proc/1234/fd/25） - 释放后立刻验证：
df -h /tmp是否回落，再sudo lsof +L1 /tmp确认无输出
这类问题 80% 出在日志、缓存、上传临时文件处理逻辑上。上线前加一句 lsof +L1 /tmp 快速过一遍，比等告警响了再救火强得多。
