容器中 composer 安装慢主因是未切国内镜像源、dns 缓存解析异常、缓存目录未挂载及 vendor 写入受阻；需执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/、设 http-max-concurrent-downloads=8、挂载 ~/.composer-cache 并禁用 autoload 生成。
容器里 Composer 安装慢，95% 不是网络差，而是镜像源没切、DNS 缓存卡死、缓存目录没挂载、vendor 写入被拦截这四点导致的。必须在构建阶段就固化配置，不能依赖宿主机或运行时补救。
怎么确认镜像源是否生效
执行 composer config -g repo.packagist，输出必须是完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果还是 packagist.org 或空值，说明没生效。
- 别信
composer.json里写了repositories就万事大吉——那只影响当前项目，create-project和全局命令仍走默认源 -
composer show -p可列出所有已注册源，确认 packagist 类型的源是否已替换 - 验证镜像连通性：
curl -I https://mirrors.aliyun.com/composer/packages.json，秒回200才算靠谱
Dockerfile 中必须写的三行关键配置
基础 PHP 镜像里不会预设国内源，必须在构建阶段显式写死。推荐阿里云镜像，同步及时、稳定性高。
-
RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意末尾/） -
RUN composer config -g http-max-concurrent-downloads 8（不是越高越好，设 15 容易触发file_put_contents(/tmp/): failed to open stream） -
RUN composer clear-cache（换源后必须清缓存，否则旧包仍走原源）
注意：parallel-downloads 在 Composer 2.2+ 已弃用，改用 http-max-concurrent-downloads；若 composer --version 显示是 1.x，先升级：RUN composer self-update --prefer-dist。
多阶段构建中 vendor 层如何真正复用
很多 Dockerfile 把 COPY . /app 放在 composer install 前面，导致只要改一行代码，整个 vendor 层缓存就失效。
- 必须拆开：先
COPY composer.json composer.lock ./，再RUN composer install --no-dev --no-scripts --optimize-autoloader -
composer.lock必须一起COPY，否则 Docker 认为这一层“可能不同”，跳过缓存 - 第二阶段用
COPY --from=builder /app/vendor /app/vendor复用编译好的 vendor，不重装 - 务必加
--no-dev，否则 dev 依赖（如 phpunit）混进生产镜像，增大体积且可能引入安全风险
内网环境常见卡点和绕过方式
某些企业内网会拦截 HTTPS 重定向、复用 cURL DNS 缓存、或禁用 TLS 1.3，导致镜像域名解析仍走海外节点或握手失败。
- 启动容器时加 DNS 参数：
docker run --dns 114.114.114.114 --dns 8.8.8.8 - 若公司网络强制 HTTP 代理，需配环境变量：
ENV HTTP_PROXY=http://proxy.company:8080和HTTPS_PROXY=http://proxy.company:8080 - 极少数内网禁 HTTPS 重定向，临时加
--secure-http=false（不推荐长期开启） - 挂载宿主机缓存目录：
volumes: - ~/.composer-cache:/root/.composer/cache，避免每次重下
真正容易被忽略的是：vendor 目录写入慢往往不是网络问题，而是 macOS APFS 或 Windows 实时杀毒软件拦截小文件写入；CI 环境若仍报错，把 http-max-concurrent-downloads 降到 6 更稳。
