答案是镜像未同步或配置错误导致“could not find package”，需验证composer config -g repo.packagist输出完整json、清缓存与composer.lock、删vendor后用install -vvv确认请求域名是否为镜像地址。
不是镜像挂了，也不是包不存在，而是你正在请求一个还没同步到镜像的版本——90% 的 “Could not find package” 都卡在这一步。
确认当前到底连的是哪个源
别信自己“配过镜像”，composer config -g repo.packagist 输出为空、null 或 https://packagist.org，说明根本没生效。Composer 会静默 fallback 到官方源，后续所有操作都白忙。
- 正确配置命令只有一条：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意三段式：键名 +composer类型 + URL 末尾必须带/） - 项目级
composer.json里若存在repositories字段，会完全屏蔽全局镜像——用grep repositories composer.json检查，临时禁用运行composer config --unset repositories - 最可靠验证方式：
composer diagnose，找到Repo packagist.org:这一行，后面跟的 URL 必须是你设的镜像地址且结尾有/
清缓存 ≠ 清元数据，这两步都得做
composer clear-cache 只删 ZIP 和 VCS 缓存，对 packages.json 和 provider-*.json 几乎无效。旧元数据还在，Composer 就继续按失效地址发请求。
- Composer ≥ 2.5：运行
composer update --refresh，精准丢弃 provider 缓存，保留已下载包 - Composer ≤ 2.4：手动删目录：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors.aliyun.com-composer - 必须删掉
composer.lock——它硬编码旧 provider 地址，不删就永远 fallback
验证镜像是否真同步了目标包
别靠 composer show 猜，直接测镜像 API 返回：
- 访问
https://packagist.org/packages/vendor/name，确认包存在、版本号和发布时间 - 再访问对应镜像接口：
https://mirrors.aliyun.com/composer/p/vendor/name.json（注意是p/不是packages/） - 返回
HTTP/2 200且Last-Modified时间戳在 30 分钟内 → 已同步；返回404或时间差超 1 小时 → 还没同步 - 某些镜像（如阿里云）不主动同步
dev-main、dev-develop这类分支，即使 Packagist 上存在也会跳过——这时只能等，或临时切回官方源
版本约束写错也会报“找不到”
Composer 默认只匹配 stable 版本。你写 ^2.0.0，但作者只发布了 2.0.0-beta1，就会直接报错，而不是提示“版本不可用”。
- 先跑
composer show -a vendor/name看当前源里实际有哪些版本 - 如果只有预发布版本，必须显式加稳定性标记：
composer require vendor/name:2.0.0@beta或composer require vendor/name:@dev - 别乱改
minimum-stability或加@dev到require里——这容易引发整棵树依赖冲突，先确认是不是真没同步 - PHP 版本不兼容也会被伪装成“找不到”：运行
composer show --platform对比包的require.php字段
最容易被忽略的点：子模块目录为空、composer.lock 没删、镜像 URL 少了末尾斜杠——这三个问题占实际排查案例的 70% 以上。
