docker compose项目名称由命令行-p参数、compose_project_name环境变量或docker-compose.yml中name字段决定，docker desktop无图形界面修改入口；-p最常用且优先级最高，名称须小写字母/数字/-/_开头，不支持大写或短横线开头。
在 Docker Desktop 中，docker compose 项目名称不是通过 Desktop 图形界面修改的，而是由命令行参数、环境变量或 docker-compose.yml 文件中的 name 字段决定的。Docker Desktop 本身不提供项目名编辑 UI，所有命名控制都落在 CLI 层级。
用 -p 参数覆盖默认项目名（最常用）
默认情况下，Docker Desktop 启动 Compose 时会取当前目录名作为项目名。但你几乎总该显式指定，避免分支切换或并行开发时冲突。
- 直接加
-p运行：docker compose -p myapp-dev up -d - 项目名必须小写、数字、
-或_，且不能以-开头；myapp_dev合法，MyApp或-dev都会报错 - Docker Desktop 的「Containers / Apps」列表里显示的正是这个
-p值（如myapp-dev-web-1），不是服务名 - 如果已运行了同名项目，
up -d会复用现有容器；想彻底重建，先docker compose -p myapp-dev down
COMPOSE_PROJECT_NAME 环境变量（适合 CI 或脚本固化）
比 -p 更隐蔽但更稳定，尤其当你不想改所有 docker compose 命令时。
- Linux/macOS：
export COMPOSE_PROJECT_NAME=myapp-staging，之后所有docker compose up都自动带上 - Windows PowerShell：
$env:COMPOSE_PROJECT_NAME="myapp-staging" - 在 Docker Desktop 的「Settings → General → Start Docker Desktop when you log in」下，环境变量不会自动加载到 GUI 启动的终端中，需手动配置或改用
-p - 注意：该变量对
docker run无效，只影响docker compose系列命令
在 docker-compose.yml 里写死 name 字段（不推荐用于多环境）
虽然 YAML 文件支持顶层 name 字段，但它在多文件场景下行为不稳定，容易被覆盖或忽略。
- 写法示例：
name: myapp-prod services: web: image: nginx - 仅当使用单个
docker-compose.yml且不带-f时才生效；一旦用了-f docker-compose.prod.yml -f docker-compose.override.yml，name只取最后一个文件里的值，极易出错 - Docker Desktop 的「Add container」按钮或右键菜单启动项目时，不会读取这个字段——它只认当前目录和 CLI 上下文
- 真正需要环境隔离时，优先用
-p或环境变量，而不是把name写进 YAML
重命名已运行的项目？没有直接方法
Compose 项目名本质上是容器命名前缀 + 网络/卷的命名空间，无法事后“改名”。试图修改只会导致资源残留或冲突。
- 不能用
docker rename改项目名——它只改单个容器名，不影响网络、卷、服务依赖关系 - 错误操作示例：
docker compose -p oldname down && docker compose -p newname up -d看似可行，但旧卷、旧网络仍保留，下次down不会清理它们 - 安全做法：先
docker compose -p oldname down -v彻底清理，再用新名启动；-v删除关联卷（注意数据备份） - 如果你依赖
container_name字段做了硬编码（比如脚本里--link myservice），那改项目名后这些引用全失效，得同步更新
真正容易被忽略的是：Docker Desktop 的「Dashboard」里看到的项目名，其实只是当前终端执行 docker compose 命令时所用的 -p 值或环境变量值——它不保存、不记忆、不跨终端共享。同一目录下开两个终端，一个设 COMPOSE_PROJECT_NAME=a，一个没设，它们看到的就是两个完全隔离的项目，连容器列表都不重叠。
