Composer的repositories是线性短路匹配，首个返回包信息的源即生效，后续全跳过；必须用索引数组、私有源置顶、显式设{"packagist.org": true}于末尾，type选错或顺序错误将导致源静默失效。
Composer 的 repositories 不是“多源并行”或“自动 fallback”，而是按数组顺序线性匹配，第一个能返回包信息的源就用它，后面的全跳过——配错顺序或漏关默认源，镜像就等于没配。
repositories 必须是索引数组，不能写成对象
常见错误是把多个源写成键值对，比如：
{"repositories": {"aliyun": {"type":"composer","url":"https://mirrors.aliyun.com/composer/"}, "tencent": {"type":"composer","url":"https://mirrors.cloud.tencent.com/composer/"}}}
这样只有最后一个（tencent）生效，前面的被 Composer 静默忽略。
- 必须写成 JSON 数组：
"repositories": [ {"type":"composer","url":"https://mirrors.aliyun.com/composer/"}, {"type":"composer","url":"https://packagist.org/"} ] - 每个元素是独立对象，不能嵌套在键下
- 顺序即优先级：越靠前的源越先被查询
packagist.org 默认被禁用，得手动加回且放最后
只要项目里定义了 repositories 数组，Composer 就自动设 "packagist.org": false —— 这不是 bug，是默认行为。不显式处理，composer require monolog/monolog 会直接报 Could not find package。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 要保留公共包能力，必须在
repositories数组末尾加{"packagist.org": true} - 不能写成
{"type": "composer", "url": "https://packagist.org/"}，那样会强制走官方源下载 ZIP，失去镜像加速意义 -
{"packagist.org": true}只用于元数据兜底（查packages.json），实际 ZIP 包仍从你排第一的镜像拉
type 字段选错，包根本不会被发现
type 决定 Composer 怎么解析这个源，不是填 composer 就万事大吉。
-
"type": "composer"：适用于完整索引服务（如阿里云镜像、Satis、Private Packagist），支持版本列表缓存和自动匹配 -
"type": "vcs"：只对应单个 Git/SVN 仓库，Composer 每次都远程探测 tag，不参与repositories顺序匹配逻辑 -
"type": "package"：声明单个包的静态信息，不支持版本发现，require 时必须完全匹配 name + version - 混用
vcs和composer类型源，容易导致Package not found，因为它们的查找机制完全不同
全局 config 和项目级 repositories 不合并，后者完全覆盖前者
很多人以为全局配置（~/.composer/config.json）里的 repositories 会和项目里的合并，实际是彻底覆盖。
- 项目级
composer.json中定义了repositories，全局配置里的同字段直接失效 - 想让私有包优先、镜像兜底，必须把私有源放
repositories数组最前，镜像居中，{"packagist.org": true}放最后 - CI/CD 中建议删掉全局
repositories，全部收敛到项目级配置，避免环境不一致 - 改完记得清缓存：
composer clear-cache，否则旧元数据可能残留导致 404
最容易被忽略的是：镜像配置只影响元数据获取路径，不影响 composer.lock 里记录的 dist URL；如果 lock 文件里记的是 repo.packagist.org 的 hash，换镜像也拉不到包——得删 lock 重装或跑 composer update --lock。
