答案是镜像同步延迟或本地provider缓存过期；应验证镜像配置是否正确（repo.packagist单数、type值、URL末尾斜杠）、检查镜像同步时间、清理~/.composer/cache/repo/下对应provider缓存，而非仅clear-cache。
报 Could not find package，90% 不是包不存在，而是 Composer 拿着过期缓存去查一个还没同步到镜像的包。
确认当前生效的镜像源是否写对了
很多人配完镜像发现没生效，是因为命令写错或漏参数。Composer 2.x 对配置格式很敏感：
-
composer config -g repo.packagist必须用单数repo.packagist，写成repos.packagist就静默失败 - 第三参数必须是
composer（type 值），不能省略，否则整条配置被忽略 - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌ - 必须加
-g，否则只写入当前项目，换目录就失效 - 验证是否成功：运行
composer config -g repo.packagist，输出应为类似{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
判断是不是镜像同步延迟导致的“假找不到”
阿里云、腾讯云等镜像通常滞后 1–6 小时，新发布的包（尤其是 dev 分支或刚打的 tag）大概率还没同步进来。别急着删缓存或重装：
- 打开浏览器访问
https://mirrors.aliyun.com/composer/，看右下角“最后同步时间”是否超过 30 分钟 - 直接查包是否存在：
curl -I https://mirrors.aliyun.com/composer/p/vendor/package.json，关注Last-Modified时间 - 临时切回官方源验证：
composer config -g repo.packagist '{"url":"https://packagist.org","type":"composer"}'，再跑composer show vendor/package - 如果官方源能查到，镜像源查不到，基本就是同步延迟——等或换源，不是你环境的问题
清理 provider 缓存，不是 clear-cache
composer clear-cache 清的是 dist 包和 zip 缓存，对 Could not find package 几乎无效。真正卡住的是本地 provider 缓存（比如 packages.json、provider-laravel-packages.json）：
- Linux/macOS：执行
rm -rf ~/.composer/cache/repo/https---mirrors.aliyun.com-composer - Windows：
rd /s /q "%APPDATA%\Composer\cache\repo\https---mirrors.aliyun.com-composer" - 清理后不用重启终端，直接再试
composer show vendor/package - 注意：不要用
composer clear-cache代替这步，它清不到 provider 层，问题照旧
子模块、私有包、path 类型仓库不走镜像
镜像只影响 packagist.org 类型的公开包。以下情况完全不经过镜像，报错和镜像无关：
- Git 子模块未初始化：
git submodule status输出带-或为空，说明内容没检出，composer.json根本读不到 - 私有包或
path类型仓库：必须在repositories字段明确定义，且子模块不继承父项目的镜像配置 - 包名拼错或大小写不符：比如
monolog/monolg（少个 o）、laravel/framework写成Laravel/Framework - PHP 版本不匹配：Composer 解析依赖时会过滤掉所有不满足
php约束的版本，结果“看起来像没找到”，实际是全被筛掉了
最常被忽略的点：你以为在查镜像，其实 Composer 连镜像服务器都没发请求——它查的是本地缓存里的 provider 列表；而那个列表，可能一周没更新了。
