composer不是服务，不存在_composer官方镜像；开发时应使用docker run --rm -v $(pwd):/app -w /app -u $(id -u):$(id -g) composer:latest install --no-dev临时执行，而非在docker-compose.yml中配置。
别用 _composer 服务名，它根本不存在
直接写 services: _composer: 会报 pull access denied 或 service "composer" not found——Docker Hub 没有官方 _composer 镜像，下划线开头还违反命名规范。Composer 是工具，不是服务。你不需要、也不该起一个独立容器来“提供 Composer”。
开发时临时执行：用 docker run 而不是 docker-compose.yml
想快速装包或调试依赖？别往 docker-compose.yml 里硬塞 composer 相关配置。直接在项目根目录运行：
docker run --rm -v $(pwd):/app -w /app -u $(id -u):$(id -g) composer:latest install --no-dev
这个命令做了三件事：--rm 用完即删，-u 避免生成 root 权限的 vendor/，composer:latest 是官方镜像（基于 Alpine，自带 PHP 运行环境）。它不依赖宿主机 PHP，也不污染你的 compose 文件。
- 如果提示
SSL certificate problem，加-e COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/composer/ - 需要 GitHub API 访问（比如私有包），挂载
-e GITHUB_TOKEN=xxx - 缓存复用：加
-v $HOME/.composer/cache:/tmp/cache -e COMPOSER_CACHE_DIR=/tmp/cache
Dockerfile 构建阶段才该装依赖，不是 docker-compose exec
docker-compose exec app composer install 看似方便，实则危险：每次启动都重装、网络超时风险高、vendor/ 权限易错乱、composer.lock 可能被意外修改。正确路径是把 RUN composer install 写进 Dockerfile 的 builder 阶段。
- builder 和 final 镜像的 PHP 小版本、发行版（如
php:8.2-cli-bullseye+php:8.2-fpm-bullseye）必须完全一致 -
COPY顺序必须是：先composer.json和composer.lock，再RUN composer install --no-dev --optimize-autoloader - 国内环境务必提前设镜像源：
RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - Alpine 镜像记得补证书：
RUN apk add --no-cache ca-certificates
docker-compose.yml 里只做一件事：挂载代码，不挂载 vendor
如果你在 docker-compose.yml 里写了 volumes: - ./vendor:/var/www/html/vendor，立刻删掉。这会导致权限冲突（Mac/Windows 默认 uid=0，PHP 容器常用 uid=1001）、autoload 失效、甚至 Class not found。真正该挂载的只有源码：
volumes: - .:/var/www/html # 不挂 vendor，不挂 composer.phar，不挂 ~/.composer
构建好的 vendor/ 已经打进镜像里了，运行时直接用。挂载源码是为了热重载，不是为了让 Composer 在容器里重跑。
多阶段构建中，vendor/ 的路径、用户属主、WORKDIR 必须三者对齐——差一个字符，autoload.php 就找不到。这不是配置问题，是路径硬编码在 classmap 里的结果。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
