应将 minimum-stability 设为对应稳定性级别（如 "dev"）并置于 composer.json 根对象，或在 require 中为包指定带 @ 后缀的版本约束（如 "@dev"）；修改后需运行 composer update --lock，并用 composer show -a 确认包实际可用版本及其稳定性标签。
Composer 报错 “Could not find a version of package matching your minimum-stability”
这是 Composer 在解析依赖时明确拒绝安装某个包的信号，根本原因不是包不存在，而是你当前的 minimum-stability 设置（默认 stable）和该包可用版本的稳定性标签（如 dev-main、beta、RC）不匹配。
如何让 Composer 安装非 stable 版本？
有且仅有两个合法方式，不能靠“跳过检查”或“强制拉取”，否则会破坏依赖一致性：
- 在
composer.json根对象中显式设置"minimum-stability": "dev"（或"beta"、"RC"），同时建议加上"prefer-stable": true以优先选 stable 版本，仅在必要时降级 - 对单个包使用
require时指定带稳定性后缀的版本约束，例如："monolog/monolog": "^3.0@dev"或"laravel/framework": "dev-master" - 注意：
@stable是冗余写法（默认行为），@dev才是真正放宽限制的关键标记
为什么设了 minimum-stability 还报错？
常见陷阱不是配置没写，而是位置或逻辑冲突：
-
minimum-stability必须放在composer.json的最外层对象（与require同级），写在config或extra里完全无效 - 如果项目已存在
composer.lock，改完minimum-stability后必须运行composer update --lock（或直接composer update）才能重新解析依赖图 - 某些包在 Packagist 上没有对应 stability 标签的版本（比如只有
v1.0.0，但你写了"vendor/pkg": "@beta"），此时仍会失败——得查该包实际发布的版本列表
查看包真实可用的稳定性版本
别猜，直接查：
composer show -a vendor/package-name
输出中每行版本号末尾的括号内容就是其 stability 标签，例如：
v2.5.0 (stable) v3.0.0-beta1 (beta) dev-main (dev)
只有括号里的值 ≥ 当前 minimum-stability 级别（按 dev 排序），才会被纳入候选范围。
稳定性不是质量担保，只是发布流程标记；用 dev 版本前务必确认它是否含你需要的 commit，且团队能接受无语义化版本控制的风险。
