Docker 没有运行中的容器，删除卷仍报 volume is in use

执行 docker volume rm 时报告 volume is in use，但 docker ps 没有输出业务容器。先查看停止的容器：停止并不会解除容器配置对卷的引用，默认只列运行中容器的命令会把这些引用者隐藏起来。

以下针对普通 Docker Engine 卷和仍存在的容器引用。删除卷会删除持久数据，目标应先明确为“退役已确认无用的卷”，而不是为了消除报错就顺带删除所有停止的容器。

用全部容器列表定位引用者

假设报错卷名为 example-data。在连接同一 Docker Engine 的终端查看：

docker ps -a --filter volume=example-data --no-trunc
docker volume inspect example-data

-a 包含已停止容器，volume 过滤帮助缩小范围。使用 Compose 时，实际卷名可能带项目名前缀，不能直接拿 YAML 中的短名称替换报错里的实际名字。

如果报错列出了容器 ID，再逐个检查这些明确的 ID：

docker inspect --type container --format '{{.Name}} {{.State.Status}} {{json .Mounts}}' CONTAINER_ID

将 CONTAINER_ID 替换为实际值，核对对应挂载的 Type、Name 和 Destination。一个停止容器也可能是保留的数据库、离线任务或回退入口，不能仅因状态是 exited 就认定它无用。

列表为空而报错仍有引用时，先核对 Docker context、实际卷名和报错是否来自同一时刻。查询失败、权限不足与成功返回空列表也要区分。不要直接进入 Docker 数据目录删除卷文件，或通过重启 daemon 代替引用关系检查。

保留容器，或按退役流程解除引用

如果容器还需要启动、回退或保留现场，就保留该卷。volume is in use 在这里是保护提示，不需要“绕过”它。若业务只是想换一份数据，应按应用迁移流程使用另一个卷，而不是清空旧卷后期待原容器还能恢复。

只有确认目标停止容器已经退役，部署定义、日志和可写层数据已按需保存，卷中数据也已备份并核对可恢复后，才移除这个明确的容器：

docker container rm CONTAINER_ID

这里不加 -f 或 -v。普通移除停止容器会移除其可写层，但不会因此删除这里要单独处理的命名卷。若容器重新进入运行状态导致删除失败，应先查明是谁启动了它，而不是立刻强制终止。

Compose、CI 或其他管理器仍可能重新创建容器。需要先在原管理流程中停用相应任务或调整引用，防止检查刚结束，又出现新的使用者。保留其他卷和其他服务，不使用全局 prune 作为这一问题的修复。

最后才删除已确认不再需要的卷

再次运行包含 -a 的卷过滤查询，并检查原报错引用的容器是否已经按计划移除。只有所有引用都解除，且数据保留与恢复要求满足后，才删除这个精确卷名：

docker volume rm example-data

如果仍被拒绝，重新检查当前引用。不要将 --force 理解为安全移除业务数据的保证，也不要因为卷没有运行中的使用者，就省略停止容器和数据用途核对。

删除成功后，用 docker volume ls 确认该实际名称已不存在，再确认其他保留卷和服务未受影响。删除操作不会自动把数据迁移到新卷，也不意味着应用会自己恢复所需目录。

卷删除后没有通用的 Docker 撤销命令。需要回退时，必须按备份恢复流程重建卷和恢复数据，再用保留的部署定义创建容器。若只完成了容器退役、卷还在，恢复也仍需重新创建容器；旧容器的可写层不会因重新挂回同一卷而自动恢复。