直接改配置文件可行但需严格遵循路径、权限和JSON结构；/etc/composer/config.json是唯一被所有用户读取的系统级配置，键名必须为"packagist.org"且URL末尾带/，验证须切换运行用户执行composer config repo.packagist。
直接改配置文件可行，但必须写对路径、权限和 JSON 结构，否则 Composer 完全不认。
为什么 composer config -g 在服务器上经常失效
因为 composer config -g 只写入当前用户的 ~/.composer/config.json，而 PHP 实际运行用户（比如 www-data、nginx 或 CI 中的 runner）根本读不到你的个人配置。你本地执行成功，上线后照样卡在 Loading composer repositories。
真正能被所有用户（包括无 shell 的服务账户）读取的唯一路径是：/etc/composer/config.json——Composer 2.2+ 会优先加载它。
-
/etc/composer/目录必须存在，权限为755，属主root:root - 文件路径必须严格是
/etc/composer/config.json（不能是/etc/composer.json或其他变体） -
"repositories"必须是对象，键名只能是"packagist.org"（不是"packagist"，也不是"aliyun"） -
"url"值必须是 HTTPS，且末尾带/，例如："https://mirrors.aliyun.com/composer/"
/etc/composer/config.json 的正确写法
这个文件不是随便填个 URL 就行，结构错一点就静默失效。最简可用模板如下：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
{
"config": {},
"repositories": {
"packagist.org": {
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/"
}
}
}
注意几个硬性点：
-
"repositories"是顶层字段，不是"config"的子项 - 键名
"packagist.org"是固定字符串，大小写、拼写、标点都不能改 - 不要加
{"packagist": false}这类禁用语句——新版 Composer 不支持这种写法，会报Repository has no URL defined - 如果用了 Ansible 或 shell 脚本分发，务必用
copy模块写入，设权限0644，属主root:root
验证是否真生效了
别只看命令有没有报错，要切换到真实运行用户去验证：
- 执行：
sudo -u www-data composer config repo.packagist - 预期输出应为完整 JSON 对象：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 如果返回空、
null或报错Could not open input file，说明路径、权限或结构有误 - CI 流水线中若用 Docker，必须把该文件
COPY进镜像，不能在构建阶段用composer config -g生成——因为构建时用户和运行时用户不同
项目级配置才是跨环境兜底方案
即使系统级配置失败，只要 composer.json 里有正确的 "repositories"，就能强制走镜像。但写法完全不同：
- 键名必须是
"packagist"（不是"packagist.org"） - 必须是顶层字段，值为对象（不是数组），例如：
"repositories": {"packagist": {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}} - 不能和全局配置混用——项目级优先级更高，但一旦提交进 Git，所有协作者都会强制走这个源
- 团队协作时，更推荐靠文档约定 + 全局配置，而不是把镜像 URL 硬编码进
composer.json
最麻烦的不是写错哪一行，而是改完没验证、没切用户测、没清理旧缓存——composer clear-cache 和 rm -rf vendor composer.lock 往往比重配还关键。
