全局配置文件是~/.composer/config.json（Linux/macOS）或%USERPROFILE%\AppData\Roaming\Composer\config.json（Windows），项目级配置为当前目录下的composer.json；应优先使用composer config命令修改，避免手动编辑出错。
Composer配置文件在哪，改哪个文件？
全局配置写在 ~/.composer/config.json（Linux/macOS）或 %USERPROFILE%\AppData\Roaming\Composer\config.json（Windows），项目级配置是当前目录下的 composer.json。别直接改 composer.lock——它只记录最终解析结果，手动改会立刻被覆盖。
优先用 composer config 命令操作，避免手误格式错误。比如设国内镜像：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意：这个地址已失效，下文会说明替代方案）
国内镜像地址现在还能用吗？
很多老教程写的镜像已停用或重定向失败，典型错误是执行 composer install 时卡在 “Loading composer repositories with package information…” 或报错：Could not fetch https://packagist.phpcomposer.com/packages.json 或 SSL certificate problem: unable to get local issuer certificate。
目前稳定可用的主流镜像有：
- 阿里云：
https://mirrors.aliyun.com/composer/ - 腾讯云：
https://mirrors.cloud.tencent.com/composer/ - 华为云：
https://repo.huaweicloud.com/repository/php/
设阿里云镜像的正确命令：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/；如果只想对当前项目生效，去掉
-g 参数。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
为什么改了镜像还是走国外源？
常见原因不是配置没生效，而是 Composer 优先级规则导致的覆盖：
- 项目级
composer.json中的repositories字段会完全覆盖全局配置 - 如果项目里写了
"repositories": [{"type": "composer", "url": "https://packagist.org"}]，哪怕全局设了镜像也没用 -
composer diagnose能帮你确认实际生效的源：
输出中看到Repo packagist: https://mirrors.aliyun.com/composer/才算成功
临时绕过镜像调试：加 -vvv 参数看真实请求地址，比如 composer update -vvv | grep "GET "。
HTTPS证书或DNS污染导致请求失败怎么办？
某些企业网络或老旧系统会出现 SSL 验证失败或域名解析超时，不是镜像本身问题：
- 先试
curl -I https://mirrors.aliyun.com/composer/packages.json看是否能通 - 如果 curl 也失败，检查系统时间是否准确、是否开了代理、DNS 是否被污染（可换用
114.114.114.114） - 极端情况可临时禁用 SSL 验证（不推荐长期使用）：
composer config -g secure-http false
注意：禁用 secure-http 后，所有 HTTP 源都允许加载，存在安全风险，仅用于排查。
repositories 会静默覆盖全局设置，每次遇到慢或失败，先 composer diagnose 看真实配置，再查网络连通性，最后才动配置文件。 
