Docker Compose down 报 active endpoints：共享网络仍被其他容器使用

前端、后端和数据库分开启动，共用一个 Docker 网络。结束前端环境时，docker compose down 提示：

error while removing network: network app_shared has active endpoints

这里的网络名是示例。报错表示删除网络时仍有容器端点连接。若数据库和后端还需要运行，应保留共享网络，先核对各个 Compose 项目对它的管理方式。

先查连接者，避免清理正在使用的后端

docker network inspect app_shared
docker ps -a --filter network=app_shared

查看网络结果中的 Containers，把容器 ID 与名称、运行状态对应起来。数据库和后端出现在列表中，并不说明它们是垃圾容器；它们可能正是前端依赖的服务。默认 down 会删除当前配置中的服务容器和由项目管理的网络，网络上仍有其他容器时，删除就会被拒绝。

如果列表中的容器已不再使用，先确认所属项目、数据卷和重新启动方式，再由对应项目正常停止、删除。停止数据库会中断连接，删除容器会丢失容器可写层中的数据；先核对持久卷和备份，恢复时使用原配置重新启动。不要用全局 prune 或批量强制删除来处理一个共享网络。

网络检查没有列出任何容器却仍报错时，不要直接认定是共享配置问题。保留完整错误与 Docker 版本，重新检查端点状态；这条分支还可能涉及残留状态，需要单独处理。

共享网络由外部管理，两个项目都只加入它

若网络本来就要在前端退出后继续供后端使用，在相关 Compose 文件中将它声明为外部网络。下面是配置片段，服务的其他字段按现有配置保留：

services:
  frontend:
    networks:
      - shared

networks:
  shared:
    external: true
    name: app_shared

后端项目同样引用这个实际网络名。external: true 表示生命周期不由该 Compose 项目负责，down 不会删除它；网络必须事先存在。仅设置 name: app_shared 只是固定名称，并没有把网络变成外部管理。

备份两个项目的配置后，安排维护窗口修改并重新创建需要迁移的服务。确保容器接入同一个预期网络，再恢复业务检查。若改错网络名导致启动失败，恢复备份配置和原连接关系。不要在迁移前删除仍承载业务的旧网络。

出现 orphan 警告，还要检查项目名

分别启动的配置若误用了同一个 Compose 项目名，前端配置可能把后端、数据库识别成 orphan。检查启动脚本中的 -p、COMPOSE_PROJECT_NAME 和容器标签 com.docker.compose.project，确认哪些服务本应属于同一项目。

需要独立管理的项目应使用不同项目名，并通过明确声明的外部网络通信。--remove-orphans 会删除当前项目中未被当前配置定义的容器，在项目名关系没有查清前不要加这个选项。

验收时，前端的 down 应正常结束，后端和数据库仍可访问，共享网络仍存在；再次启动前端后，服务间通信也应正常。若全部服务本来就属于一个生命周期，则用覆盖所有服务的同一套配置统一启动和停止更合适。