composer update卡在「Loading composer repositories」主要是因默认源packagist.org国内访问延迟高、dns不稳或被限速；其次缓存目录挂载慢速存储或权限不足，以及xdebug等扩展拖慢解析。
Composer update 为什么卡在「Loading composer repositories」
大概率是默认源走的是官方 packagist.org，国内直连延迟高、DNS 不稳，甚至被部分 ISP 限速。它不是卡在你本地，而是卡在发起 https 请求获取元数据这一步——哪怕只拉一个 composer.json，也会先尝试连接所有配置的仓库。
- 执行
composer config -g repo.packagist可确认当前全局源；若输出为{"type": "composer", "url": "https://packagist.org"}，就坐实了问题根源 - 临时切镜像源验证：运行
composer config -g repo.packagist composer https://packagist.phpcomposer.com（已停用）或改用https://mirrors.aliyun.com/composer/ - 阿里云镜像目前最稳，但注意它不支持某些私有包或 dev 分支的完整同步，生产环境切回官方源前建议先
composer clear-cache
cache-dir 被设成网络路径或权限异常
Composer 默认把下载的 ZIP 包和解压后的代码缓存在本地，路径由 cache-dir 配置决定。如果这个目录指向 NFS 共享盘、docker volume 绑定到慢速宿主机路径，或者当前用户没写入权限，update 就会反复失败重试，表现为「卡住几秒后报错再重试」。
- 查当前缓存位置：
composer config -g cache-dir；常见错误值如/mnt/data/composer-cache（挂载自机械硬盘）或/tmp/composer（某些系统 tmpfs 空间不足） - 安全做法是设回用户主目录：
composer config -g cache-dir "$HOME/.composer/cache" - 执行
ls -ld $(composer config -g cache-dir)确认目录存在且可读写；若提示No such file or Directory，手动创建并赋权：mkdir -p $HOME/.composer/cache
chmod 755 $HOME/.composer/cache
启用了 xdebug 或其他 PHP 扩展拖慢解析
Composer 是 PHP 脚本，启动时会加载全部启用的扩展。xdebug 在 CLI 模式下默认开启 profiler 或 trace，会让 json 解析、依赖图构建等操作慢 3–10 倍；某些杀毒软件实时扫描 .composer/cache 目录也会造成阻塞。
- 检查是否误启 xdebug：
php -m | grep xdebug；若存在，临时禁用：php -d extension= -d zend_extension= $(which composer) update - 跳过插件加载（排除第三方插件干扰）：
composer update --no-plugins - 加
-vvv参数看具体卡在哪一行：composer update -vvv 2>&1 | head -n 50，重点关注Reading ./composer.json和Downloading https://...之间的时间差
vendor 目录残留导致反复校验
当 vendor/ 已存在但 composer.lock 过期，Composer 会逐个比对已安装包的 composer.json 和远程元数据，而不是直接重装。这个过程涉及大量文件 stat + hash 计算，在大项目中可能耗时数分钟。
- 快速验证方式：删掉
vendor/和composer.lock，再跑composer install—— 如果这次飞快，说明原lock文件与 vendor 状态严重不一致 - 避免频繁
update：日常开发用composer install；只有明确要升级依赖时才update，且建议加--with-dependencies控制范围 - 慎用
composer update --lock：它只更新 lock 文件不装包，但后续install仍要校验，不如直接update干净
实际慢的原因往往不是单一配置，而是「镜像源 + 缓存路径 + xdebug」三者叠加。最值得优先排查的是 repo.packagist 配置和 cache-dir 的物理位置——这两项改完立刻见效，其余优化属于锦上添花。