composer config -g repo.packagist 必须严格满足三条件才生效：键名必须为单数小写 repo.packagist，第二个参数必须显式写 composer（type 值），URL 必须 HTTPS 且末尾带 /；任一不符即静默回退官方源，验证需输出完整 JSON 对象如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
必须用 composer config -g repo.packagist 写入，其他写法全无效。 Composer 2.0+ 对键名、type 和 URL 格式有硬性校验，错一个就静默回退到 packagist.org，连 warning 都不报。
为什么 composer config -g repo.packagist 总是不生效
不是权限或网络问题，是命令本身有三处不可妥协的细节：
-
repo.packagist必须是单数、全小写 —— 写成repos.packagist、repositories.packagist或mirror都会被忽略 - 中间必须显式带
composer这个 type 值：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，漏掉composer就 fallback - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（会拼出/composerpackages.json，404）
验证是否真写入：运行 composer config -g repo.packagist，输出应为完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null 或仍含 packagist.org，说明没生效。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
全局配置在 CI/CD 或宝塔里常失效的原因
全局配置写在 ~/.composer/config.json，但很多环境不是用你的用户执行的：
- 宝塔面板默认用
www用户跑命令，而composer config -g默认写的是root的配置，www根本读不到 - CI 容器里可能以
runner或app用户启动，root下写的配置不生效 - 解决办法：切到对应用户下执行，例如
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
换源后仍卡在 Downloading？别忘了清缓存
镜像配置改了，但旧的 packages.json 和元数据还躺在缓存里，Composer 会优先读缓存，然后试图从旧地址拉校验信息 —— 结果卡在 DNS 或 TLS 握手。
- 必须执行
composer clear-cache，加-v看它实际删了什么 - 项目级
composer.json中若定义了repositories字段，会直接覆盖全局配置；用composer config --list --global和composer config --list对比确认实际生效的是哪个 - 临时验证是否走镜像：加
-vvv运行composer install，看日志里下载域名是不是mirrors.aliyun.com这类镜像地址
最易被跳过的点：换源只加速 dist 包下载，不解决 Resolving dependencies 阶段的卡顿。那个阶段完全不走网络，但对 PHP 内存、xdebug、config.platform.php 匹配度极度敏感 —— 镜像再快，这一步卡住也白搭。
