Composer报“Could not find a version”主因是minimum-stability与目标版本稳定性标签不兼容，非网络或包不存在；需用composer show -a查实际版本标签，优先对单个包加@dev后缀或配置repositories声明私有源。
“Could not find a version of package matching your minimum-stability” 不是网络问题，也不是包不存在，而是 Composer 拒绝安装——因为当前 stability 设置和目标版本的标签不兼容。
为什么 composer require 突然报 stability 匹配失败
Composer 默认只信任 stable 版本（即打了正式 tag 且无后缀的版本），而很多活跃开发中的包只有 dev-main、v4.0.x-dev 或 3.2.0-beta 这类带稳定性标签的版本。一旦你在 composer.json 中没显式允许它们，Composer 就会直接跳过，报“找不到匹配版本”。
-
minimum-stability是全局开关，设为"dev"后所有包都可能降级到开发版，但不设它，哪怕包存在dev-main，也进不了安装队列 -
prefer-stable: true不会绕过过滤，它只在多个可选版本中优先挑 stable 的；如果唯一可用的是dev-main，而minimum-stability是stable，那它连候选资格都没有 - 分支别名（如
dev-main）不是版本号的一部分，写成"vendor/pkg": "main"或"vendor/pkg": "dev"都无效，必须写全"dev-main"
怎么快速确认该包到底有哪些可用版本
别猜，直接问 Composer：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer show -a vendor/package-name，输出里每行末尾的(stable)、(dev)、(beta)就是它的实际稳定性标签 - 如果返回
Package not found，说明包名拼错，或它根本不在你当前配置的源里（比如私有包没加repositories） - 如果返回了版本列表但没有你要的，比如你想装
^3.0，但列表里只有2.8.1和dev-main，那就只能换约束（如改用"dev-main"）或等正式发布
临时放宽稳定性限制的两种安全做法
全局改 minimum-stability 容易引发连锁升级风险，优先用更收敛的方式：
- 对单个包显式加
@后缀：运行composer require vendor/package:dev-main@dev，它会在require里自动补上该约束，不影响其他包 - 如果要长期用 dev 分支但又想保底稳定，可在
composer.json根节点加：{"minimum-stability": "dev", "prefer-stable": true}，然后明确指定"vendor/package": "dev-main"，而不是留空让 Composer 自选 - 切忌只改
minimum-stability却不加prefer-stable——这会让整个依赖树突然倾向不稳定版本，CI 构建可能第二天就挂
容易被忽略的缓存与镜像陷阱
即使你改对了配置，旧缓存或滞后镜像仍会让你反复看到“找不到”：
- 执行
composer clear-cache清掉本地元数据快照，否则 Composer 可能还在用上周的包索引 - 国内镜像（如阿里云）对
dev-分支、新提交的 tag 同步有延迟，临时切回官方源验证：composer config --global repo.packagist composer https://packagist.org - 私有 Git 仓库必须在
repositories里声明"type": "vcs"，否则 Composer 根本不会去那个地址拉元数据，报错一模一样，但原因完全不同
真正卡住人的往往不是语法或命令，而是把 dev-main 当成普通版本号来写，或者以为 clear-cache 能解决一切——其实它只清本地缓存，不修复镜像不同步或仓库未声明的问题。
