先确认分支名是否为合法的dev-xxx格式且与远程仓库分支名完全一致；再检查repositories配置、minimum-stability设置、认证及缓存，最后用composer update而非install刷新解析。
Composer报“Could not find a matching version”时，先确认分支名写法是否合法
错误往往不是分支真不存在，而是 Composer 拒绝解析你写的分支名。它只认 dev-xxx 格式，且 xxx 必须和远程 Git 仓库里实际存在的分支名**一字不差**（包括大小写、斜杠、连字符）。比如远程分支叫 feature/auth-v2，你就得写 dev-feature/auth-v2，写成 dev-feature-auth-v2 或 dev-auth-v2 都会失败。
常见误操作：
- 漏掉
dev-前缀，直接写main或develop→ Composer 当成版本号去 Packagist 查，自然找不到 - 分支名含斜杠但没转义或拼错，如把
release/2.4.x写成release-2.4.x - 远程仓库已重命名分支（例如从
master改为main），但本地还沿用旧名
验证远程分支是否存在，别只信 GitHub 页面显示
GitHub 界面可能缓存或展示不全，最可靠的方式是直接查 Git 远程源：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 进到包的 Git 仓库主页（如
https://github.com/vendor/package），点 Branches 标签页，确认目标分支在列表中且非灰色（即未被删除） - 用命令行快速验证：
git ls-remote --heads https://github.com/vendor/package.git，输出里应有对应分支名，如refs/heads/main - 私有仓库（GitLab/GitHub Enterprise）需确保当前环境能访问该地址，必要时配置
auth.json或 SSH key
minimum-stability 和 prefer-stable 会影响分支识别
即使分支名完全正确，Composer 仍可能跳过它，只因稳定性策略拦住了：
-
"minimum-stability": "stable"（默认值）会直接过滤所有dev-分支，无论你写得多对 - 更安全的做法是保持
"minimum-stability": "stable"，仅对单个包放宽："require": { "vendor/package": "dev-main@dev" }，其中@dev显式声明接受不稳定版本 - 若已设
"prefer-stable": true，它不会阻止dev-安装，但会优先选 stable 版；加@dev可绕过该偏好
repositories 配置缺失或路径错误导致 Composer 根本不去查那个仓库
包不在 Packagist 上，或你想用 fork 的仓库，就必须手动告诉 Composer 源在哪。否则它永远只查 Packagist，自然报“not found”：
- 检查根目录
composer.json是否有repositories字段，且类型为vcs，url指向正确的 Git 地址（如"https://github.com/yourname/package"） - URL 必须可公开访问，或已配好认证；私有 GitLab 项目要确保
auth.json里有对应 token - 如果用的是
path类型仓库（如本地开发），url必须是相对路径，且不能跨出项目根目录（../不被允许）
最易被忽略的一点：改完 composer.json 后，必须运行 composer update vendor/package（带包名），而不是 composer install——后者只读 composer.lock，根本不会重新解析分支名。
