composer config -g repo.packagist 不生效的根本原因是：键名必须为单数 repo.packagist、type 值必须显式写 composer、URL 必须 HTTPS 且末尾带 /，三者缺一即静默回退官方源；验证需输出完整 JSON 对象如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
为什么 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
注意点：
工作流任务拆解与模型编排技能。使用场景：(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，镜像源对此完全无效。
