Composer需通过repositories配置非Packagist源，支持vcs、package、path等类型；vcs自动识别Git标签分支，path用于本地开发并创建符号链接；包名必须与目标composer.json中name字段完全一致，否则无法安装。
Composer 默认只从 Packagist 拉取包，但很多企业私有库、GitHub 仓库、甚至本地开发中的扩展，并不在 Packagist 上。这时候不能靠 composer require vendor/name 直接装——得手动告诉 Composer “这个包在哪、怎么取”。
配置 repositories 指向非 Packagist 源
Composer 通过 repositories 字段支持自定义源，类型包括 vcs（Git/SVN/Hg）、package（单包声明）、path（本地路径）等。最常用的是 vcs。
-
vcs类型会自动探测 Git 标签和分支，适合 GitHub / GitLab / Gitee 等托管的开源或私有仓库 - 必须把
repositories写在项目根目录的composer.json中（不是全局配置），且需放在顶层，不能嵌套在其他字段里 - 如果源是私有仓库（如需要 SSH 或 token 认证），确保本地 Git 能正常 clone —— Composer 底层调用的就是
git clone
示例：添加一个 GitHub 私有仓库
{
"repositories": [
{
"type": "vcs",
"url": "https://github.com/your-org/your-private-package"
}
],
"require": {
"your-org/your-private-package": "^1.2"
}
}
包名必须与 composer.json 中的 name 完全一致
很多人配完 repositories 还是装不上，根本原因是：Composer 查找包时，不看 URL，只认 name 字段。你声明的 require 里的名字，必须和目标仓库根目录下 composer.json 里的 "name" 值一模一样（包括大小写和分隔符）。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 比如目标包的
composer.json写着"name": "acme/utils"，你就必须写"acme/utils": "^2.0"，写成"acme-utils"或"Acme/utils"都会失败 - 如果目标仓库没写
name，Composer 会拒绝识别——哪怕你用package类型硬声明，也得补上name - 运行
composer show可验证是否已识别该包；若没出现，先检查 name 是否拼错，再检查repositories是否生效（可加-vvv看调试日志）
使用 path 类型链接本地未发布的扩展
开发阶段频繁改代码时，用 vcs 太重（每次都要 commit + push + update），直接挂本地路径更高效。注意 path 是硬链接，不是拷贝。
- 路径可以是相对路径（如
../my-package）或绝对路径（如/home/user/my-package），但推荐相对路径，便于协作 - 目标目录下必须有合法的
composer.json，且含name和version（或dev-main这类分支别名） - 执行
composer install或composer update后，Composer 会在vendor/下创建符号链接（Linux/macOS）或复制（Windows），修改本地源码会实时反映到项目中 - 上线前务必删掉
path配置并切回vcs或正式 tag，否则部署机上路径不存在会导致失败
真正麻烦的不是配置本身，而是团队成员对 name 和 repositories 的理解不一致，或者忘了清理 path 就提交了 composer.json。建议把私有包的 name 写进 README 顶部，CI 流程里加一条检查 composer.json 是否含 "type": "path" 的断言。
