全局配置写在~/.composer/config.json（Linux/macOS）或%USERPROFILE%\AppData\Roaming\Composer\config.json（Windows），且仅该路径生效；执行composer config -g即直接修改此文件，但需注意用户权限、键名repo.packagist、type值composer及URL末尾斜杠缺一不可。
全局配置写在哪？~/.composer/config.json 是唯一落点
Composer 的全局配置只存在一个地方：~/.composer/config.json（Linux/macOS）或 %USERPROFILE%\AppData\Roaming\Composer\config.json（Windows）。它不读取项目目录、PHP 配置、环境变量或任何其他路径下的同名文件。你执行 composer config -g，就是直接改这个文件。
常见错误是：你在终端用 sudo 运行了 composer config -g，结果配置写进了 /root/.composer/config.json；但你的 Web 服务（如 Nginx + PHP-FPM）或宝塔后台是以 www 用户运行的，它根本不会去读 /root/ 下的配置——所以「明明配了，却没生效」。
- 确认当前命令执行用户：
whoami，再检查对应家目录下的.composer/config.json -
composer config -g repo.packagist输出为空？说明该用户的配置文件里没写对字段，不是「没配」，是「配错了位置」 - CI 环境中（如 GitHub Actions、GitLab CI），务必确保
composer config -g和后续composer install在同一个用户上下文里执行
repo.packagist 不是 repos.packagist，拼错就静默失效
这是最常踩的坑：多一个 s，少一个 composer 类型声明，或者 URL 少了末尾斜杠，命令都成功返回，但配置完全无效。
正确写法只有这一种：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。其中：
-
repo.packagist是固定键名，不能是repos.packagist、packagist.org或mirror -
composer是 type 值，必须显式写出，不能省略 - URL 必须以
https://开头，且结尾带/，否则部分 Composer 版本会拼接出错（比如变成https://mirrors.aliyun.com/composer/packages.json→ 404）
验证是否写入成功，只看这一条命令：composer config -g repo.packagist。输出必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。其他任何输出（空、null、报错）都代表没生效。
项目级配置优先级高于全局，但必须删 vendor 和 composer.lock 才能生效
你在 composer.json 里加了 "repositories": {"packagist": {...}}，但 composer install 还是从 packagist.org 拉包？大概率是因为旧的 composer.lock 文件里记录的是官方源的包哈希和下载地址，Composer 直接复用，根本不查新配置。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
项目级换源后，必须做两件事：
- 删除当前目录下的
vendor/和composer.lock - 执行
composer install（不是update），让 Composer 重新解析依赖树并生成适配镜像的新 lock 文件
注意：composer update 会保留旧 lock 中的版本约束，可能仍尝试从旧源解析元数据；而 install 强制依据当前 composer.json + 当前配置重走全流程。
镜像只加速「元数据加载」和「ZIP 下载」，不解决 Resolving dependencies 卡顿
如果你执行 composer install 卡在 Loading composer repositories，换镜像是对症的；但卡在 Resolving dependencies 几十秒甚至几分钟，和镜像完全无关。
这个阶段是 Composer 在本地做依赖图计算，耗时取决于：
-
composer.json中约束太宽（比如"^7.0"或"dev-master"） - 项目依赖树过深、冲突太多，导致回溯搜索爆炸
- PHP 内存限制太低（
memory_limit小于 1.5G 容易 OOM） - Composer 版本过旧（
composer self-update到 2.9.6+ 可明显改善）
这时候换镜像、清缓存、重启终端都没用。真正要做的，是收紧版本约束、升级 Composer、或用 composer why-not xxx 定位冲突源头。
