sudo lsof +l1 是唯一可靠方法，专筛链接计数为0的已删仍打开文件；先用 df -h 与 du -sh /* 对比确认差值，再通过 sudo lsof +l1 定位 pid、size/off 和 (deleted) 路径，最后用 kill -hup pid 或 systemctl reload 安全释放空间。
直接用 sudo lsof +L1 就能找出被已删除文件占用的无形磁盘空间——它专筛链接计数为 0 的打开文件，也就是那些“删了还在写”的幽灵文件。
先确认问题是否存在
不是所有磁盘空间异常都源于已删文件。先对比 df 和 du：
- 运行
df -h查分区实际使用率（比如/显示已用 95%） - 再运行
du -sh /* 2>/dev/null | sort -h统计根下各目录真实大小 - 若两者差值明显（如 df 显示用了 30G，du 加起来才 18G），差额大概率就是被已删文件悄悄占着
精准定位这些“隐形占用”
lsof +L1 是唯一可靠方式，别用 lsof | grep deleted ——容易误匹配路径含 deleted 字样的正常文件（比如 /tmp/deleted_cache）：
- 只查某目录：
sudo lsof +L1 /var/log - 只查某用户：
sudo lsof -u www-data +L1 - 加速执行（跳过 DNS 解析）：
sudo lsof +L1 -n - 输出中重点看：
PID（进程号）、COMMAND（程序名）、SIZE/OFF（当前占用字节数）、最后一列带(deleted)的路径
判断它们到底吃多少空间
光看到 (deleted) 不代表真占大空间，得验证实际大小：
- 查单个 fd 大小：
ls -lh /proc/PID/fd/FD号（例如ls -lh /proc/1234/fd/1） - 更准的统计：
du -sh /proc/PID/fd/FD号 - 估算所有已删文件总和：
sudo lsof +L1 2>/dev/null | awk '{sum += $7} END {printf "MB: %.0f\n", sum/1024/1024}'
安全释放空间，不中断服务
找到 PID 后，别急着 kill -9。优先选平滑释放：
- 支持日志重载的服务：
kill -HUP PID（如 rsyslog、nginx、Java 应用） - 系统服务：
systemctl reload servicename或systemctl restart servicename - 容器内进程：先
cat /proc/PID/cgroup确认是否属 Docker/K8s，再进容器或重启 Pod - 慎用手动清空：
echo > /proc/PID/fd/FD号仅适用于明确以追加模式写入且可截断的场景
