minimum-stability 是 Composer 的“信任阈值”，默认 stable，限制仅安装稳定版本；改为 dev 会导致所有依赖倾向拉取开发版而引发报错；正确做法是保持默认，仅对目标包用 "vendor/package": "dev-main" 等显式约束。
minimum-stability 是什么，为什么改它会出问题
minimum-stability 不是开关，而是 Composer 的“信任阈值”。它默认设为 stable，意思是：除非你显式声明某个包要装 dev-main 或 beta 版本，否则 Composer 会跳过所有不稳定版本（dev-、alpha、beta、rc）。
直接在 composer.json 里把 minimum-stability 改成 dev，看似能装开发版，实则会让所有依赖（包括 Laravel、Symfony 这类主包）都倾向拉取 dev-main，项目大概率当场报错或无法启动。
想装某一个包的 dev 分支，别动 minimum-stability
真正安全的做法是：保持 minimum-stability 为 stable（或不写，默认就是），只对目标包单独指定版本约束。
常见错误现象：Could not find package vendor/package with stability dev，其实不是包不存在，是 Composer 按默认策略过滤掉了。
- 在
require中用带分支名的版本号，比如："vendor/package": "dev-main"或"vendor/package": "dev-develop" - 如果该分支没加
composer.json里的minimum-stability兼容声明，需同时加"prefer-stable": true防止意外拉到其他不稳依赖 - 若提示
Your requirements could not be resolved，大概率是这个dev-分支依赖了其他不兼容的 dev 包，得顺藤摸瓜补上对应约束
什么时候才该调低 global minimum-stability
只有两种真实场景值得动它：
- 你在搭内部工具链，所有包都由自己维护，且统一走
dev-main流水线 - 你正在给某个开源库贡献 PR，需要本地复现其
dev分支行为，并确认下游集成没问题
即使在这两种情况下，也建议：
- 把
minimum-stability设为dev后，立刻加上"prefer-stable": true，避免全量降级 - 不要提交修改后的
minimum-stability到主分支，CI 和队友会遭殃 - 用
composer require vendor/package:dev-main --no-update先锁版本，再composer update vendor/package精准更新，比全量update安全得多
dev 分支安装失败的三个高频原因
dev- 版本不是“随便就能装”，它受制于仓库类型、分支可见性、以及包自身配置：
- GitHub/GitLab 仓库必须公开，或你在
auth.json里配了正确的 token（私有仓库尤其容易卡在这） - 包的
composer.json里没写"minimum-stability": "dev"，且没在autoload或autoload-dev中声明开发所需文件路径，导致自动加载失败 - 你用了
dev-master，但原仓库已删掉master分支（现在默认是main），应改用dev-main
最常被忽略的一点：Composer 默认不会为 dev- 版本生成 autoloader 映射，除非你在 composer.json 里明确写了 "autoload": {"psr-4": {...}} —— 很多临时写的测试包漏了这行，装得进去，跑不起来。
