ssh批量执行composer config -g失败主因是默认非登录shell不加载环境配置，导致COMPOSER_HOME未设或PHP路径不可用；需加-l参数、显式指定COMPOSER_HOME，并验证输出为完整JSON。
全局配置在多服务器上基本无效，必须逐台、逐用户执行项目级或全局 config 命令，并确保目标用户身份与运行环境一致。
为什么 ssh 批量执行 composer config -g 总是失败
常见现象：用 ssh user@host "composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/" 一跑就报错或查不到配置。根本原因不是命令本身错，而是：
– ssh 默认启动非登录 shell，不加载 ~/.bashrc 或 ~/.profile，导致 COMPOSER_HOME 未设或 PHP 路径不可用
– 多数服务器上 composer 是全局二进制（如 /usr/local/bin/composer），但配置文件写入路径依赖当前用户的家目录，而 sudo -u www 或 su -c 不一定生效
– Windows 服务器（如通过 WSL 或 Git Bash）可能读取 %APPDATA%\Composer\config.json，而非 ~/.composer/config.json
实操建议：
– 改用登录式 shell：加 -l 参数，例如 ssh -l user@host 'composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/'
– 显式指定 COMPOSER_HOME：在命令前加 COMPOSER_HOME=/home/user/.composer
– 验证是否真写入：后续必须单独执行 ssh user@host 'composer config -g repo.packagist'，输出应为完整 JSON 对象，空或 null 即失败
– CI/CD 或宝塔类环境，优先改用环境变量方式，避免依赖用户级配置文件
批量注入项目级 repositories 字段的可靠方式
当服务器上有多个 PHP 项目（如 /var/www/*/composer.json），且需统一启用镜像源时，不能只靠全局配置——只要任一项目含 "repositories" 字段，全局设置即被跳过。
推荐用 jq 批量处理（Linux/macOS）：
– 先确认所有目标 composer.json 合法：用 jq empty {} 验证语法
– 注入逻辑必须包含三步：判断 repositories 是否存在 → 若无则新增含 {"packagist.org": false} 和镜像对象的数组 → 若有则仅替换已存在的 type: "composer" 条目，不破坏私有源
– 示例命令（安全覆盖）：
find /var/www -name "composer.json" -exec jq -S 'if has("repositories") == false then .repositories = [{"packagist.org": false}, {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}] else (.repositories |= map(if .type == "composer" and (.url | startswith("https://packagist.org") or .url == null) then {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} else . end)) end' {} \; -exec chmod 644 {} \;– 注意：
jq -S 会重排缩进，若团队要求空格而非 tab，需额外用 sed 统一
Windows 服务器或混合环境的兜底方案
PowerShell 原生 JSON 操作易出错（如中文路径、BOM、嵌套空格），直接调用 jq 又需额外安装。更稳的做法是复用 Composer 自身能力：
– 写一个 setup-mirror.php 脚本，放在各服务器公共路径（如 /opt/bin/）：
<?php<br>$json = json_decode(file_get_contents($argv[1]), true);<br>if (!isset($json['repositories'])) {<br> $json['repositories'] = [<br> ['packagist.org' => false],<br> ['type' => 'composer', 'url' => 'https://mirrors.aliyun.com/composer/']<br> ];<br>} else {<br> foreach ($json['repositories'] as &$repo) {<br> if (isset($repo['type']) && $repo['type'] === 'composer') {<br> $repo['url'] = 'https://mirrors.aliyun.com/composer/';<br> }<br> }<br>}<br>file_put_contents($argv[1], json_encode($json, JSON_UNESCAPED_SLASHES | JSON_PRETTY_PRINT) . "\n");– 在每台服务器上执行：
php /opt/bin/setup-mirror.php /var/www/myapp/composer.json– 优势：不依赖外部工具，PHP 版本兼容性好，能处理 BOM 和 Windows 换行符
验证和清理比配置本身更重要
改完不验证等于没改。尤其多服务器场景下，缓存、旧 lock 文件、CI 构建层残留会导致行为不一致。
必须同步执行的步骤：
– 清 Composer 缓存：composer clear-cache（注意：该命令对当前用户生效，若用 www 用户运行，就得 sudo -u www composer clear-cache）
– 删除旧锁文件和 vendor：rm -f composer.lock vendor/（否则 composer install 仍按 lock 中的 dist URL 下载）
– 验证真实请求地址：composer update -vvv 2>&1 | grep "GET https"，确认日志中出现的是 mirrors.aliyun.com，而非 packagist.org
– 检查 CI 环境变量是否覆盖了配置：如 GitHub Actions 中设置了 COMPOSER_REPO_PACKAGIST，它会优先于 config 文件
最容易被忽略的一点：不同服务器上的 PHP CLI 用户可能不同（root、www、deploy），而 composer config -g 只影响执行命令的那个用户。批量脚本里漏掉 sudo -u xxx 或用户切换，就会造成部分机器“看起来配好了，实际没生效”。
