docker中composer报command not found是因为php官方镜像默认不预装；必须通过dockerfile安装并配置全局路径，选用debian系镜像更兼容，alpine需额外处理依赖和ssh；缓存应使用命名卷或正确权限绑定挂载；php-fpm与cli容器须统一工作目录、用户id及缓存路径以避免autoload加载失败。
docker里装composer为什么总报command not found
因为官方PHP镜像默认不带composer，它不是PHP内置工具，得手动装。很多人直接docker run php:8.2-cli php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"，结果容器一重启就没了——镜像层没保存，命令只在临时容器里跑了一次。
- 必须在
Dockerfile里安装，而不是进容器手敲 - 推荐用官方安装脚本+校验哈希，别用
curl | php这种不安全写法 - 装完要加
RUN mv composer.phar /usr/local/bin/composer && chmod +x /usr/local/bin/composer，否则得一直php composer.phar调用
PHP镜像选alpine还是debian影响composer运行吗
影响明显。Alpine用musl libc，某些扩展（比如ext-ssh2或私有git仓库走SSH时）会缺依赖，composer install卡在“Cloning into…”；Debian系更稳，但镜像体积大30–50MB。
- 如果项目依赖
ext-gd、ext-mbstring等常见扩展，Alpine需要额外装apk add --no-cache $PHPIZE_DEPS gd-dev libpng-dev再编译，容易漏 - 私有Git仓库用HTTPS+Token基本无感；用SSH密钥就得挂载
~/.ssh且注意Alpine的openssh-client版本太老，可能连不上新服务端 - CI场景优先选Debian，本地开发图快可试Alpine，但得提前验证
composer update全流程
如何让composer缓存不随容器重建丢失
容器删了，~/.composer/cache就清空，每次composer install都重下zip包，慢且耗流量。不能靠VOLUME硬挂宿主机目录（权限错乱、macos文件系统延迟问题多），得用命名卷或绑定挂载并预设权限。
- 启动时用
docker run -v composer-cache:/root/.composer/cache php-app，卷名固定，数据跨容器保留 - 若绑定宿主机路径（如
-v ./cache:/root/.composer/cache），先chown -R 82:82 ./cache（PHP容器www-data用户UID是82），否则permission denied -
composer config -g cache-dir /root/.composer/cache这句不用写，新版默认就是该路径
docker-compose中怎么让php-fpm和cli共用同一份composer配置
常见陷阱：php-fpm容器里composer install成功，但CLI容器报class 'ComposerAutoloadClassLoader' not found，其实是vendor/autoload.php路径没对齐，或两个容器工作目录不一致。
- 确保
docker-compose.yml里两个服务的volumes映射完全一致，尤其./src:/var/www/html这类路径 - CLI容器执行
composer install时，务必working_dir: /var/www/html，否则生成的vendor/autoload.php里的路径是错的 - 别在CLI容器里用
--no-scripts跳过自动加载器生成，fpm依赖这个文件，跳了就炸
环境变量、用户ID、缓存路径这三处不统一，比语法错误更难排查。动手前先docker exec -it app-php-cli ls -l /var/www/html/vendor/autoload.php看一眼文件是否存在、属主是否匹配。