答案是本地缓存元数据未更新或版本未被packagist索引——运行composer show -a vendor/package-name查看真实可用版本，若缺失目标版本则说明该版本未发布、已下架或tag不规范；需手动清理镜像缓存目录并比对p2接口确认同步状态。
Composer 报 “Could not find a matching version” 找不到历史版本，90% 不是镜像挂了，而是你本地缓存的元数据没更新，或者那个版本压根没被 Packagist 索引过。
composer show -a 输出里没有你要的旧版本？先信它，别猜
运行 composer show -a vendor/package-name 是唯一可信的“当前可用版本清单”。它不查网页、不读文档、不依赖记忆——只读本地缓存的元数据（packages.json 和 p/vendor/package-name.json）。
- 如果返回
Package not found：包名拼错、大小写不符（Linux 下monolog/monolog≠Monolog/Monolog），或项目级repositories配置屏蔽了所有源 - 如果返回了列表但缺你要的版本（比如只有
2.8.1和dev-main，你要1.6.0）：不是镜像延迟，是该版本从未发布到 Packagist，或已被作者删除 tag / 标记为 abandoned - 如果列表里有
1.6.0@stable，但你写的是1.6.0：必须显式加@stable，或配置minimum-stability
curl 直接比对官方源和镜像源的 p2 接口
Packagist 网页显示有 v1.6.0，不代表镜像已同步。真正决定 Composer 能否识别的，是 p2/ 接口返回的 JSON 结构。
- 查官方源：
curl -s https://packagist.org/p2/vendor/package-name.json | jq -r '.packages."vendor/package-name" | keys[]' | sort - 查镜像源（以阿里云为例）：
curl -s https://mirrors.aliyun.com/composer/p2/vendor/package-name.json | jq -r '.packages."vendor/package-name" | keys[]' | sort - 两组输出不一致 → 镜像滞后；完全为空 → 镜像未同步该包，或包本身未进 Packagist
手动清理 provider 缓存目录，不是 clear-cache
composer clear-cache 只删 ZIP 包和部分 JSON，对 packages.json 和 provider-*.json 几乎无效。镜像同步延迟的本质，是你本地还拿着过期的索引文件。
- 找到对应镜像缓存路径：
ls -d $(composer config --global cache-dir)/repo/https---mirrors.aliyun.com-composer（URL 中/被转义为---） - 直接删掉整个目录：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors.aliyun.com-composer - Windows 用户路径类似：
%APPDATA%\Composer\cache\repo\https---mirrors.aliyun.com-composer - 删完再跑
composer show -a vendor/package-name，Composer 会强制重拉最新元数据
确认该旧版本是否真实存在于 Packagist 生态
很多“找不到”的旧版本，根本不在 Packagist 上——它们没提交、没打标准 tag、或作者已下架。
- 访问
https://packagist.org/packages/vendor/package-name，看 “Versions” 标签页是否列出你要的版本 - 非标准 tag（如
release-1.6.0、v1.6.0-final）不会被索引；Composer 只认1.6.0或v1.6.0 - 用 Git 直查真实 tag：
git ls-remote --tags https://github.com/vendor/repo.git，注意区分轻量 tag（1.6.0）和附注 tag（1.6.0^{}） - 若
curl -I https://packagist.org/p/vendor/package-name.json返回 404 → Packagist 官方都没收录，换任何镜像都无解
最常被忽略的点：你以为在用镜像，其实项目级 repositories 配置早已静默覆盖全局设置；你以为版本存在，其实它只是 Git 仓库里的一个未推送 tag 或废弃分支。验证永远比猜测快。
