composer config -g不同步因配置写入各用户独立家目录，CI/宝塔/Docker环境用户与权限各异；repositories失效主因是键名错误、格式不符、URL缺/或数组与对象混用；跨服务器应统一用项目级配置并提交composer.lock；系统级配置需严格满足/etc/composer/config.json路径、权限、键名及URL格式四条件。
为什么composer config -g在多台服务器上根本不同步
因为composer config -g写入的是当前用户的~/.composer/config.json，而每台服务器、每个用户（www-data、runner、root）的家目录完全独立。CI 容器没家目录，宝塔用www用户，Docker 构建用非登录用户——它们压根不读同一个文件。更隐蔽的是：你用sudo composer config -g配进了root的配置，但 PHP 进程以www-data运行，镜像就彻底失效。
composer.json里写repositories为什么有时不生效
Composer 2.2+ 对repositories字段格式极其敏感，常见失效原因包括：
- 键名写成
"packagist.org"或"aliyun"，正确必须是"packagist"（单数、小写、无.org后缀） - 值用了对象格式
{"type":"composer","url":"..."}，但没前置{"packagist.org": false}，导致元数据仍硬编码走官方源 -
url末尾缺/，请求变成/packages.json直接 404 - 原
repositories是数组（如[{"type":"vcs",...}]），而composer config repo.packagist命令只支持对象格式，会报错而非合并
跨服务器真正能落地的配置方式
项目级配置是唯一可版本化、可复现、不依赖人工敲命令的方案。操作要点如下：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 进项目根目录，执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 确认
composer.json中生成的repositories是顶层对象，不是嵌套在config下 - 若已有私有源，该命令会安全追加，但前提是原
repositories为对象；若是数组，需手动改为"repositories": {"packagist.org": false, "packagist": {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}} - 必须提交
composer.lock——旧 lock 文件里的dist.url可能仍是packagist.org，需运行composer update --lock强制刷新
/etc/composer/config.json配置的四个硬性条件
当需要让 Web 服务或 CI 用户（如www-data、runner）也统一生效时，只能靠系统级配置，但它必须同时满足：
-
/etc/composer/目录存在，权限755，属主root:root - 配置文件路径严格为
/etc/composer/config.json（不能是/etc/composer.json） -
repositories必须是对象，且键名严格为"packagist.org"（不是"packagist"） -
url值必须是 HTTPS 且末尾带/，例如"https://mirrors.aliyun.com/composer/"
验证方式：sudo -u www-data composer config repo.packagist输出应为镜像地址。漏掉任一条件，配置即静默失效，且无任何提示。
