容器中composer install每次重下包是因为~/.composer/cache未持久化，需通过-v挂载宿主机目录或Docker卷实现缓存复用，同时构建镜像时执行composer config -g配置镜像源确保全局生效。
为什么容器里每次composer install都重下包？
不是镜像源没配对，而是容器每次启动都是干净环境，~/.composer/cache根本没存下来。你改了composer.json、加了--repository、甚至只改了个注释，只要docker run新起一个容器，缓存就清零——因为没挂载、没共享、没复用。
怎么让中文镜像缓存真正留在容器里？
单容器场景下，不能靠BuildKit的--mount=type=cache（它只在docker build时生效），必须把缓存目录显式绑定到宿主机或Docker卷。关键不是“设镜像源”，而是“让缓存路径可持久”。
-
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/要提前执行一次，确保全局配置落进镜像，而不是靠环境变量临时覆盖 - 运行容器时，必须用
-v /host/path/to/composer-cache:/root/.composer/cache，路径要和composer config cache-dir输出一致（别硬写/root/.composer/cache，先进容器查） - 如果用Docker卷，先
docker volume create composer-cache，再-v composer-cache:/root/.composer/cache - Alpine镜像记得提前装证书：
RUN apk add --no-cache ca-certificates，否则SSL握手失败，缓存根本走不到下载环节
容器内composer install卡在“Resolving packages…”怎么办？
这不是缓存没生效，是根本没连上镜像源。国内直连packagist.org基本超时，而COMPOSER_REPO_PACKAGIST环境变量只影响单次命令，不持久，容易漏配。
- 用
composer install --no-interaction -vvv 2>&1 | grep "Downloading"看真实请求URL，确认是否命中https://mirrors.aliyun.com/composer/ - 别依赖
docker run -e COMPOSER_REPO_PACKAGIST=...，它不写入全局配置，下次composer require又回退到默认源 - 最稳做法：构建镜像时就跑
RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，一劳永逸 - 如果项目用了私有包，还要配
composer config -g http-basic.repo.example.com user pass，否则认证失败也会卡住
单容器部署时，vendor/要不要也挂载？
不要。挂载vendor/会导致权限错乱、符号链接失效、扩展加载失败（比如ext-redis在容器里编译的so文件，挂宿主机路径后ABI不匹配）。vendor/必须由composer install在容器内生成，缓存只管.zip包下载，不碰vendor/目录本身。
- 真正要挂的是
/root/.composer/cache，不是/app/vendor - 如果想加速首次
install，可以在构建镜像阶段用多阶段预装vendor/，但运行时容器仍要独立生成自己的vendor/（哪怕内容一样） - 挂载
vendor/还会绕过composer.lock校验，导致PHP版本不兼容的包被强行加载，运行时报Class not found
composer global命令意外覆盖——这些细节比选哪个镜像源更关键。 
