换镜像本身不提升ci/cd吞吐量，但配错参数会导致90%以上php项目ci超时；必须验证镜像生效（输出完整json）、加齐五个关键参数、启用缓存与lock文件、避免内存限制及私有包dist缺失。
换镜像本身不能直接提升CI/CD吞吐量，但配错或漏配关键参数会让整个流水线卡在依赖安装环节——这是90%以上PHP项目CI超时的根源。
验证镜像是否真生效
很多CI脚本写了composer config -g repo.packagist就以为完事，结果日志里全是Downloading from https://packagist.org。必须进CI容器执行：
-
composer config -g repo.packagist—— 输出必须是完整JSON，形如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null或报错=没写进去 -
composer install -vvv 2>&1 | grep -i "mirrors\|aliyun\|tuna"—— 看实际下载域名是不是镜像地址 - 旧版Composer（1.x）不认
repo.packagist，得用repos.packagist，且值必须是合法JSON字符串
CI中必须加的五个参数
--no-interaction和--prefer-dist只是底线，缺一不可；但只加这两个，仍可能被环境拖慢：
-
--no-dev：跳过require-dev，省掉30–60%时间，尤其避免拉phpunit这类大包 -
--optimize-autoloader（或-o）：生成静态类映射，PHP 7.4+下可进opcache，测试启动快20%+ -
--classmap-authoritative（或-a）：部署专用，告诉自动加载器“没在映射里=真没有”，彻底跳过文件扫描；但本地开发禁用，否则新增类直接Class not found -
--ignore-platform-reqs：CI镜像常为最小化配置，跳过PHP版本/扩展检查；若需校验，改用--platform=php:8.2 -
--no-progress：关闭进度条输出，减少CI日志IO压力，尤其在低配Runner上明显
parallel-downloads不是万能钥匙
很多人设了parallel-downloads 10就以为并发拉包，但实际根本没跑起来：
- 仅Composer 2.2+支持，旧版本设了也白搭：
composer --version确认，低于2.2.x必须composer self-update --prefer-dist - 只对
install生效，且严重依赖镜像源支持HTTP/2；如果镜像没生效，它连并发机会都没有 - 并发过高会触发临时文件竞争，典型错误是
file_put_contents(/tmp/): failed to open stream，此时立刻降到6或8 - Composer 2.5+已弃用
parallel-downloads，应改用http-max-concurrent-downloads 10
缓存和lock文件才是吞吐瓶颈所在
镜像再快，每次构建都重下ZIP包，吞吐量还是上不去。CI中真正卡点在这三处：
- 没提交
composer.lock：CI拉代码后vendor/为空，composer install直接报错退出，不会自动生成 - 没挂载
~/.composer/cache：哪怕vendor/缓存了，每次仍要重新下载ZIP包；只缓存vendor/反而危险——不同PHP版本生成的autoloader不兼容 - PHP内存不足：CI默认限制常触发
Killed，得在脚本开头加export COMPOSER_MEMORY_LIMIT=-1 - 私有包没dist发布：若只提供Git地址，
--prefer-dist会报Could not find a matching version of package xxx，此时只能关掉该参数，或补全dist发布流程
最易被忽略的是--classmap-authoritative和~/.composer/cache的组合效果——前者让autoload快到几乎不感知，后者让ZIP包复用率接近100%，两者叠加才能把单次构建的依赖阶段压到秒级。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
