结论：不存在\_composer容器，应将Composer作为构建工具或挂载进PHP容器使用；开发用docker run临时执行，生产在Dockerfile中安装，注意版本匹配、扩展依赖、权限及vendor挂载风险。
直接说结论：不要用单独的 _composer 容器——它不存在，也不是官方支持的镜像或模式。 Docker Compose 里没有叫 _composer 的标准服务名或镜像，强行写进去只会报 pull access denied 或 service "composer" not found。正确做法是把 Composer 当作构建时的工具，或挂载进 PHP 容器复用。
为什么找不到 _composer 镜像？
Composer 是 PHP 的依赖管理工具，不是独立运行的服务。Docker Hub 上没有官方 composer 或 _composer 镜像（只有社区维护的 composer 镜像，但不推荐在生产中当服务跑）。常见错误是照着过时博客写：
services:
_composer:
image: _composer这会直接失败——_composer 不是有效镜像名，下划线开头也违反命名惯例。
怎么在 Docker Compose 中真正用上 Composer？
分两种场景，选对方式才能少踩坑：
- 开发阶段快速装包：用
docker run --rm -v $(pwd):/app -w /app composer install一次性执行，不写进docker-compose.yml - 构建 PHP 应用时自动装依赖：在
Dockerfile里 RUNcomposer install --no-dev --optimize-autoloader，然后 COPY 到镜像 - 想在容器里交互式用 Composer？把
composer二进制挂进 PHP 容器：services: php: image: php:8.2-cli volumes: - .:/app - ./composer.phar:/usr/local/bin/composer working_dir: /app注意composer.phar得先本地下载好（curl -sS https://getcomposer.org/installer | php）
容易被忽略的兼容性细节
Composer 版本和 PHP 版本必须匹配，否则 composer install 会报错：
- PHP 8.2+ 项目必须用 Composer 2.5+；旧版 Composer 在 PHP 8.2 下可能卡死或报
ParseError - 如果
composer.json里用了ext-redis这类扩展，PHP 容器得提前装好对应扩展，否则composer install会跳过、但运行时崩 -
vendor/目录别挂成 volume：Docker 卷覆盖会清空已安装的包，导致Class not found
最麻烦的其实是权限——宿主机 UID 和容器内 UID 不一致时，composer install 生成的 vendor/ 文件属主可能是 root，PHP-FPM 容器却以 www-data 身份跑，结果读不了文件。这个点没提前处理，后面调半天 autoload 都白搭。
