清空回收站后空间未释放，主因是被删除文件仍被进程占用；需用lsof | grep deleted定位带(deleted)标记的句柄，优先通过bt restart重启服务释放，或用echo > /proc/PID/fd/N在线清空。
回收站清空后空间没变，先看是不是文件还被进程锁着
宝塔的 /www/Recycle_bin 清空了，df -h 却显示空间没涨，大概率是某些服务仍在读写已被删除的日志或临时文件，系统无法回收 inode。这类文件在 lsof 输出里带 (deleted) 标记，但磁盘块仍被占用。
- 运行
lsof | grep deleted，重点关注nginx、php-fpm、mysql、bt相关进程 - 若输出中某行含
/www/wwwlogs/xxx.log (deleted)，说明 Nginx 日志被删但进程还在追加写入 - 不要直接
kill -9所有 PID——比如php-fpm主进程被杀会导致网站 502；优先用bt restart 5重启 PHP，它会优雅关闭子进程并释放句柄 - 对 Nginx，执行
bt restart 0比kill -9更安全；Apache 同理用bt restart 1
为什么 lsof | grep deleted 没结果，但空间还是不释放
可能原因有两个：一是进程没在 lsof 默认扫描范围（比如以非 root 用户启动），二是文件被硬链接或挂载点遮蔽。这时候得缩小排查范围。
- 限定路径查：比如怀疑日志目录，运行
lsof +D /www/wwwlogs/ | grep deleted - 检查是否用了软链接：
ls -l /www/wwwlogs/access.log看目标是否指向已删文件（如指向/tmp/nginx_access.log，而后者已被删） - 确认是否启用了宝塔的“防篡改”或“网站监控”插件，它们可能在后台持续打开旧日志文件句柄
- 用
find /proc/*/fd -ls 2>/dev/null | grep deleted绕过lsof权限限制，直接查 proc 文件系统
不重启服务也能释放空间？试试在线清空文件
有些场景不能停服务（比如生产环境高峰期），又急需腾空间，可以用内核级方式“截断”被占用的已删文件，不中断写入流。
- 从
lsof输出中拿到 PID 和 fd 编号，例如：nginx 1234 root 7w REG 8,2 1073741824 123456 /www/wwwlogs/site.log (deleted)，其中7w是 fd 号 - 执行
echo > /proc/1234/fd/7—— 这会把该 fd 对应的文件内容清空，空间立刻释放，且 nginx 仍能继续写入新日志 - 注意：此操作只对可写文件有效；若 fd 是只读的（
r），需改用truncate -s 0 /proc/1234/fd/7（部分老内核不支持） - 别对数据库主文件（如
ibdata1）这么干，风险极高
宝塔专属残留：回收站目录名被转义，手动删时容易漏
/www/Recycle_bin 里的文件不是原样存放，而是把路径分隔符 / 替换为 _bt_，比如 /www/test/index.php 会被存成 _bt_www_bt_test_bt_index.php。直接 rm -rf /www/Recycle_bin/* 可能删不干净。
- 先进入目录：
cd /www/Recycle_bin - 用
ls -1 | head -n 5看前几条命名规律，确认是否含_bt_ - 彻底清理命令应为：
find /www/Recycle_bin -type f -delete && find /www/Recycle_bin -type d -empty -delete - 再跑一次
du -sh /www/Recycle_bin，确保输出是0或提示目录不存在
echo > /proc/PID/fd/X 可能导致归档中断或校验失败。这种细节不会报错，但会影响后续恢复。 
