最干净的临时切换镜像源方式是使用COMPOSER_REPO_PACKAGIST环境变量，Composer≥2.2原生支持，优先级高于config.json；示例：Linux/macOS下执行COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/composer/ composer install。
直接用环境变量临时切换镜像源
不需要改全局配置或临时修改 composer.json，最干净的方式是运行时通过 COMPOSER_REPO_PACKAGIST 环境变量指定镜像地址。Composer 从 2.2 开始原生支持该变量，优先级高于 config.json 中的设置。
- 国内常用镜像如阿里云：
https://mirrors.aliyun.com/composer/ - 腾讯云：
https://mirrors.cloud.tencent.com/composer/ - 华为云：
https://repo.huaweicloud.com/repository/php/
执行命令示例（Linux/macOS）：
COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/composer/ composer install
Windows CMD 下需分两步：
set COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/composer/<br>composer install
PowerShell 用户注意：变量名要加 $env: 前缀，且必须用双引号包裹 URL：
立即学习“PHP免费学习笔记（深入）”；
$env:COMPOSER_REPO_PACKAGIST="https://mirrors.aliyun.com/composer/"; composer install
为什么不用 composer config 临时改源
很多人习惯用 composer config repo.packagist composer https://xxx，但这会写入当前项目根目录下的 composer.json 或全局 ~/.composer/config.json，容易污染配置，且在 CI/CD 或共享脚本中不可靠。
- CLI 模式下无项目上下文时，
composer config默认操作全局配置，可能影响其他项目 - 即使加
--no-plugins --no-scripts，仍无法绕过配置持久化逻辑 -
COMPOSER_REPO_PACKAGIST是只读覆盖，进程退出即失效，更符合“临时”需求
遇到 Could not fetch packages 但镜像URL没错？
常见原因是镜像服务返回了重定向（302），而 Composer CLI 默认不跟随重定向（尤其在某些 PHP cURL 版本下）。这时需要额外加 -vvv 查看真实请求头和响应状态码。
- 确认镜像域名是否被本地 DNS 缓存污染，可尝试
curl -I https://mirrors.aliyun.com/composer/packages.json - 某些企业网络会拦截 HTTPS 重定向，可临时换用 HTTP 镜像（不推荐长期用）：
http://mirrors.aliyun.com/composer/ - PHP 的
openssl.cafile配置异常也会导致 TLS 握手失败，检查php -r "print_r(openssl_get_cert_locations());"
CI 场景下自动适配国内源
在 GitHub Actions、GitLab CI 等环境中，建议用条件判断 + 环境变量组合，避免硬编码。例如 GitHub Actions 的 job 步骤中：
- name: Install dependencies<br> env:<br> COMPOSER_REPO_PACKAGIST: ${{ contains(matrix.os, 'ubuntu') && 'https://mirrors.aliyun.com/composer/' || 'https://packagist.org/' }}<br> run: composer install --no-interaction注意点：
- 不要在
composer.lock提交前临时改源，否则 lock 文件里记录的 dist URL 会变成镜像地址，导致其他开发者拉取失败 - 如果项目依赖私有包，确保镜像源支持代理私有仓库（阿里云镜像支持
packagist.org全量同步，但不代理私有源） -
COMPOSER_REPO_PACKAGIST不影响repositories数组里的自定义源，仅覆盖默认 packagist.org
真正要小心的是多层嵌套调用——比如某个 PHAR 工具内部执行 exec('composer ...')，它不会继承父进程的环境变量，得显式透传。
