应使用"type": "package"仓库类型，为每个私有包显式声明name、version和dist字段，并将其置于repositories数组最前面，以确保私有包绝对优先且仅提供指定包。
Composer 的 repositories 怎么只让某个私仓提供特定包？
Composer 本身不支持“仓库级包名白名单”，但可以通过 repositories + package 类型仓库组合实现精准控制：把私仓声明为 "type": "package"，手动列出它**实际提供的每个包版本**，其他包完全不会被 Composer 检索到。
这是最可靠的方式，绕过了默认的 composer 类型仓库（会全量扫描 packages.json）带来的泛匹配风险。
- 必须用
"type": "package"，不能用"type": "composer"或"type": "vcs" - 每个包需显式写出
name、version、dist（或source）字段，Composer 不会自动发现 - 多个包就写多个
package条目，放在同一repositories数组里
{
"repositories": [
{
"type": "package",
"package": {
"name": "mycorp/utils",
"version": "1.2.0",
"dist": {
"url": "https://artifacts.mycorp.com/utils-1.2.0.zip",
"type": "zip"
}
}
},
{
"type": "package",
"package": {
"name": "mycorp/logger",
"version": "3.1.5",
"dist": {
"url": "https://artifacts.mycorp.com/logger-3.1.5.tgz",
"type": "tar"
}
}
}
]
}
为什么不用 composer 类型仓库做过滤？
因为 "type": "composer" 仓库依赖远程 packages.json 文件，只要该文件里列出了某个包（哪怕你没装），Composer 就可能在 require 时尝试从它解析——尤其是当多个仓库都声明了同名包时，优先级逻辑容易失控。
典型问题包括：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer require vendor/unknown-package报错说 “could not find package”，但其实私仓的packages.json里误写了这个包名（比如拼写错误或历史残留） - 私仓管理员上传了测试包
mycorp/test-helper，但你不希望任何项目意外拉取它，而composer类型仓库无法阻止这种“可见性” - 想让私仓只服务
mycorp/*命名空间，但 Composer 没有通配符白名单机制
composer.json 中 repositories 的加载顺序影响包来源吗？
影响。Composer 按 repositories 数组**从上到下**扫描可用包，一旦在某个仓库找到匹配的 name + version，就不再继续往后查。所以要把精确控制的 package 类型仓库放在前面，再放其他通用仓库（如 packagist.org 的镜像）。
- 错误顺序：
packagist.org在前 → 私仓里的mycorp/utils可能被忽略（如果 Packagist 上也有同名包） - 正确顺序：你的
"type": "package"仓库排第一，确保私有包绝对优先 - 注意：设置
"packagist.org": false后仍要显式添加镜像仓库，否则连公共包都装不了
用 composer config 动态加仓库时怎么避免污染全局？
别用 composer config -g。全局配置会影响所有项目，且无法按项目做包级隔离。应该始终在项目根目录的 composer.json 里维护 repositories，或者用 composer config --file=composer.json 显式指定路径。
另外，运行 composer update 前务必确认 composer.lock 里记录的包来源是否符合预期——打开它搜 "source" 或 "dist" 字段，能看到每个包实际来自哪个 URL。这点常被忽略，但它是验证仓库过滤是否生效的最终依据。
