推荐使用 docker compose run 执行临时性任务，因为它会启动全新容器，复用服务配置但隔离干净；而 docker compose exec 仅在已运行容器内执行命令，易因环境不一致或进程冲突失败。
在 Docker Compose 环境中执行临时性任务（比如数据库迁移、脚本调试、数据校验），推荐使用 docker compose run，它会启动一个全新容器，复用服务定义的镜像、网络、卷等配置，但不启动依赖服务（除非显式指定），也不受 depends_on 启动顺序约束——这点和 exec 有本质区别。
明确 run 和 exec 的核心差异
run 创建新容器，独立于已运行的服务；exec 则是在已有容器内执行命令。临时任务（如首次 migrate、一次性导入）必须用 run，否则可能因环境变量缺失、卷挂载不一致或进程冲突失败。
-
docker compose run web python manage.py migrate→ 新建容器执行，隔离干净 -
docker compose exec web python manage.py migrate→ 进入正在运行的 web 容器，但该容器可能正处理请求或未加载完整环境
确保依赖服务就绪再运行
很多临时任务依赖数据库、缓存等服务。虽然 run 默认不自动启动依赖项，但可通过 --service-ports 或 --rm + --wait（v2.23+）配合 depends_on 控制等待逻辑。更稳妥的做法是手动启动依赖：
- 先运行
docker compose up -d db redis（确保基础服务就绪） - 再执行
docker compose run --rm --no-deps app python scripts/init_db.py -
--no-deps防止意外拉起其他服务；--rm让容器用完即删，避免残留
复用服务配置但覆盖关键参数
直接复用 docker-compose.yml 中 service 的定义最省心，但需灵活覆盖：环境变量、入口点、命令、工作目录等。例如：
- 覆盖命令：
docker compose run --rm api sh -c "curl -s http://backend:8000/health" - 注入临时环境：
docker compose run --rm -e DEBUG=1 worker python check_tasks.py - 指定工作目录（尤其含相对路径脚本时）：
docker compose run --rm --workdir /app/src backend pytest tests/
调试失败任务的实用技巧
临时任务失败时，别急着重试。先加 -it 交互运行，观察环境是否符合预期：
-
docker compose run -it --rm web sh→ 进入 shell 查看文件结构、环境变量、网络连通性 - 检查是否挂载了正确卷：
ls -l /data、mount | grep data - 测试服务可达性：
nc -zv db 5432或ping redis（需镜像含对应工具） - 若提示“command not found”，说明镜像没装对应 CLI 工具，可临时改用基础镜像调试，或在 Dockerfile 中预装
不复杂但容易忽略：临时任务不是“随便跑个命令”，而是要像部署一样考虑环境一致性、依赖就绪状态和资源清理。用好 run，能大幅降低运维盲区。
