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。
典型场景：你在调试一个刚改完的内部工具包，主项目通过 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、返回了什么状态码——这才是定位问题的第一手证据
