提升CI/CD流水线速度？Composer中文镜像有奇效！-composer-PHP中文网

ci/cd中composer慢的根本原因是未切国内镜像、缓存路径错误、关键参数缺失；必须配置阿里云镜像、缓存~/.composer/cache（非vendor/）、并严格使用--no-dev --prefer-dist --optimize-autoloader --classmap-authoritative --no-interaction参数。

提升ci/cd流水线速度？composer中文镜像有奇效！

CI/CD里Composer慢，不是“中文”问题，也不是网络抽风——根本原因是没切国内镜像、缓存路径错、参数漏设。三者缺一，提速就白忙。

composer config -g repo.packagist 输出还是 packagist.org？

这说明镜像根本没生效，后续所有优化都打水漂。常见原因有三个：

CI脚本用 sudo composer config -g，结果写进了 root 的 ~/.composer/config.json，但构建实际跑在 runner 或 www 用户下，压根读不到
拼错字段名，比如写成 repos.packagist（多一个 s），Composer静默忽略，composer config -g repo.packagist 查出来仍是空
旧版 Composer 1.x 不支持 repo.packagist，得改用 composer config -g repos.packagist '{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}'

验证是否真走镜像：加 -vvv 运行 composer install，日志里出现 GET https://mirrors.aliyun.com/composer/p2/ 才算成功。

缓存 vendor/ 还是 ~/.composer/cache？

必须缓存 ~/.composer/cache，绝不能缓存 vendor/。原因很实在：

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

vendor/ 里的 autoloader 是编译时生成的，依赖 PHP 版本、扩展（如 ext-zip）、OS 架构；缓存错环境，上线后直接报 Class not found
~/.composer/cache 只存下载的 zip 包和元数据，跟 composer.lock 哈希强绑定，与运行环境完全无关
GitHub Actions 示例：path: ~/.composer/cache，key: ${{ runner.os }}-php-${{ matrix.php }}-composer-${{ hashFiles('**/composer.lock') }}
GitLab CI 示例：cache: key: ${PHP_VERSION}-composer-cache; paths: - ~/.composer/cache

composer install 必须带哪些参数？

不是“能跑就行”，而是要同时满足可重现、安全、性能。漏一个，就可能出问题：

--no-dev：跳过 require-dev 中的包（如 phpunit），否则上线后 class_exists('PHPUnit\Framework\TestCase') 直接 fatal
--prefer-dist：强制下载预构建 zip 包，避免 Git clone 失败、SSH 权限缺失或协议阻塞
--optimize-autoloader（或 -o）：生成 vendor/composer/autoload_classmap.php，绕过 PSR-4 运行时扫描，类加载快 50%+
--classmap-authoritative：告诉 autoloader “没在 classmap 里 = 真没有”，彻底禁用 file_exists() 探测——这是防止 Class not found 的最后一道防线
--no-interaction 和 --no-progress：禁用交互提示和进度条，避免流水线卡住或日志解析失败

注意：--classmap-authoritative 必须与 --no-dev 同时使用；否则 dev 类虽不装，运行时判断仍会触发 fatal。

CI 里为什么不能用 composer update？

因为 composer update 会重解析整个依赖树、修改 composer.lock，破坏构建可重现性。昨天通过的流水线，今天可能因一个 monolog 的 patch 升级而失败。

CI 中只允许 composer install，且必须确保 composer.lock 已提交到 Git
本地改了 composer.json 后，手动运行 composer update 并提交新 composer.lock，再推送到 CI
CI 脚本里一旦出现 composer update，应立刻删除
如果 CI 报 Lock file operations: 1 install, 0 updates, 0 removals 却卡住，大概率是 PHP 扩展缺失（比如 Alpine 镜像没装 apk add php81-zip），不是命令问题

最易被忽略的一点：换镜像源后，务必执行 composer clear-cache，否则旧源还在内存里苟着，-vvv 日志里看到的仍是 packagist.org 的请求。