Composer默认拒绝dev-main等开发分支，因其无语义化版本映射，不被视作^3.0等约束的兼容版本；需包作者在composer.json中声明branch-alias，或改用--stability=dev显式允许安装。
开发版依赖（如 dev-main、dev-develop）冲突不是版本号问题，而是 Composer 无法验证语义化兼容性——它默认拒绝未打标签的分支，除非你明确告诉它“这个分支等价于某个稳定版本”。
为什么 composer require vendor/pkg:dev-main 总报 conflict
Composer 对 dev- 分支默认无版本映射，它不认为 dev-main 和 ^3.0 兼容，哪怕代码完全一致。报错里出现 Conclusion: don't install vendor/pkg dev-main，本质是约束链中某处写了 "vendor/pkg": "^3.0"，而 dev-main 不在该语义范围内。
-
branch-alias只对包作者声明有效：如果你 require 的是别人维护的包，且对方在composer.json里写了"branch-alias": {"dev-main": "3.0.x-dev"}，Composer 才会把它当3.0.x-dev处理 - 你自己控制的私有包，必须在它的
composer.json中显式加branch-alias，否则主项目 require 它的dev-main就永远和^3.0冲突 - 别手动在主项目的
composer.json里写"vendor/pkg": "dev-main as 3.0.x-dev"——这属于 hack，Packagist 不认，CI 里可能失败，且composer update时容易被覆盖
composer why-not 查不到 dev- 分支的阻塞源？
因为 why-not 默认只查已发布版本（tagged releases），对 dev- 分支不建模。当你运行 composer why-not vendor/pkg:dev-main，它可能返回空或 “nothing provides”，这不是命令失效，而是 Composer 根本没把 dev-main 当作一个可解析的版本候选。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先确认目标分支是否真存在于远端：运行
composer show vendor/pkg --all，看输出里有没有dev-main行 - 如果存在但
why-not仍无结果，说明冲突发生在平台约束层：比如该分支要求 PHP 8.2，而你本地是 PHP 8.1；或它conflict了你已装的symfony/consolev6 - 此时改用
composer requires -v或composer update --dry-run -v，日志里会暴露真实卡点，例如：Skipped branch dev-main: required PHP version (>=8.2) is not satisfied by your platform
测试环境要用 dev- 分支，又不想污染生产依赖
开发分支引入的不稳定依赖（比如 dev-main 拉来 phpunit/phpunit:dev-main）会通过 require-dev 渗透进整个解析过程，导致 composer install 在 CI 上失败，哪怕你加了 --no-dev。
- 把所有开发专用的
dev-依赖移到require-dev，并确保主require区块里全是稳定版本（^3.0、3.2.1等） - 在
composer.json顶部加"minimum-stability": "stable"，防止require-dev里的dev-分支意外影响主依赖树 - CI 部署脚本里用两步走：
composer install --no-dev装生产依赖，再单独composer require --dev vendor/pkg:dev-main装测试依赖（仅限开发机或 CI 的 test stage） - 注意：某些包（如 Laravel 的
orchestra/testbench）内部硬绑框架版本，dev-main可能要求laravel/framework:dev-main——这种链式开发依赖必须整体协调，不能只升一个
真正难处理的不是 dev- 分支本身，而是它绕过了语义化版本校验后暴露出的底层 API 不兼容。比如 dev-main 里删了一个方法，而你的代码还调着——Composer 不拦，PHP 运行时报错才真正发生。
