镜像仅加速下载，不解决“Resolving dependencies”卡顿；真实原因多为PHP内存不足、xdebug启用、platform配置错配或composer.lock残留问题。
还原镜像本身不能提升依赖解析成功率——它只改变元数据来源；真正卡在 Resolving dependencies 的，99% 是 PHP 环境或 lock 文件问题，不是源地址的事。
为什么删了镜像还卡在 Resolving dependencies
这个阶段完全不发网络请求，Composer 只在本地解析 composer.json 和 composer.lock 中的约束关系。常见真实原因：
-
memory_limit过低（如 128M），尤其在依赖树深的项目中会反复重试 → 临时加COMPOSER_MEMORY_LIMIT=-1测试 - 启用了
xdebug（运行php -v看输出里有没有 xdebug）→ 解析慢 5–10 倍，用php -d xdebug.mode=off $(which composer)临时绕过 -
platform配置与实际 PHP 版本不匹配（例如"php": "7.4"却在 PHP 8.2 上运行）→ Composer 被迫降级查找兼容版本，耗时剧增 -
composer.lock里残留已下线包的引用（比如某私有包被删除、或 packagist.org 上某个旧版本被移除）→ 回退搜索失败，卡死
还原镜像的正确操作顺序
还原不是“删一个配置就完事”，必须同步清理三层残留：
- 删全局镜像字段：
composer config -g --unset repos.packagist（Composer 2.x 用复数repos）和composer config -g --unset repo.packagist（1.x 兼容写法，也得删） - 清缓存：
composer clear-cache—— 不执行这步，packages.json快照仍来自镜像，后续所有操作都错 - 检查项目级覆盖：
grep -A 5 '"repositories"' composer.json（Linux/macOS）或手动打开composer.json查repositories块，存在则删或改回"packagist.org": true
验证是否真还原：运行 composer require monolog/monolog --no-install -vvv，看日志里 Downloading 行的 URL 是否为 https://repo.packagist.org，而不是任何 mirrors.* 域名。
环境变量可能偷偷覆盖配置
即使删光了 JSON 配置，COMPOSER_REPO_PACKAGIST 环境变量仍能强制走镜像：
- Linux/macOS：运行
env | grep COMPOSER_REPO，若输出非空，用unset COMPOSER_REPO_PACKAGIST清除 - Windows：运行
echo %COMPOSER_REPO_PACKAGIST%，若非空，需在系统或终端中取消该变量 - CI/CD 脚本里常被硬编码，比如 GitHub Actions 的
env:块或 Dockerfile 的ENV指令，也要一并检查
还原镜像最易被忽略的点：它只是让 Composer 回到原始行为路径，但不会修复你本地 PHP 版本、xdebug、内存限制或 lock 文件损坏这些底层问题。别在删配置上反复折腾，先确认 Resolving dependencies 卡住时终端里有没有报 PHP Fatal error: Allowed memory size exhausted 或 xdebug 相关痕迹——那才是真正的病灶。
