Docker Compose 提示孤立容器？删除前先审计项目归属

1. 保存准确警告，暂缓清理决定

保存完整警告、触发它的命令、工作目录，以及所有 `-f`、`--project-directory`、`-p` 或 `--project-name` 参数。在归属问题未解决前，不要运行 `docker container prune`、`docker compose down -v`，也不要带着 `--remove-orphans` 重复原命令。

记录 `docker compose version`、当前 Docker context 和相关 Compose 文件名。如果命令由自动化发起，还要保留会影响项目命名的环境，特别是 `COMPOSE_PROJECT_NAME` 和该次调用选择的 `.env` 文件。

用 `docker ps -a --no-trunc` 列出警告中提到的全部容器，并记录完整 ID、状态和名称。名称是线索，标签与有效 Compose 模型才是归属证据。

2. 解析实际 Compose 项目名，不要依赖记忆中的文件名

Docker 文档给出的项目名优先级依次为：命令行 `-p`、`COMPOSE_PROJECT_NAME`、所指定文件中最后一个顶层 `name`、项目目录的基本名称，最后才是当前目录。先重建准确调用，再判断两个文件是否真是不同项目。

使用与原调用相同的文件、profiles、环境和项目参数运行 `docker compose config`，并使用已安装版本支持的名称输出选项渲染模型。保存最终项目名和服务清单，但不要暴露秘密值。

两个仓库如果都从名为 `docker` 的目录启动，或自动化为它们提供同一个显式项目名，就可能碰撞。在该分支中，警告里的容器可能仍属于另一套有效应用。应给项目设置稳定且不同的名称，不要只为消除警告而删除另一个项目的容器。

3. 读取每个警告容器的 Compose 归属标签

检查每个准确容器 ID，并记录 `com.docker.compose.project`、`com.docker.compose.service`、`com.docker.compose.project.config_files`、`com.docker.compose.project.working_dir`，以及当前 Compose 版本提供的一次性运行标记。使用 `docker inspect` 的 JSON 输出，不要从截断的名称猜归属。

把项目标签与当前调用解析出的实际项目名比较。项目标签不同就是停止条件：删除任何内容前，先查清为什么本次运行把它归入警告。项目标签相同而服务不在渲染模型中，只能说明它是候选孤立项，还不能证明删除安全。

再把记录的配置文件和工作目录标签与当前文件组合比较。这可能暴露文件改名、`-f` 顺序变化、部署自动化从另一个目录运行，或旧调用曾经有意管理更多服务。

4. 区分四个常见分支

服务改名或删除后，容器的项目标签仍匹配，但旧服务标签不再出现在当前模型中。将其判定为失效前，先用版本控制或部署记录确认这项变更。

项目名冲突表现为项目身份相同，实际应用或文件根目录却不同。为每个应用设置稳定、唯一的项目名后重新检查。删除容器不是首要修复，因为错误项目仍会再次碰撞。

一次 `docker compose run` 可能在命令结束或工作流中断后留下已停止容器。上游 issue 展示过特定版本中反复运行命令会积累容器和警告的案例。把它保留为一个分支：先检查标签、状态、退出码和版本，不要把所有警告都套用到该案例。

旧文件组合分支出现在同一项目有意使用不同 `-f` 组合或 profiles 时。今天的模型中缺少某服务，并不表示另一种受支持调用不再需要它。清理前先记录它由哪个模型拥有。

5. 在接触容器前审计挂载和卷

对每个候选项，从 `docker inspect` 记录 bind mount、具名卷和匿名卷。已停止容器仍可能是定位数据的最直接地图，而这些数据的用途未必记录在其他地方。与服务所有者确认备份和恢复预期。

Compose down 参考把容器和网络删除与卷删除分开说明。应用声明的具名卷不等于可丢弃的容器层，外部卷则由 Compose 项目之外管理。绝不能仅因为警告写着孤立，就随手加上 `-v`。

如果容器仍暴露端口或运行工作负载，在停止前识别其用户和依赖。孤立分类只表示它不在当前模型中，并不能证明工作负载或数据已无用。

6. 选择范围最窄的动作并记录结果

只有在容器已被证实失效、确属当前项目、不再承载所需工作负载且数据已保全后，才使用与相同文件组合和项目名对应的项目级 Compose 命令。文档说明 `docker compose up --remove-orphans` 会删除当前文件中未定义服务的容器，因此必须先证明它的项目范围正确。

如果原因是项目名冲突，应更改项目身份并在不删除的情况下重新运行。如果容器属于预期的替代 profile 或文件组合，应保留并记录正确调用。如果原因是一次性运行容器，应优先使用正常生命周期控制和针对具体版本的修复，而不是全局 prune。

执行后，用相同 context 再跑一次原命令并保存新的警告状态。重新检查存活容器，确认无关项目、端口、网络和数据挂载没有变化。

证据 | 可能分支 | 最小安全动作 项目标签不同于预期项目 | 归属不符 | 停止；先解决调用和命名问题 项目相同，且有意改名后旧服务已不在模型中 | 已确认的失效服务 | 保全数据后，使用项目范围的孤立清理 无关文件根目录解析出相同项目名 | 项目名冲突 | 设置稳定且不同的项目名；保留有效容器 已停止的一次性容器有匹配运行证据 | 一次性运行生命周期 | 检查退出状态和版本，只删除已确认的运行容器 服务属于另一种受支持的文件或 profile 组合 | 预期资源 | 保留，并记录拥有它的调用

7. 验证清理并准备可交给支持人员的归属记录

验收条件必须具体：警告中的每个具名容器都有已记录的项目和服务所有者；保留容器对应受支持调用；被删容器已证实失效；所需挂载仍存在；原 Compose 命令不再干扰另一个项目。

提交支持请求时，附上已脱敏的 Compose 与 Engine 版本、Docker context、实际项目名、文件顺序、容器 ID、项目/服务/配置文件标签、状态与退出码，以及挂载类型。报告中不得包含凭据、秘密环境值或私有仓库令牌。

只有在已排除项目名优先级、文件组合差异、标签、一次性状态和普通生命周期行为后，才升级为可能的 Compose 回归。警告提到 `--remove-orphans`，并不能单独证明该标志适用于准确子命令或能修复当前分支。

常见问题

Docker Compose 所说的孤立容器是什么意思？ 它表示容器与实际 Compose 项目身份相关联，但其服务不在当前模型中。原因可能是真实的服务删除、项目名冲突、不同文件/profile 组合，或一次性运行容器。

`--remove-orphans` 总是安全吗？ 不是。只有在当前项目范围正确、每个候选项确实失效，而且所需挂载或数据已保全后才安全。该标志遵循当前 Compose 模型；项目名或文件组合错误会让范围变得危险。

为什么两个无关 Compose 文件会看到彼此的容器？ 它们可能通过目录默认值、环境变量、顶层 name 或显式 `-p` 解析成同一个项目名。应为无关应用设置稳定且不同的项目名。

应该用 `docker container prune` 清除警告吗？ 不应把它作为第一步。全局 prune 范围更大，也不能解释归属。先检查标签、项目命名、状态和挂载，再只删除已证实失效的容器。