docker 中 composer install 慢的根本原因是镜像层缓存失效、重复下载及无本地镜像源；应先 copy composer.json/composer.lock 再 run install，使用 --repository-url 指定国内镜像源，并通过多阶段构建精简最终镜像。
在 Docker 容器里跑 composer install 慢，根本原因不是 Composer 本身，而是镜像层缓存失效 + 重复下载 + 无本地镜像源。直接用官方 PHP 镜像+裸 composer install，每次构建都重下包、重解压、重生成 autoloader，CI 构建动辄 3–5 分钟。
为什么 COPY composer.json 先于 RUN composer install 是关键
Docker 构建缓存只在指令内容完全一致时复用。如果把整个代码目录 COPY . /app 放在 RUN composer install 前面，哪怕只改了一行 PHP，composer install 这一层就彻底失效——因为上层变更导致后续所有 RUN 指令缓存失效。
必须拆开：先单独 COPY 依赖声明文件，再执行安装，最后 COPY 其余代码：
COPY composer.json composer.lock ./ RUN composer install --no-dev --no-scripts --optimize-autoloader COPY . .
-
composer.lock必须一起 COPY，否则即使composer.json没变，Docker 也会认为这一层“可能不同”，跳过缓存 -
--no-dev减少安装包数量；--no-scripts避免执行 post-install-cmd（如生成 autoload、清缓存等，这些可在运行时或单独阶段做） - 别加
--prefer-dist——它已是默认行为，显式写上反而容易让人误以为能提速
如何让 Composer 使用国内镜像源（阿里云/腾讯云）
默认走 packagist.org，国内直连慢且不稳定。不能靠运行时 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，因为这会污染全局配置、影响多项目复用，且在构建阶段不生效（除非进容器手动配）。
正确做法是在构建时通过环境变量或配置文件注入镜像源：
RUN composer config --global repo.packagist composer https://mirrors.aliyun.com/composer/
或者更稳妥（避免全局污染）：在 composer install 时临时指定：
RUN composer install --no-dev --no-scripts --optimize-autoloader \
--repository-url=https://mirrors.aliyun.com/composer/
- 阿里云镜像地址：
https://mirrors.aliyun.com/composer/；腾讯云：https://mirrors.cloud.tencent.com/composer/ - 不要用
composer config repo.packagist修改项目级配置（即不加--global），它会写入composer.json，污染源码 - 若项目已含自定义仓库（如私有 GitLab 包），需确保镜像源配置不覆盖它们——
--repository-url是临时覆盖，安全
多阶段构建中分离 vendor 和应用代码
生产镜像里不需要 dev 依赖、不需要 composer.json、不需要源码中的测试/文档文件。硬塞进去只会增大镜像体积、拖慢拉取和启动速度。
用多阶段构建，把安装过程放在 builder 阶段，只拷 vendor 和运行时必需文件到 final 阶段：
FROM php:8.2-cli AS builder WORKDIR /app COPY composer.json composer.lock ./ RUN composer install --no-dev --no-scripts --optimize-autoloader FROM php:8.2-cli-alpine WORKDIR /app COPY --from=builder /app/vendor ./vendor COPY . .
- final 镜像体积通常能减少 60%+（尤其用了大量 dev 依赖的项目）
- alpine 基础镜像比 debian 更小，但注意某些扩展（如
mongodb）在 alpine 上需额外编译，权衡后再选 - 别漏掉
autoload_files或files类型的自动加载项——它们依赖具体文件路径，COPY 时要一并带上
最易被忽略的一点：如果你的 composer.json 里用了 path 类型仓库（比如本地开发时 link 到另一个包），构建时会失败——Docker 构建上下文里根本不存在那个路径。这类配置必须在 CI/CD 中动态替换，或用 COMPOSER_HOME + 环境变量做条件切换，不能直接进镜像。
