在新环境中快速导入Composer镜像配置-composer-PHP中文网

命令不生效是因为键名错（应为repo.packagist）、漏type值composer、url末尾缺/，三者缺一即静默回退官方源；验证需输出完整json，且须清缓存、删vendor与composer.lock后重装。

在新环境中快速导入composer镜像配置

composer config -g repo.packagist 命令为什么总不生效

它不是“有时慢”，而是根本没走镜像——90% 的失败源于三个硬性条件缺一：键名必须是 repo.packagist（不能是 repos.packagist 或 packagist.org），第二个参数必须显式写 composer（这是 type 值，不是注释），URL 必须是 HTTPS 且末尾带 /（https://mirrors.aliyun.com/composer/ ✅，少斜杠就 404）。

验证是否真写进去了，只看这一行输出：
composer config -g repo.packagist
正确结果只能是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果为空、null、或还是 https://packagist.org，说明命令压根没成功，立刻重试。

宝塔/Docker/GitHub Actions 里配镜像，别碰 -g

这些环境里执行 composer install 的用户，往往不是你当前终端登录的用户：

宝塔默认用 www 用户跑命令，root 下配的 -g 配置它根本读不到
Docker 构建时基础镜像（如 php:8.2-cli）常未初始化 ~/.composer 目录，composer config -g 会静默失败
GitHub Actions 的 php-actions/composer 动作默认忽略全局配置，只认项目根目录下的 composer.json

更可靠的做法是直接在项目根目录运行（不加 -g）：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
它会自动往 composer.json 的 repositories 字段追加条目，不破坏私有源结构，且所有环境都认这个。

改完镜像后，vendor 和 lock 文件必须删干净

旧 composer.lock 里记录的是包的 dist URL 和 hash，很可能还指向 packagist.org；vendor/ 里的 autoload 和元数据也残留旧源逻辑。不清理，composer update 甚至 install 都可能 fallback 回官方源或报 hash mismatch。

必须按顺序执行：

Workflow Decomposer

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

下载

composer clear-cache
rm -rf vendor/ composer.lock
composer install（注意：不是 update）

跑完后用 composer install -vvv 2>&1 | grep "GET\|Downloading" 看实际请求域名，确认是 mirrors.aliyun.com 而不是只信 config -g 输出。

新项目初始化前就要配镜像，否则卡死在 Loading

composer init 第一步就要拉取 packagist 元数据，没镜像就直连国外源——不是网慢，是它卡在 Loading composer repositories 并最终超时失败。

正确流程是：

先确保 PHP CLI 环境可用（尤其宝塔要检查是否禁用了 proc_open、putenv）
再执行镜像配置（推荐项目级：composer config repo.packagist composer https://mirrors.aliyun.com/composer/）
最后跑 composer init

如果已初始化但没配镜像，别硬撑——删掉刚生成的 composer.json，配好镜像再重来。否则后续 require 仍大概率失败，因为交互式选版本时元数据加载就失败了。