Composer支持多源共存，需在repositories数组中按顺序配置：GitHub/GitLab等Git仓库用"type": "vcs"，私有Packagist服务用"type": "composer"；vcs源URL必须可git clone，包名须与对应仓库composer.json中name一致；require dev分支时需设"minimum-stability": "dev"或加--stability=dev参数。
怎么让 Composer 同时从 GitHub、GitLab 和私有源拉包
Composer 本身不禁止多源共存，关键在于 repositories 数组的顺序和类型配置是否匹配真实托管平台特性。Git 仓库（GitHub/GitLab）必须用 vcs 类型，私有 Packagist 服务（如 Satis、Artifactory）才用 composer 类型；混用会导致元数据读取失败或跳过整个源。
常见错误是把 GitLab 仓库 URL 直接塞进 type: "composer"，结果 Composer 尝试去请求 packages.json 却收到 404 或 HTML 页面——因为 Git 服务器根本不提供这个接口。
-
repositories必须是数组，每个元素带明确type：GitHub/GitLab/自建 Gitee →"type": "vcs"；内网 Packagist →"type": "composer" - 多个
vcs源可以并存，但 Composer 不会自动合并它们的包列表；require 时仍需确保包的name字段与对应仓库中composer.json里声明的一致 - Git 仓库 URL 必须可被 git clone（比如
https://gitlab.example.com/team/utils.git），不能是网页地址（如https://gitlab.example.com/team/utils） - 若某源仅用于特定包，可在其配置中加
"packagist": false避免干扰全局包发现逻辑
require 时指定不同源的包，为什么总装不上 dev 分支
不是源没配对，而是 Composer 默认忽略非稳定版本。即使你已在 repositories 中正确声明了 GitLab 的 vcs 源，composer require acme/utils:dev-main 仍可能失败，除非项目级稳定性策略允许。
根本原因是：minimum-stability 默认为 stable，而 dev-main 属于 dev 稳定性级别，直接被过滤掉。
- 临时解决：运行
composer require acme/utils:dev-main --stability=dev，显式提升本次操作的稳定性阈值 - 长期方案：在项目
composer.json中设"minimum-stability": "dev"，同时加"prefer-stable": true，这样有 stable 版就优先用，没有才退到 dev - 注意：设
"minimum-stability": "dev"后，所有未显式指定版本的require都可能拉到 dev 分支，CI 构建容易因分支漂移失败 - Git 仓库中必须存在对应分支名（如
main），且该分支下composer.json的name字段值与 require 的包名完全一致
本地 path 仓库和远程 vcs 仓库能共存吗
能，而且很常用——比如开发阶段用 path 指向本地库，上线前切回 vcs 指向 GitLab。但必须手动切换，Composer 不会自动降级或 fallback。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
典型场景：你在调试一个刚改完的内部工具包，主项目通过 path 仓库链接它；同时该项目还依赖另一个已发布的 GitLab 包，走的是 vcs 源。两者互不干扰，只要 repositories 数组里都声明了就行。
-
path仓库的url必须是相对于主项目composer.json的有效文件路径，且目标目录含合法composer.json - 同一包名不能同时出现在
path和vcs中，否则 Composer 会报错：“Package … is listed in more than one repository” - 切换时别只改
require版本，记得同步删掉repositories里已废弃的条目，否则composer update仍会尝试访问旧路径或旧 Git 地址 -
path仓库默认启用 symlink，但若目标路径跨磁盘或容器挂载点（如 Docker 中 host 路径映射进 container），symlink 可能失效，此时需加"options": {"symlink": false}强制复制
为什么 clear-cache 后还是找不到私有包
清缓存只是删掉 ~/.composer/cache，但 Composer 查找包的核心依据是 repositories 配置 + 远程元数据响应。如果 Git 仓库返回 401、403 或超时，或者私有 Packagist 的 packages.json 根本没生成，clear-cache 完全无效。
最常被忽略的是认证和网络可达性：CI 环境通常没配 SSH key 或 Git 凭据，本地能 clone 成功不代表 Composer 在无交互环境下也能访问。
- 先验证源是否真正可用：手动执行
git ls-remote https://gitlab.example.com/team/pkg.git或curl -I https://pkgs.internal.company.com/packages.json - 对
vcs源，确保url使用 HTTPS 时已配置 Git 凭据（git config --global credential.helper store），或改用 SSH 并确认 agent 已加载 key - 对
composer类型私有源，检查其packages.json是否包含你要的包名，并确认该文件 HTTP 返回码是 200 而非 302 重定向 - 运行
composer install -vvv，看日志里实际请求了哪些 URL、返回了什么状态码——这才是定位问题的第一手证据
