一键配置Composer镜像源的Shell脚本-composer-PHP中文网

composer config -g repo.packagist 不生效的根本原因是：键名必须为单数 repo.packagist、type 值必须显式写 composer、url 必须 https 且末尾带 /，三者缺一即静默回退官方源；验证需输出完整 json 对象如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。

一键配置composer镜像源的shell脚本

为什么 `composer config -g repo.packagist` 设置后不生效

常见现象是执行了 composer config -g repo.packagist https://mirrors.aliyun.com/composer/，但后续 composer create-project 或 require 仍走官方源，甚至报超时错误。根本原因在于：Composer 从 2.0 开始默认启用了「packagist.org 的镜像自动发现机制」，它会忽略用户手动配置的 repo.packagist，转而优先使用 https://packagist.org 自身返回的镜像列表（比如腾讯、华为等 CDN 地址），而这些地址在国内不一定稳定或可用。

真正起效的方式是禁用自动镜像，并显式指定镜像源为「完整镜像」——即把 packagist.org 的全量数据同步站作为替代源。实操建议如下：

先运行 composer config -g --unset repos.packagist 清理旧配置（避免残留干扰）
再执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ —— 注意末尾的 composer 类型标识，这是关键，表示启用「完整镜像协议」，而非仅替换域名
验证是否生效：运行 composer config -g repo.packagist，输出应为 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，而不是纯字符串

Shell 脚本里如何安全判断并切换镜像源

一键脚本不能无脑覆盖，得识别当前环境是否已配置、是否指向有效镜像、是否需要回退。核心逻辑是解析 composer config -g repo.packagist --json 的 JSON 输出，而不是依赖文本匹配。

示例关键片段（Bash）：

current=$(composer config -g repo.packagist --json 2>/dev/null | jq -r '.url // ""')
if [[ "$current" == "https://mirrors.aliyun.com/composer/" ]]; then
  echo "已配置阿里云镜像，跳过"
elif [[ "$current" == "https://packagist.phpcomposer.com" ]]; then
  echo "检测到已弃用的 phpcomposer 镜像，强制更新"
  composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
else
  composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
fi

注意点：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

必须用 --json 获取结构化输出，避免解析 composer config -g 全局列表时受其他配置干扰
jq 是硬依赖，脚本开头应检查 command -v jq，缺失则提示安装或降级为简单字符串匹配（但精度下降）
旧镜像如 https://packagist.phpcomposer.com 已下线，脚本中需显式识别并迁移，否则 composer update 会卡死在 DNS 或 404

全局配置 vs 当前项目配置：什么时候该用 `-g`，什么时候不该

绝大多数人想“一键加速所有项目”，所以默认用 -g（global）是对的。但有两类场景必须避开全局配置：

CI/CD 环境（如 GitHub Actions、GitLab CI）：不同项目可能依赖不同镜像策略，或需复现生产环境行为，此时应在项目根目录运行 composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（不带 -g），并提交 composer.json 中的 repositories 字段
团队协作项目：若团队约定使用私有 Packagist（如 Satis 或 Private Packagist），全局镜像会覆盖私有源，导致包拉取失败；这时应只在项目内配置，且明确禁用 packagist.org："packagist.org": false

脚本可加参数支持模式切换，例如：./set-mirror.sh --local 表示仅当前目录生效，内部调用的是无 -g 的命令。

镜像源选哪个？阿里云、清华、腾讯的实际差异

不是所有镜像都一样快。实测（2024 年国内主流网络环境）：

https://mirrors.aliyun.com/composer/：DNS 解析稳定，大包下载（如 Laravel 完整骨架）首字节延迟低，适合大多数场景
https://mirrors.tuna.tsinghua.edu.cn/composer/：教育网和北方联通用户更快，但偶尔出现元数据同步延迟（composer show 列不出新版包）
https://mirrors.cloud.tencent.com/composer/：南方电信用户表现好，但 HTTPS 证书偶发校验失败（需 composer config -g disable-tls false 配合，不推荐）

脚本里不应写死单一源，而应提供选项或按地理位置探测（如用 curl -s https://myip.ipip.net 粗略判断），但更务实的做法是：默认阿里云，加注释说明如何快速切换——毕竟镜像失效时，手动改一行 URL 比重跑脚本更直接。

最后提醒一句：Composer 镜像只是加速手段，不是万能解药。如果项目里用了大量 vcs 类型仓库或自定义 dist 地址，那些请求仍然走原始 Git 或 HTTP，镜像源对此完全无效。