容器化CI/CD任务完成后自动销毁的核心是“用完即清”，需在任务结束阶段强制执行，覆盖容器、镜像、卷、网络等全部资源，推荐使用docker system prune -f --filter "until=30m"组合命令，并配合--rm启动、docker-compose down -v或kind delete cluster等工具实现环境级原子清理。
容器化ci/cd任务完成后自动销毁，核心是“用完即清”——不依赖人工干预，确保每次执行都从干净状态开始，同时释放资源、规避残留风险。关键不在销毁动作本身，而在销毁时机、范围和可靠性。
明确销毁范围：容器、镜像、卷、网络一并清理
只删容器远远不够。一个典型的CI任务会生成：临时运行的容器（可能处于exited状态）、构建产生的中间镜像、挂载的匿名卷、自定义bridge网络。若只执行 docker container prune -f，镜像和卷仍持续占用磁盘，久而久之导致CI节点空间告急。
- 推荐组合命令（适用于单机Docker环境）：
docker system prune -f --filter "until=30m"
它一次性清理已停止容器、未被使用的网络、悬空镜像（dangling）和未被任何容器引用的卷；--filter "until=30m"可限定只清理30分钟前创建的闲置资源，避免误伤正在调试的临时实例。 - 若需更精细控制（例如保留最近3个测试镜像），可配合
docker images --format "{{.ID}}\t{{.Tag}}" | grep "test-" | head -n -3 | xargs -r docker rmi类脚本实现标签级清理。
嵌入CI流程：在job结束阶段强制触发销毁
销毁必须作为CI job不可跳过的收尾步骤，而非可选操作。无论测试成功或失败，只要任务进入结束阶段，就应执行清理。
- 在GitHub Actions中，使用
always()条件：if: ${{ always() }}
放在cleanupjob 或当前job的steps末尾，确保即使上一步run: npm test报错退出，销毁仍会执行。 - 在GitLab CI中，使用
after_script并显式声明：after_script:- docker system prune -f
同时在job顶层加interruptible: false防止用户手动取消时跳过该阶段。
配合编排工具：用docker-compose或kind实现环境级销毁
当测试不止一个容器（如app + db + cache），单独删容器易遗漏依赖关系。此时应将整个环境视为一个单元来管理。
- 使用
docker-compose up -d启动后，务必配套docker-compose down -v——-v参数确保关联卷一并删除，否则数据库文件残留会导致下次启动失败。 - 对Kubernetes风格测试，优先选用
kind：它把集群打包为容器，kind create cluster和kind delete cluster是原子操作。销毁时不仅清空所有Pod，还卸载整个控制平面容器，彻底无残留。
预防性设计：从启动就减少销毁负担
销毁不是补救，而是设计结果。越早引入轻量化与隔离机制，后期清理越简单可靠。
- 所有临时容器启动时加
--rm标志。这样容器退出即自动删除，无需额外prune命令。CI中绝大多数工具类容器（如linter、scanner）都适用此模式。 - 敏感配置通过环境变量注入（如
-e DB_PASSWORD=$DB_PASS），而非写死在docker-compose.yml中。这既提升安全性，也避免因配置变更导致旧容器无法被识别清理。 - 为CI专用Docker守护进程单独配置
/etc/docker/daemon.json，启用"live-restore": true和合理设置"default-ulimits"，防止因宿主机重启或资源超限造成容器状态异常，干扰自动销毁逻辑。
