Composer查包严格按repositories数组从上到下线性匹配，首个声明支持目标包的仓库即生效，后续全跳过；必须用索引数组、私有源置顶、显式设{"packagist.org": false}于其后，且私有源packages.json须含完整元数据。
repositories数组顺序决定查找路径，但不等于“谁先写谁赢”
Composer 会从 repositories 数组索引 0 开始逐个检查，但**只对声明支持目标包的仓库发起请求**。如果第一个仓库没在 packages、provider-includes 或 pattern 中覆盖你要装的包（比如 myorg/utils），它就直接跳过，不会发 HTTP 请求——哪怕 URL 是有效的，也不会触发“查不到就往下走”的逻辑。
常见错误现象：
-
composer require myorg/utils报Could not find package，但curl -I https://my-company.example.com/packages.json返回 200 OK → 实际日志里根本没访问这个地址，因为前面的镜像源返回了空{"packages":{}} - 私有 Satis 源没生成
provider-includes，导致每次拉全量packages.json，体积大、解析慢，你却以为是“顺序没生效” - 写了两个私有源，都声明支持
monolog/monolog，但 Composer 只取第一个返回元数据的，后一个完全被忽略，行为未定义
"packagist.org": false 不是开关，是“终止符”
这个键值对不是全局禁用 Packagist 的配置项，而是 repositories 数组里的一个特殊哨兵对象：它只在被遍历到时起作用，告诉 Composer “别再隐式兜底了”。如果把它放在私有源前面，Composer 查完私有源后立刻碰到它，判定“无源可用”，直接报错退出；必须放在私有源之后、数组末尾。
正确结构示例：
"repositories": [
{ "type": "composer", "url": "https://my-company.example.com" },
{ "packagist.org": false }
]
关键细节：
- 必须是独立对象，不能嵌套进其他仓库定义里（比如不能写成
{"type":"composer","url":"...","packagist.org":false}） - 键名必须是
"packagist.org"，写成"packagist"或"packagist.com"都无效 - 禁用后若还需公共包，得手动加回官方源，并确保排在它之后：
{"type": "composer", "url": "https://packagist.org/"}
项目级 repositories 会整块覆盖全局配置
只要项目 composer.json 里存在 "repositories" 字段（哪怕只是空数组 "repositories": []），全局 ~/.composer/config.json 里的所有仓库配置都会被丢弃——不是合并，不是追加，是彻底替换。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
验证方式：
- 运行
composer config repositories，确认输出和你写的完全一致 - 如果输出里还有
https://repo.packagist.org，说明项目配置没生效，或被误删/覆盖 - 临时验证可执行
composer config --unset repositories（慎用，可能影响私有包拉取）
安全追加镜像的推荐做法是：composer config repo.packagist composer https://mirrors.aliyun.com/composer/，它会自动 merge 到 repositories 对象中，不破坏已有私有源。
type=package 仓库最容易引发静默劫持
"type": "package" 是手动声明单个包元信息的方式，但它没有自动发现能力，且一旦出现在 repositories 数组靠前位置，就会拦截所有对该包名的请求，包括 dev-main、dev-feature/x 这类开发分支。
典型问题：
- 你写了
"version": "1.2.3"，Composer 就只认这个字符串，不会去 Git 仓库 fetch tag，也不会响应composer update --with-dependencies的版本推导 - 同名包在其他仓库中的任何版本（包括更新的
v2.0.0）都会被完全忽略 - 混用
type=vcs和type=package容易踩坑：前者走 Git 元数据解析，后者走静态 JSON，优先级判断逻辑不同，结果难预测
真正容易被忽略的是：冲突往往藏在 require-dev 里，而 composer why-not 的输出最后一行才是你的根项目约束——逆推读，不是顺读。
