Composer报“Could not find a version…matching minimum-stability”根本原因是稳定性标签不匹配，而非包不存在；需用composer show -a确认真实版本及标签，并通过@dev等显式约束或调整minimum-stability（须置于composer.json顶层）解决。
直接结论： Composer 报 “Could not find a version of package … matching your minimum-stability” 不是包不存在，而是你当前的 minimum-stability（默认 "stable"）和该包实际发布的版本标签（如 dev-main、v3.0.0-beta1）不兼容——必须显式允许，不能跳过检查。
为什么 minimum-stability 改了还报错？
常见配置失效不是因为写错了值，而是位置或上下文不对：
-
minimum-stability必须放在composer.json的最外层对象中（与require、autoload同级），写在config或extra里完全无效 - 改完后没运行
composer update --lock，composer.lock仍按旧规则锁定依赖，导致install阶段继续拒绝 - 包本身根本没发布对应稳定性的版本：比如你写了
"vendor/pkg": "@beta"，但composer show -a vendor/pkg输出里只有v2.0.0 (stable)和dev-main (dev)，没有beta标签的版本，照样失败
composer require 加 @dev 和设全局 minimum-stability 有什么区别？
本质是作用范围和风险控制粒度不同：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 用
composer require vendor/pkg:dev-main或composer require vendor/pkg:^2.0@dev：只影响这一个包，composer.json中会自动写成"vendor/pkg": "dev-main"或"vendor/pkg": "^2.0@dev"，其他包照常走stable策略 - 设
"minimum-stability": "dev"：整个项目所有依赖都可能降级到dev-分支，哪怕某个包有v1.5.0 (stable)，Composer 也可能选dev-main—— 除非同时配"prefer-stable": true -
@stable是冗余写法（默认行为），@dev才是真正放宽的关键标记；@alpha、@beta同理，但必须确保包真有对应标签的版本
怎么确认包到底有哪些可用版本和稳定性标签？
别猜，别看 README，用命令直接查真实元数据：
- 运行
composer show -a vendor/package-name，输出每行末尾括号里的内容就是该版本的稳定性标签，例如：v2.5.0 (stable)v3.0.0-beta1 (beta)dev-main (dev) - 只有括号内标签的稳定性等级 ≥ 当前
minimum-stability设置（按dev > alpha > beta > RC > stable排序），才会被纳入安装候选 - 如果
composer show返回 “Package not found”，说明包名拼错、不在 Packagist、或你用了私有仓库但没配repositories；此时需先验证源是否可达，比如临时切回官方源：composer config --global repo.packagist composer https://packagist.org
最容易被忽略的一点：即使你写了 "prefer-stable": true，只要某个包在 require 中明确指定了 @dev 或 dev-main，Composer 就会装它——这个优先级高于 prefer-stable。所以问题往往不出在“没开开关”，而出在“开关开了但目标版本压根没发布”。
