磁盘空间不足本质是临时资源消耗与预分配不匹配，需控源头、疏路径、留余量协同解决：定位真实瓶颈（如/tmp、/var/lib/docker）、构建阶段限流（pip禁缓存、多阶段构建）、运维层嵌入自动清理与弹性回收机制。
自动化部署过程中磁盘空间不足，本质是临时资源消耗与预分配空间不匹配的问题。它不是单纯的“硬盘小了”，而是构建缓存、日志、镜像、解压中间产物在短时间内集中爆发，超出系统预留容量。解决关键在于“控源头、疏路径、留余量”三步协同，而非事后清理。
定位真实瓶颈：别只看 /，要盯住 /tmp、/var/lib/docker 和 /root
很多团队一看到 df -h 显示根分区 95%，就急着删日志，结果发现空间没释放——因为真正撑爆的是容器环境或 pip 缓存目录。AutoDL、Jenkins、GitLab Runner 等平台默认把构建过程全扔在 /tmp 或 /root/.cache/pip，而这些路径可能挂载在独立小分区（如仅 5GB 的 /tmp），和 / 的使用率无关。
- 运行
df -h | grep -E "(tmp|docker|root)"快速筛查高危挂载点 - 用
du -sh /tmp/* | sort -hr | head -5查看临时目录下谁在“狂吃” - Docker 用户务必执行
docker system df -v，确认镜像、构建缓存、卷是否堆积
构建阶段主动限流：从源头压缩空间占用
自动化部署脚本本身可优化，避免“下载→解压→安装→删源”这种低效模式。尤其在 CI/CD 流水线中，每一步都应有空间意识。
- pip 安装时加
--no-cache-dir，禁用本地缓存；或指定外部缓存路径：--cache-dir /mnt/shared/pip-cache - 构建 Docker 镜像时启用
--squash（旧版）或优先用多阶段构建（multi-stage），让中间层不保留在最终镜像里 - 下载大文件（如模型权重、ISO）前先检查剩余空间：
[ $(df -B1 . | awk 'NR==2 {print $4}') -lt 2147483648 ] && echo "ERROR: less than 2GB free" && exit 1
运维层加固：设置自动清理与弹性回收机制
靠人工巡检不现实。应把空间治理变成流水线的“标准动作”，嵌入到部署前、部署后、空闲期三个环节。
- 部署前：在 Jenkins pipeline 或 GitHub Actions 中加入
shell: df -h && echo "---" && du -sh /var/log/* | sort -hr | head -3，失败阈值设为 85% - 部署后：添加清理步骤，例如
find /tmp -name "pip-install-*" -mtime +1 -delete、journalctl --vacuum-size=100M - 空闲期：配置 logrotate 对
/var/log/jenkins/、/var/log/gitlab/等目录按大小轮转，保留最多 3 份压缩日志
长期扩容策略：别只扩磁盘，要改架构
频繁遇到空间告急，说明当前部署架构存在刚性瓶颈。真正的“一劳永逸”不是把虚拟机磁盘从 50G 拉到 100G，而是解耦存储责任。
- 将构建产物（如 RPM、DEB、Docker 镜像）统一推送到私有制品库（Nexus、Harbor），本地只保留必要元数据
- 用 NAS 或对象存储（如 MinIO）挂载为
/shared/build-cache，供所有构建节点共享缓存，避免重复下载 - 对无状态服务，采用“构建即销毁”模式：每次部署启动干净容器，任务结束自动回收全部临时空间
