docker-compose down 默认仅停止容器并删除容器和默认网络，安全释放需按需搭配参数：--volumes删卷、--rmi local删本地构建镜像、--rmi all删所有关联镜像（慎用），配合--remove-orphans处理孤立容器，且外部卷与被引用镜像受保护不误删。
用 docker-compose down 安全释放整套容器应用生态，关键不是“一键删光”，而是按需、分层、可控地清理资源，避免误删数据或影响其他项目。它本身不危险，但搭配参数不当或忽略依赖关系，就容易导致服务无法恢复、数据丢失或镜像被连带清除。
明确你要清理的范围：容器、网络、卷、镜像
Docker Compose 默认只停容器、删容器和默认网络，其余都保留——这是安全设计的起点。你需要根据场景主动选择是否扩展清理：
-
仅停服务、不丢数据：用
docker-compose down（无额外参数），适合日常调试后暂停服务 -
清空所有持久化数据：加
--volumes（或-v），会删除命名卷和匿名卷——执行前务必确认卷中无重要数据 -
同步清理镜像：加
--rmi local（删本地构建镜像）或--rmi all（删所有关联镜像），注意：all会尝试删基础镜像（如nginx:alpine），若其他项目正用，会失败并报错
避开常见误操作陷阱
很多“清理失败”或“重启异常”其实源于没看清依赖关系和默认行为：
-
外部卷（external volumes）不会被删：即使加了
--volumes，只要在docker-compose.yml中声明了external: true，该卷就完全跳过清理，这是保护跨项目共享数据的安全机制 -
孤立容器（orphans）默认不处理：如果改过
docker-compose.yml但旧容器还在运行，它们会被视为“孤儿”。加--remove-orphans才会一并停掉删除 -
镜像被引用时删不掉：比如你用
--rmi all，但另一个docker run nginx正在用同一镜像，Docker 会跳过并提示 “image is being used by running container”
推荐组合命令与使用时机
不同阶段对应不同清理强度，选对命令比追求“彻底”更重要：
-
开发调试后快速重来：
docker-compose down --rmi local—— 停服务、删自建镜像，保留基础镜像和卷，下次up启动快且安全 -
测试环境完全重置：
docker-compose down --volumes --rmi all --remove-orphans—— 清空卷+所有相关镜像+孤儿容器，接近“全新安装”状态 -
长期闲置项目收尾：先
docker-compose down，再单独执行docker volume ls和docker image ls人工核对，最后用docker volume rm xxx或docker image prune -f精准清理
清理后验证是否真正“释放”
执行完命令别急着关终端，花30秒确认资源是否按预期回收：
- 查容器：
docker-compose ps应返回空列表 - 查卷：
docker volume ls | grep $(basename $(pwd))（假设项目名作卷前缀），确认无残留 - 查镜像：
docker images | grep -E "(your-service-name|build-)"，看自定义镜像是否已消失 - 查磁盘：
docker system df -v对比清理前后 “Reclaimable” 列变化，直观看到空间释放量
