镜像生效需同时满足三项：config输出完整JSON、diagnose显示镜像地址、-vvv日志含mirrors.aliyun.com；任一缺失即静默回退官方源。
composer config -g repo.packagist 输出不是“已生效”，只是“你写了什么”
很多人执行完 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，再跑一遍 composer config -g repo.packagist 看到 JSON 就以为配好了。其实这只是显示你“存了什么”，不代表 Composer 正在用它——项目级 repositories 字段、错误的缓存、甚至拼写错误（比如 repos.packagist）都会让这个配置被完全忽略。
真正验证必须看三处输出，缺一不可
判断镜像是否真生效，只看日志里实际发出的 HTTP 请求地址。以下三个检查项必须全部满足：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
-
composer config -g repo.packagist输出是完整 JSON 对象，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}（不能是null、空字符串或报错） -
composer diagnose中 “Repo packagist.org:” 行显示的是你的镜像地址，而不是https://packagist.org或https://repo.packagist.org -
composer clear-cache && composer require monolog/monolog -vvv 2>&1 | grep "Downloading"的输出里，出现的是mirrors.aliyun.com/composer/packages.json这类路径，而非官方域名
为什么 composer config --global cache-dir 显示的值不等于真实缓存路径
composer config --global cache-dir 只返回配置文件里写的值，但真实路径由 composer diag 输出的 Cache directory: 行决定——它已经综合了环境变量 COMPOSER_HOME、COMPOSER_CACHE_DIR、配置文件和默认逻辑。常见干扰包括：
- 设了
COMPOSER_HOME但路径不存在或权限不对，Composer 会静默 fallback 到默认位置 - Linux/macOS 下用
sudo composer config -g，把缓存路径写进了/root/.composer/config.json，而普通用户运行时根本读不到 - Windows 用户改了
%COMPOSER_HOME%但没重启终端，shell 仍用旧值
项目级 repositories 覆盖全局配置时的合并陷阱
项目根目录下执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带 -g），结果取决于 composer.json 原来的 repositories 结构：
- 如果原先是对象形式：
"repositories": {"my-private": {...}}→ 新增"packagist"键，安全 merge - 如果原先是数组形式：
"repositories": [{"type": "..."}]→ 整个数组被覆盖，原有私有源丢失 - 如果写了
"repositories": {"packagist.org": false}且没补替代源 →Could not find package直接报错 - 删掉
repositories后不执行composer clear-cache→ 旧缓存仍可能触发对packagist.org的请求
composer clear-cache，然后用 -vvv 观察真实网络请求，别信任何中间状态。 
