composer config -g repo.packagist 常批量失效，因SSH环境未加载shell配置致composer不可用、目标机缺Composer或版本低于2.2、用户权限错配（如配到ubuntu而非www）、且命令返回0不等于配置成功，必须逐台验证输出并清缓存。
不能靠单条命令批量推送到多台机器，必须组合 SSH、脚本分发和环境校验——否则大概率在某台机器上静默失败，你还以为全好了。
为什么直接用 composer config -g 在远程机器上执行常失效
很多人写个 for 循环 + ssh user@host 'composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/'，结果一半机器没生效。原因很实在：
-
composer config -g写入的是当前用户的~/.composer/config.json，但 SSH 登录时 shell 类型（如/bin/sh）可能不加载~/.bashrc或~/.profile，导致composer命令根本找不到或走错 PHP 版本 - 目标机器可能没装 Composer，或装的是旧版（
repo.packagist在 2.2+ 才支持，1.x 会忽略） - 用户权限不对：CI 节点常用
www或runner用户运行，但你 SSH 进去用的是ubuntu，配置写到了错的家目录 - 没验证输出：命令返回 0 不代表写进去了，
composer config -g repo.packagist返回空或null就是失败，但脚本里没检查
安全可靠的批量推送脚本结构
核心思路：把验证、安装、配置、清理打包成一个幂等脚本，用 scp 推送后 ssh 执行，每步都带 || exit 1 和显式检查。
- 先检查
composer是否可用且版本 ≥ 2.2：composer --version | grep -q "2\.[2-9]"，不满足则自动安装或退出 - 确认当前用户是预期用户（比如
id -un必须等于www），避免配到 root 或其他账户 - 执行配置前先备份原配置：
cp ~/.composer/config.json ~/.composer/config.json.bak.$(date +%s) - 用
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/配置，然后立刻验证：composer config -g repo.packagist | grep -q "mirrors.aliyun" - 强制清缓存：
composer clear-cache，不然旧元数据还在干扰
示例关键片段（保存为 setup-composer.sh）：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
#!/bin/bash
set -e
[[ $(composer --version | grep -o "2\.[2-9]\+\.[0-9]\+") ]] || { echo "Composer 2.2+ required"; exit 1; }
[[ $(id -un) == "www" ]] || { echo "Must run as www user"; exit 1; }
cp ~/.composer/config.json{,.bak.$(date +%s)} 2>/dev/null || true
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
composer config -g repo.packagist | grep -q "mirrors.aliyun" || { echo "Config failed"; exit 1; }
composer clear-cache
Windows 机器怎么处理（尤其 CI Agent 是 Windows Server）
PowerShell 原生 JSON 解析不可靠，别硬刚 ConvertFrom-Json 改 config.json。稳妥做法是调用 PHP 脚本，复用 Composer 自身逻辑：
- 写一个
set-mirror.php，用Composer\IO\NullIO和Composer\Config加载并写入全局配置 - 确保目标机已安装 PHP CLI（
php -v可用），且路径加入系统变量 - 用 PowerShell 执行：
php set-mirror.php https://mirrors.aliyun.com/composer/ - 重点：PHP 脚本里必须显式指定用户家目录（
$_SERVER['HOME']在 Windows 上常为空），改用getenv('USERPROFILE')
这样比纯 PowerShell 处理 JSON 稳定得多，也绕开了 Windows 下 ~/.composer 路径解析混乱的问题。
最容易被忽略的三个收尾动作
批量配完不是就结束了，漏掉任意一个，过两天就会有人来问“为什么又变慢了”：
-
vendor/和composer.lock不会自动更新——它们记录的是旧源地址，必须让各项目主动执行一次composer update --lock（或删掉再install）才能真正走新镜像 - CI/CD 流水线里如果用了 Docker 缓存（比如
composer install步骤被缓存），镜像配置再对也没用；得加composer clear-cache到每个 job 开头 - 某些机器上
~/.composer目录权限是700，但 CI Agent 以不同用户启动，导致读不到配置；检查ls -ld ~/.composer，必要时chmod 755 ~/.composer
