镜像源是否生效需三重验证：执行composer config -g repo.packagist输出必须为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；运行composer install -vvv确认日志出现GET对应镜像URL；且项目级无repositories字段覆盖全局配置。
确认镜像源是否真生效
执行 composer config -g repo.packagist，输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的 JSON 对象。如果返回空、null、或仍是 https://packagist.org，说明配置没落进实际运行命令的用户环境里。
常见失效原因：
- CI 脚本里用
sudo composer config -g，写进了root的~/.composer/config.json，但 runner 用户读不到 - 拼错字段名，比如写成
repos.packagist（多一个s），会静默失败 - 漏掉
composer类型声明，命令变成composer config -g repo.packagist https://...，旧版会 fallback 回官方源
验证是否真走镜像：加 -vvv 运行 composer install，日志里出现 GET https://mirrors.aliyun.com/composer/p2/ 才算成功。
项目级配置比全局更可靠
在项目根目录运行：composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/。它会自动往 composer.json 的 repositories 字段安全追加，不覆盖已有私有源。
注意前提条件：
- 如果
composer.json里已有"repositories": []（数组格式），命令会报错；得先手动改成"repositories": {}（对象）再执行 - 别手写
"packagist.org": false——这会彻底关掉官方源，镜像临时不可用时，composer install直接失败 - 换源后首次
install若报 hash 校验失败，删掉vendor/和composer.lock重来即可
缓存 ~/.composer/cache，别缓存 vendor/
vendor/ 缓存看似快，实则危险：不同 PHP 版本、扩展或 OS 下生成的 autoloader 不能混用，缓存错版本会导致 Class not found 或 Cannot declare class。
真正该缓存的是 ~/.composer/cache——它只跟 composer.lock 哈希绑定，与环境无关。
在 .gitlab-ci.yml 中正确配置：
- 路径必须写
~/.composer/cache，不是vendor或~/.composer - 建议按
${PHP_VERSION}或composer.lock内容设key，避免跨版本污染 - 换镜像后首次运行前，加
composer clear-cache，否则旧源还在内存里苟着
CI 中必用的安装参数组合
--no-dev --prefer-dist --optimize-autoloader --classmap-authoritative 不是可选项，是生产构建底线配置。
各参数作用：
-
--no-dev：跳过require-dev，缩短时间、减小体积 -
--prefer-dist：优先下载 zip 包而非 clone Git 仓库，避开 SSH、Git 协议阻塞和超时 -
--optimize-autoloader：把 PSR-4 映射编译成静态数组 -
--classmap-authoritative：禁用file_exists()探测，autoload 性能提升数倍
CI 部署命令应为：composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative --no-interaction。
容易忽略的一点：这些参数对 composer update 无效，它卡在 Resolving dependencies 阶段，和镜像源完全无关——那是依赖解析算法或 composer.json 写法的问题。
