问题发现
在日常运维中，我注意到服务器的磁盘使用率持续攀升，系统告警提示 / 分区已达到95%的使用上限。为定位问题根源，我首先执行了 df -h 命令，确认根分区确实已严重饱和。
为了深入分析是哪些组件占用了大量空间，我调用了WisdomSSH的诊断功能，执行了 docker system df 命令。输出结果清晰地揭示了问题所在：
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 19 8 11.64GB 9.072GB (77%)
Containers 8 8 2.307MB 0B (0%)
Local Volumes 0 0 0B 0B
Build Cache 55 0 3.317GB 3.317GB数据显示，虽然有8个容器正在运行（符合预期），但镜像和构建缓存占用的总空间高达约15吉字节，其中可回收空间达12.389吉字节。这表明大量未使用的镜像和构建缓存堆积，是造成磁盘空间紧张的直接原因。
排查与清理过程
步骤一：识别待清理对象
根据 docker system df 的提示，首要任务是找出所有可以安全删除的"无用"资源。我执行了 docker images --filter "dangling=true" 命令，查询所有悬空镜像。输出结果如下：
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 216e76326069 4 days ago 2.55GB
<none> <none> 140038f00beb 4 days ago 2.55GB
...结果显示存在多个悬空镜像，它们不被任何容器引用，是典型的垃圾数据。
步骤二：执行全面清理
基于上述排查，我决定执行一次全面的系统清理。我使用了 docker system prune -a --volumes 命令，该命令会删除：
- 所有停止的容器
- 所有未被任何容器使用的网络
- 所有未被任何容器使用的匿名数据卷
- 所有不被任何容器关联的镜像
- 所有构建缓存
由于此操作不可逆，系统提示需要用户确认。我通过自动化脚本发送确认指令 echo "y" | docker system prune -a --volumes，启动了清理流程。
步骤三：验证清理效果
清理完成后，我再次运行 docker system df 进行最终验证：
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 8 8 4.452GB 74.78MB (1%)
Containers 8 8 2.307MB 0B (0%)
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B结果令人满意：总计回收了11.94吉字节的空间。系统可回收空间比例从77%降至1%，磁盘使用率回归正常范围，问题彻底解决。
总结
本次事件的核心是定期维护的缺失。尽管服务正常运行，但历史构建和废弃镜像的积累最终突破了磁盘容量的阈值。
通过WisdomSSH，我得以快速、精准地定位到问题根源，并利用其提供的标准化、安全的命令组合完成了清理。整个过程无需手动逐项检查，避免了人为遗漏或误删风险。此次经历再次证明，将工具链与高效的自动化脚本相结合，是保障系统长期稳定运行的关键。