Composer镜像改回原厂_针对不同网络环境调整

直接执行 composer config -g repo.packagist composer https://packagist.org 就能强制全局启用官方源，这个方法比单纯删配置要稳得多——尤其在使用 Composer 2.2 到 2.4 这些版本时，--unset 经常出现 fallback 失败的情况，结果就是 update 卡在半路，或者直接报 Could not parse version constraint 的错。

为什么 composer config -g --unset repos.packagist 不总能见效

这个命令只删掉了全局配置里的 repos.packagist 字段，但 Composer 查源的优先级顺序是：环境变量 > 项目级配置 > 全局配置。换句话说，就算全局配置删得干干净净，只要当前项目的 composer.json 里还残留着 "repositories" 区块，项目级配置就会抢先一步生效。

• 检查项目是否覆盖：运行 composer config repos.packagist（不加 -g），如果输出的是镜像地址，说明项目级配置还在发挥作用。
• 旧项目可能混用两种写法：repo.packagist（单数）和 repos.packagist（复数），需要分别清除：composer config -g --unset repo.packagist 和 composer config -g --unset repos.packagist。
• 有些脚手架（比如老版的 Lara vel 安装器）会在项目配置里写 "repositories": {"packagist.org": false}——这相当于关闭了源但又没给替代方案，光是删 repos.packagist 根本没用，必须直接删除整个 "repositories" 字段。

怎么确认当前真正生效的源地址

别只看 config -g 的输出，因为那只是全局配置的快照，实际请求到的是哪个域名才是关键。最稳妥的办法是加上 -vvv 参数，盯着元数据下载的真实 URL：

• 运行 composer require monolog/monolog --no-install -vvv
• 在日志里搜索 Downloading 或 Loading，找到形如 Downloading https://repo.packagist.org/packages.json 的行——这才是真正生效的源。
• 如果看到的是 mirrors.aliyun.com 或 mirrors.cloud.tencent.com，说明还有某层配置在干扰。
• 顺手检查一下环境变量：Linux/macOS 跑 env | grep COMPOSER_REPO，Windows 跑 echo %COMPOSER_REPO_PACKAGIST%。

clear-cache 不是可选项，是必做动作

缓存不清空，Composer 依然会读取旧镜像缓存的 packages.json 快照，结果就是 update 找不到新包、锁文件错乱、甚至报 Package not found。

• 运行 composer clear-cache 后，检查缓存目录是否清空：Linux/macOS 下 ls -la ~/.composer/cache/，Windows 下 dir %APPDATA%\Composer\Cache\，应该为空或者只剩空子目录。
• 清完缓存再跑一次 composer show -p | head -3，如果能正常显示 composer/composer 这类包的信息，才算切换成功。
• 注意：清缓存对源配置本身完全无影响，它只删除 ~/.composer/cache/ 下的内容。有些人会误以为删掉整个 ~/.composer/ 目录就能解决，但 Composer 会自动生成默认配置——除非你事先设了环境变量。

还有一个很容易被忽视的细节：某些 IDE（比如 PHPStorm）可能会在项目设置里偷偷注入镜像源，改完配置后如果不重启 IDE，它依然按旧设置发起请求。