虚拟机磁盘满致崩溃本质是根分区或关键挂载点空间耗尽，需分四步排查：先用df -h、df -i、lsof查是否真满；再用du、find定位占用源；接着区分inode耗尽或文件已删未释放；最后安全清理日志、缓存、docker等。
虚拟机内磁盘空间满引发系统崩溃，本质是根分区（/）或关键挂载点（如 /var、/home）可用空间归零，导致 systemd 无法写入服务状态、日志无法落盘、mysql/nginx 等服务初始化失败。排查必须分层验证：先确认是不是真满了，再定位谁在吃空间，最后判断是删了没释放、还是虚拟磁盘本身不收缩。
第一步：确认是否真满——别被表象骗
登录虚拟机终端（或通过 recovery mode、Live USB 进入），立即执行三组命令交叉验证：
- df -h：看 Use% 是否达 100%，重点关注 /、/var、/tmp；若 Avail 显示 0G 或几十 KB，基本坐实；
- df -i：若 inode 使用率（IUse%）也到 100%，说明不是大文件占满，而是海量小文件（如未轮转的日志切片、临时 session），df -h 却可能还显示有空间；
-
lsof | grep deleted：查是否有被 rm 但进程仍在写的老文件（如 Java 应用持续写入的
app.log），这类文件 du 看不到，df 却算占用——这是“删了没释放”的典型信号。
第二步：定位增长源——钻进目录找元凶
确认某一分区爆满后，从根往下逐级排查，避免跨挂载点误统计（加 -xdev 参数）：
Handsfree Windows Control
下载
通过 handsfree-windows CLI控制 Windows 本机应用 (UIA) 和浏览器 (Playwright) 的引导技能，用于自动化或测试桌面应用。
- 查一级目录占比：sudo du -xsh /* 2>/dev/null | sort -hr；重点盯 /var/log（Nginx、应用、journal 日志）、/var/lib/docker（容器镜像/日志）、/var/lib/mysql（binlog、临时表）、/home（用户大文件、下载缓存）；
- 查单个超大文件：sudo find / -xdev -type f -size +500M 2>/dev/null -exec ls -lh {} \; | sort -k5 -hr；常见目标包括
core.*、mysql-bin.*、ext4.vhdx（WSL2）、hiberfil.sys（Windows 宿主机）； - 查近期突增文件：sudo find /var/log -type f -mtime -7 -ls | sort -k7 -r，快速识别最近 7 天疯涨的日志。
第三步：区分真假满——两个最易踩的坑
很多“崩溃”其实源于误判：
- inode 耗尽：日志每秒生成一个 1KB 文件，df -i 显示 100% 时，df -h 可能还有 30% 空间。解决方法是合并或轮转日志，而非删文件；
-
文件已删但句柄未关：lsof 输出中带
(deleted)的条目，说明空间未真正释放。必须重启对应服务（如 systemctl restart nginx）或安全清空：sudo truncate -s 0 /path/to/file（比 kill 进程更稳妥）。
第四步：针对性清理与释放——安全优先
只做可逆、低风险操作：
- 日志类：用 sudo journalctl --vacuum-size=100M 清 systemd 日志；sudo logrotate -f /etc/logrotate.conf 强制轮转；
- 包管理缓存：Ubuntu/Debian 执行 sudo apt clean && sudo apt autoremove；统信 UOS 清 /var/cache/apt/archives/*.deb；
-
Docker：运行 docker system prune -af --volumes，并检查
/etc/docker/daemon.json是否配置了"log-opts": {"max-size": "10m", "max-file": "3"}； -
WSL2 场景：若
ext4.vhdx膨胀严重，先在 Linux 内执行 sudo apt clean && sudo journalctl --vacuum-size=50M，再在 Windows PowerShell 中运行：wsl --shutdown && diskpart /s script.txt（脚本含 compact vhdx 指令）。
