PHP-FPM容器中不应运行Composer，依赖必须在Docker构建阶段（RUN composer install）或CI/CD独立CLI容器中安装；vendor目录需构建完成时就位，运行时只读；镜像配置须与install在同一RUN指令中用&&连接，并确保www-data家目录存在。
PHP-FPM容器里根本不能“运行”Composer
别在php-fpm容器里执行composer install或composer update——这不是慢不慢的问题，是架构错位。php-fpm进程只负责接收FastCGI请求、执行PHP脚本，它不启动CLI环境，也不加载Composer二进制。你看到的“卡住”“超时”“child exited on signal 9”，全是强行塞任务导致的进程崩溃。
真正该装依赖的地方只有两个：Docker构建阶段（RUN composer install），或CI/CD流水线里的独立CLI容器（比如composer:2镜像）。生产镜像里连composer命令都不该存在。
- php-fpm启动后是常驻worker进程，不会主动读
composer.json或触发安装逻辑 - 即使你在
ENTRYPOINT里加了composer install，它只执行一次，且大概率因权限/家目录缺失失败 - vendor目录必须在镜像构建完成时就已就位，运行时只读取，不变更
Dockerfile里配置Composer镜像的正确位置
镜像配置不是“设一次就全局生效”，它只对当前RUN指令之后、同一构建层内执行的composer命令起作用。所以必须把composer config -g和composer install写在同一行RUN里，中间用&&连接。
错误写法：
RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/<br>RUN composer install --no-dev
第二行会忽略第一行的配置，因为新shell session不继承上一层的~/.composer/config.json。
立即学习“PHP免费学习笔记（深入）”；
- 正确写法：
RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ && composer install --no-dev --prefer-dist -o -a - 如果用多阶段构建，镜像配置只需出现在build阶段（如
php:8.3-cli-alpine），final阶段（php:8.3-fpm-alpine）不需要、也不该有composer - 别依赖宿主机的
~/.composer/config.json——Docker build没你的家目录，必须在镜像内显式写入
为什么composer config -g在FPM容器里总失效
你以为执行了composer config -g就万事大吉，但实际它默认写入/root/.composer/config.json，而php-fpm默认以www-data用户运行，它查的是自己的家目录/var/www/.composer/——这个路径通常为空，甚至不存在。
更麻烦的是，Alpine镜像里www-data用户根本没有初始化家目录，mkdir -p /var/www/.composer都得手动做，否则composer config -g直接报错Could not create directory。
- 若坚持要在运行时配置（不推荐），得先确保目标用户家目录存在且可写：
RUN mkdir -p /var/www/.composer && chown www-data:www-data /var/www/.composer - 然后切到该用户再执行：
RUN su -c "composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/" -s /bin/sh www-data - 但再次强调：这只是应急手段，不是生产方案；真正可靠的配置永远发生在构建阶段
项目级镜像配置比全局更稳
全局配置（composer config -g）容易被项目里的composer.json覆盖。只要项目根目录下composer.json里写了"repositories"字段，Composer就会优先用它，无视全局设置。
这对CI/CD尤其危险——不同分支可能带不同composer.json，导致依赖来源不可控。项目级配置反而明确、可版本化、可审计。
- 在
composer.json里加这段（注意格式合法，末尾无逗号）：{"repositories": [{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}, {"packagist.org": false}]} - 删掉
vendor/和composer.lock，再跑composer install生成新lock文件 - 这样即使全局配置被误删或未生效，项目仍走镜像源
composer install/update执行时起效，而这两个命令绝不该出现在php-fpm容器的生命周期里。真正容易被忽略的，是构建阶段那一行&&连接的顺序，以及www-data家目录是否真实存在——这两点出错，90%的“镜像没生效”问题就来了。 
