composer cli 默认读取当前用户主目录的 ~/.composer/config.json，ci/cd 或定时任务中若用户上下文不同则可能未加载全局源配置；临时换源应优先使用 --repository 参数（composer 2.2+），旧版本需用 composer config repositories.packagist 动态设置并及时清理。
为什么 composer install 在 CLI 下不读取全局源配置？
因为 PHP-CLI 环境下，Composer 默认仍走当前用户主目录的 ~/.composer/config.json，但如果你在脚本中用 proc_open() 或 shell_exec() 调用 Composer，又没显式指定用户上下文（比如用 www-data 用户执行），就可能读错配置文件——更常见的是：你改了全局源，但 CI/CD 或定时任务里跑的 CLI 进程根本没加载你的修改。
临时换源最稳的方式：用 -g + --repository 参数
别碰 COMPOSER_HOME 环境变量或改全局 config，容易污染其他项目。直接在命令行里用 composer create-project 或 install 时加参数：
composer create-project laravel/laravel myapp --repository=https://packagist.phpcomposer.comcomposer install --repository=https://mirrors.aliyun.com/composer/
注意：--repository 是 Composer 2.2+ 原生支持的参数，低版本会报错“Unknown option”。如果用旧版，必须降级为 config 命令临时写入（见下一条）。
兼容旧版 Composer 的临时方案：用 config 命令动态覆盖
旧版不认 --repository，但可以用 composer config 写入当前目录下的 composer.json 临时仓库地址，且不修改全局配置：
composer config repositories.packagist composer https://mirrors.aliyun.com/composer/-
composer install（此时会优先读当前目录composer.json里的仓库配置） -
composer config --unset repositories.packagist（用完立刻清理，避免下次误用）
关键点：repositories.packagist 是特殊键名，表示覆盖默认 packagist.org 源；不能写成 repositories.0 或随便起名，否则无效。
CI/CD 中常踩的坑：PHP-CLI 用户权限和缓存冲突
在 GitHub Actions、GitLab CI 里跑 composer install，即使加了 --repository，也可能因缓存未清而继续走旧源：
- 每次执行前加
composer clear-cache - 确认运行用户有写权限到
~/.composer/cache，否则缓存写失败，降级回网络请求旧源 - 避免在
composer.json里硬编码repositories，CI 场景应完全靠命令行参数控制
临时源只解决下载路径问题，不解决证书、DNS 或代理问题——如果连不上镜像站，先 curl -I https://mirrors.aliyun.com/composer/ 看是否通，别一上来就怀疑 Composer 配置。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
