清理开发服务器时，最容易让人放松警惕的词，是“未使用”。没有容器引用一个数据卷，它又占着空间，似乎正适合交给清理命令。
但我在一次临时数据卷退役中，把这个判断拆成了两句：现在没有容器使用它；以后也不需要里面的数据。前一句可以检查，后一句必须另外证明。
这不是反对清理。那次操作最终确实移除了已经确认可退役的数据卷，也核对了空间变化。我想记录的，是从候选清单走到删除决定之间，哪些检查真正有用，哪些绿灯容易被误读。
“未引用”是对象关系，不是数据价值
Docker 官方说明，数据卷的内容独立于具体容器的生命周期存在；删除容器，并不意味着卷内数据随之失去保留价值。[1]
当前 docker volume prune 文档把“未使用的本地卷”定义为没有被任何容器引用的卷；默认只清理其中的匿名卷，加入 --all 才扩大到所有未使用卷。[2]
这里没有“数据已经无用”的判断。一次实验留下的导出物、还没确认迁走的数据库内容、已经移除容器所留下的恢复材料，都可能没有当前容器引用。反过来，一个名字很正式的卷，也可能只是可再生的旧测试数据。
所以，卷名像不像临时文件、创建时间早不早、是否被标成未使用，都只能帮助我筛选候选，不能单独授权删除。这是我的清理原则，不是 Docker 对业务价值作出的保证。
第一处容易漏看：停止的容器仍要算进去
我没有只看正在运行的容器。Docker 的容器列表默认显示运行中的对象，--all 才会包括停止的容器。[3]
这次退役脚本读取的是完整容器集合，再逐个核对挂载关系。一个容器虽然停着，但仍然引用数据卷，就不能因为运行列表里看不到它而把卷当成孤立对象。除此之外，当次检查还覆盖了宿主机进程和挂载对目标目录的使用线索。
对读者来说，可以先从下面两条只读命令建立清单：
docker container ls --all docker volume ls
它们分别列出容器和卷，不会自动替你证明两份清单之间的关系。接下来仍要检查目标容器的挂载信息、卷的身份及它所属任务的用途。不要把“我把两张表都看了一遍”当成引用核验已经完成。
对有并发任务的机器，我还会把“停止创建或重新挂载候选卷”作为操作窗口的约束。如果做不到，就先保留，不能用几分钟前的一次扫描保证删除时仍然没人使用。
我的实际顺序：先保全，再定点移除
这次处理的是一批已经按用途确认可退役的本地卷，不是在线数据库，也不是随意扩大到整个 Docker 环境的清扫。
先冻结具体对象。 操作前固定卷身份和批准范围，明确排除仍被引用的卷。执行过程中如果发现驱动、挂载位置、创建信息或引用关系与记录不一致，就停止处理该对象，而不是自动换一个“看起来相似”的目标。
再把需要保留的数据转成受保护的恢复材料。 当次归档进入私有存储，保留原对象与归档之间的对应关系。上传结束不是最后一步：执行记录包含归档回读、解密、内容及元数据比较，还对一个样本做了隔离位置的实际解包恢复。
这里必须说清范围：所有归档的完整回读与比较，不等于每个卷都已重新挂到应用中运行；一个样本落盘恢复，也不等于所有卷都完成了应用级恢复。 本次经验只支持已执行的检查，不扩写成“任何故障都能恢复”。
最后在删除前重新核验。 实际脚本在定点删除之前，再次检查对象范围、归档状态、源内容是否变化和引用关系，然后只移除那一个已核验的卷。删除后再读回卷清单，确认对象确实不存在。
这条顺序和“先批量清理，发现有用再想办法找回”完全不同。它把不可逆动作放在后面，也避免用一个全局清理开关替代逐项决定。
我怎样判断这次清理真的完成了
我核对的不是一句“命令成功”，而是几份相互对应的记录：目标清单中的条目都具有归档验证及删除回执；操作前后的容器身份、运行状态和挂载记录一致；源卷确实从清单中消失；宿主机有相应的空间回收记录。
写作时，我又做了一次只读卷清单核对，原退役清单里的卷均已不存在。这里没有重新执行删除，也没有把历史回执冒充今天再次完成的全套恢复测试。
这些结果足以支持“这批已批准的本地卷完成了退役”的结论，却不足以承诺所有业务长期无影响。尤其是业务用途是否判断正确，仍不能由文件校验和或容器状态替代。
为什么我保留一个短期恢复窗口
对这批数据，我没有把“源卷已删”与“归档也该立刻删除”合并成一个动作。归档保留了短期恢复窗口，到期仍需按当时的引用、用途和恢复需要复查；本次没有把到期日直接接成自动删除器。
这也不意味着所有临时文件都值得做一套复杂归档。我的取舍是：能明确重建、没有独有内容的临时产物，清理应当轻；可能保留唯一结果的数据卷，值得先确认并保全。 对用途无法解释的对象，先调查，不能靠“多备一份”把未知风险洗成安全。
保留窗口只能降低部分误判后果，不能证明数据原本就无用。它还会占用存储并增加管理成本，因此应有明确归属、恢复方式和复查条件，而不是无限期堆积。
哪些场景不能照搬
本文不是在线数据库备份教程。正在写入的数据、远程或共享卷、特殊存储驱动、多主机环境，都需要按各自的一致性和使用关系重新设计处理方式；不能把这次静态本地卷的归档路径照搬过去。
Docker 对卷的备份与恢复有官方说明，但示例能说明命令用法，并不能替具体应用证明数据一致性或业务可恢复。[1]
如果只能确认“没有当前容器引用”，却不知道内容是否唯一、是否还有外部任务使用、归档能否实际读回，我会停在候选清单，而不是继续删除。本文也刻意不提供一键批量删除脚本。
结论：清理的终点不是更短的列表
这次经历让我更愿意问三个具体问题：谁还在引用它？里面有没有唯一价值？移除后还能按明确路径取回什么？
回答清楚以后，删除本身反而很简单。回答不清楚时，“未使用”只是一个技术状态，不是一张丢弃许可。
本文根据作者于 2026 年 10 月 2 日完成的本地数据卷退役记录，由 AI 辅助核验与整理；写作时补做了只读对象核对。项目名称、账号、主机、目录、对象标识、配置及数据规模均已省略。官方文档核验日期为 2026 年 10 月 3 日；未对所有 Docker 版本、驱动和并发环境逐一测试。封面为原创概念插画，不是真实设备或内部架构图。
来源与核验
以下为 Docker 官方在线文档，核验日期：2026 年 10 月 3 日。官方机制与本文的个人操作记录分开标注。
- [1] Docker Volumes
- [2] docker volume prune
- [3] docker container ls
