composer config -g不可靠因它仅写入用户级配置，而PHP运行用户（如www-data）无法读取；全局生效需用/etc/composer/config.json，且须满足目录权限、路径、repositories键名及URL格式四条件。
为什么 composer config -g 在团队里根本不可靠
因为 composer config -g 写的是当前用户的 ~/.composer/config.json，而团队里 PHP 实际运行用户（如 www-data、nginx、CI runner）根本读不到 root 或开发者个人的配置。你本地配好了，服务器上照样卡在 Loading composer repositories。
/etc/composer/config.json 是唯一真正全局生效的路径
Composer 2.2+ 会优先加载 /etc/composer/config.json，它不依赖用户 HOME，所有用户（包括 www-data）都认这个文件。但必须满足四个硬性条件：
-
/etc/composer/目录存在，权限为755，属主root:root - 配置文件路径必须是
/etc/composer/config.json（不能是/etc/composer.json或其他） -
"repositories"必须是对象（不是数组），键名严格为"packagist.org" -
"url"值必须是 HTTPS 且末尾带/，例如："https://mirrors.aliyun.com/composer/"
正确示例：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
{
"config": {},
"repositories": {
"packagist.org": {
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/"
}
}
}
Ansible 或脚本分发时最容易踩的坑
别用 sudo -u www-data composer config -g ——www-data 通常没 shell，命令直接退出；也别指望 chown -R www-data ~/.composer，因为该目录在多数生产环境根本不存在。
- 分发前先创建目录：
mkdir -p /etc/composer && chmod 755 /etc/composer - 用
copy模块写入配置文件，设权限0644，属主root:root - 验证必须切换到真实运行用户：
sudo -u www-data composer config repo.packagist，输出应为镜像 URL 对象 - CI 流水线中，如果用的是 Docker，需把该文件 COPY 进基础镜像，而不是在构建阶段执行
composer config
项目级配置才是跨环境最稳的兜底方案
即使系统级配置下发失败，只要 composer.json 里有正确的 repositories，就能强制走镜像。但注意写法：
-
"repositories"必须是顶层字段，且值为对象（不是数组） - 键名必须是
"packagist"（不是"packagist.org"或"aliyun"） - 内容格式：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 已有私有源？用
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g）追加，不会覆盖
真正的麻烦往往不在配置本身，而在验证环节——很多人改完就跑 composer install，却没用实际运行用户去确认 composer config repo.packagist 输出是否匹配，也没抓一次 curl -v 看请求头真发到了哪个域名。这两步跳过，等于没配。
