答案是导入中断残留为未完成写入的临时层，不可修复，须先释放空间→清理临时层→验证清空→重导入：定位/var/lib/docker/overlay2或~/.local/share/containers/storage/overlay/中l-开头的半成品目录，用system prune强制清理，若报空间不足则先清日志、tmp和缓存，再执行image prune -a -f，最后校验sha256并预留≥5GB空间重载。
导入中断后残留的临时层不是“损坏文件”，而是未完成写入的中间状态数据，直接修复不可行，必须清除后重试。关键在于识别并清理这些卡在存储路径里的半成品层，同时避免触发新的空间错误。
先确认中断类型和残留位置
导入（docker load 或 podman load）中断通常分两类：
-
网络中断或 Ctrl+C：镜像 tar 包没读完，只写入部分 layer，
docker images可能看不到对应镜像，但 storage 目录里已有不完整 layer 文件 -
磁盘满导致失败：系统报
no space left on device，此时 overlay2 或 fuse-overlayfs 下已堆积大量未提交的临时 blob 和 diff 目录
定位路径：
- Docker 默认：
/var/lib/docker/overlay2/（查看是否有大量以l-开头但无对应diff或merged的目录） - Podman 默认：
/var/lib/containers/storage/overlay/或用户级路径如~/.local/share/containers/storage/overlay/
清理残留临时层的实操步骤
不要手动删文件夹，用容器运行时自带命令更安全：
- 运行
docker system prune -a -f --volumes（Docker）或podman system prune -a -f --volumes（Podman），强制清理所有未被引用的 layer、构建缓存、临时卷 - 如果提示
no space left on device，说明清理命令本身也写不了临时文件——需先释放空间：
• 清日志：sudo journalctl --vacuum-size=100M
• 清 tmp：rm -rf /tmp/*（注意避开正在使用的 socket）
• 清用户缓存：rm -rf ~/.cache/containers - 再执行
docker image prune -a -f，删除所有未被容器引用的镜像，包括导入中断产生的 dangling 层
验证是否清干净
执行以下命令交叉检查：
-
docker system df—— 查看BUILD CACHE和IMAGE SPACE是否明显下降 -
docker images --digests | grep <none>—— 确保无悬空镜像残留 -
find /var/lib/docker/overlay2 -maxdepth 1 -type d -name "l-*" | wc -l—— 若数量异常多（如 >200），说明仍有未清理的临时 link 目录，需重启 dockerd 后再 prune
重新导入前的必要准备
避免再次中断，导入前做两件事：
- 确认 tar 包完整性：
sha256sum your-image.tar对比原始哈希值 - 预留足够空间：导入过程临时占用约 1.5 倍 tar 包大小，建议磁盘剩余 ≥5GB
- 用
docker load -i your-image.tar（不加任何参数），避免缓存干扰；若仍失败，改用podman load（对中断恢复更鲁棒）
