禁用默认 Packagist 源后仍访问 packagist.org，因 Composer 2.0+ 将其设为元数据兜底；必须在 repositories 数组中显式声明 type: "packagist" 的替代源并同级配置 "packagist.org": false。
禁用默认 Packagist 源后 composer install 仍尝试访问 packagist.org？
这是最常被忽略的细节：禁用默认源不等于移除 Packagist 的元数据索引逻辑。Composer 在 2.0+ 中引入了「packagist.org 作为元数据兜底」机制，即使你设了 "packagist.org": false，只要没显式声明其他 packagist 类型仓库（比如私有镜像），composer install 仍可能在解析依赖时触发对 packagist.org 的 DNS 查询或 404 请求。
实操建议：
- 必须在
repositories数组中显式添加一个类型为packagist的替代源（哪怕只是空配置） - 确保
"packagist.org": false是repositories的子项，而非顶层配置 - 运行
composer config --global repositories.packagist false仅影响全局配置，项目级composer.json会覆盖它
repositories 中如何正确定义禁用 + 替代 packagist 源？
关键不是“删掉”，而是“替换并关闭”。错误写法是只写 {"packagist.org": false}；正确结构必须包含一个 type: "packagist" 的条目，并把 url 指向你的私有镜像（如阿里云、腾讯云或自建 Satis）。
示例（composer.json 中）：
{
"repositories": [
{
"type": "packagist",
"url": "https://mirrors.aliyun.com/composer/"
},
{
"packagist.org": false
}
]
}
注意点：
- 两个对象必须同在
repositories数组内，顺序无关 -
type: "packagist"条目会接管所有未限定仓库的包发现逻辑 - 若使用自建镜像，确保其支持
/packages/list.json和/p/[vendor]/[package]/[version].json接口
为什么 composer require 还会报 Could not find package xxx at any version？
这不是网络问题，而是 Composer 在禁用默认源后，无法自动推导出「哪些包属于哪个仓库」。尤其当你要安装的包从未在你指定的私有镜像中同步过，或者镜像本身未开启 full-sync 模式，就会失败。
排查路径：
- 先执行
composer show -p | grep xxx看包是否在当前可用仓库列表中 - 检查私有镜像后台日志，确认该包的元数据是否已拉取
- 临时启用 packagist.org 验证包是否存在：
composer config repositories.packagist.org https://packagist.org，成功后再手动同步到私有源 - 避免混用
type: "composer"和type: "packagist"仓库处理同一类包，会导致优先级冲突
config.repos.packagist 全局设置和项目级 composer.json 的优先级关系
项目级 composer.json 中的 repositories 始终覆盖全局配置。但容易被忽略的是：composer config --global repositories.packagist false 实际写入的是 ~/.composer/config.json，而该文件中的 repositories 是一个对象，不是数组 —— 它只能控制是否启用默认源，不能定义新仓库。
所以真正生效的禁用动作，必须落在项目级配置里。常见误操作：
- 只运行全局命令，没改项目
composer.json→ 无效 - 在项目中写了
"packagist.org": false，但漏了type: "packagist"替代项 → 降级回默认行为 - 用
composer config repositories.foo ...命令追加仓库，结果生成的是object而非array，导致解析失败
复杂点在于：Composer 不校验 repositories 结构合法性，错误配置只会静默失效或部分生效。
