如何利用Composer中文镜像提升PHP CI/CD速度？-composer-PHP中文网

ci/cd镜像没生效主因是配置写入错误用户目录，如sudo composer config -g写入root的config.json而runner用户读不到；应改用sudo -u runner composer config -g或项目级composer config repo.packagist写入composer.json并提交；换源后需clear-cache、--no-cache重装并更新composer.lock，配合--no-dev、--prefer-dist、--optimize-autoloader、--classmap-authoritative四参数及缓存~/.composer/cache方可提速。

如何利用composer中文镜像提升php ci/cd速度？

CI/CD里镜像没生效，大概率是写进了错用户的config.json

CI环境（比如GitHub Actions、GitLab CI）跑的是runner用户，不是root。用sudo composer config -g会把配置写进/root/.composer/config.json，但构建时根本读不到。结果就是composer config -g repo.packagist看着有值，实际请求还是打到packagist.org。

正确做法是确认当前用户再配：

先查用户：whoami 或看CI日志里的UID
给对应用户配：sudo -u runner composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
或更稳妥：直接在项目根目录运行composer config repo.packagist composer https://mirrors.aliyun.com/composer/，它会写进composer.json，随代码提交，所有环境自动生效

换源后还卡在Downloading，先清缓存再重装

镜像只加速下载，但Composer默认优先读本地缓存。旧缓存里存着packagist.org的元数据，哪怕你已经换源，它也会尝试从旧地址校验——表现就是卡在DNS解析或TLS握手，根本没发请求到镜像站。

必须三步一起做：

执行composer clear-cache
删掉vendor/和composer.lock
跑composer install --no-cache，强制走新源重新拉取元数据

别保留旧composer.lock——它记录的是旧源的包哈希，和镜像返回的元数据不兼容，必然报hash does not match。

CI脚本里必须加的四个参数

--no-dev、--prefer-dist、--optimize-autoloader、--classmap-authoritative这四个不是可选优化，是生产部署的硬性组合。少一个，提速就打折。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

--no-dev跳过require-dev包，省掉30–60%时间
--prefer-dist强制走ZIP包，避免git clone带来的I/O和SSH开销
--optimize-autoloader生成静态类映射，PHP 7.4+下能进opcache
--classmap-authoritative告诉自动加载器“不在映射里=真没有”，彻底跳过文件扫描（注意：本地开发禁用，否则新增类直接Class not found）

CI推荐完整命令：composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative --no-interaction --no-progress

缓存路径别搞错：缓`~/.composer/cache`，别缓`vendor/`

缓存vendor/看似快，实则危险。不同PHP版本、扩展或OS下生成的autoloader不能混用，缓错版本会导致Class not found或Cannot declare class。

真正该缓存的是~/.composer/cache——它只跟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.lock但没提交，导致hashFiles算出的key不匹配。

换镜像本身不解决Resolving dependencies阶段卡顿——那阶段纯CPU计算，和网络无关。真正影响CI速度的，是镜像是否生效、缓存是否干净、参数是否齐全，这三件事漏掉任何一件，提速就落空。