composer全局镜像需用composer config -g正确配置，否则仅项目生效；通过composer config -g repo.packagist查看，-g --list列出全部全局项；设阿里云/腾讯云镜像须带-g参数及完整json对象，后执行clear-cache；优先级为项目>全局>默认，ide或权限差异易致失效。
Composer 全局镜像不是“一键修改”就能生效的，核心在于 composer config 命令作用域是否正确——错用 --global 或漏掉它，配置就只在当前项目生效，根本不算“全局”。
怎么确认当前全局配置位置和内容
Composer 的全局配置文件是用户家目录下的 composer.json（路径类似 ~/.composer/config.json），但直接编辑它容易出错。更安全的方式是用命令查：
-
composer config -g repo.packagist—— 查看当前全局镜像设置，如果返回空或报错Key "repo.packagist" does not exist，说明没设过 -
composer config -g --list—— 列出所有全局配置项，重点看repo.packagist是否存在、值是否为镜像地址 - 注意：不加
-g就是查当前项目目录下的composer.json，90% 的人误以为改了全局，其实只改了本地
怎么真正设置成阿里云/腾讯云等国内镜像源
必须带 -g 参数写入全局配置，且值必须是完整对象（不是字符串）：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 阿里云镜像：
composer config -g repo.packagist '{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}' - 腾讯云镜像：
composer config -g repo.packagist '{"type": "composer", "url": "https://mirrors.cloud.tencent.com/composer/"}' - 注意单引号包裹整个 JSON 字符串，双引号保留在内部；Windows CMD 用户需改用双引号并转义内部双引号，比如：
composer config -g repo.packagist "{\"\type\": \"composer\", \"\url\": \"https://mirrors.aliyun.com/composer/\"}" - 设置后运行
composer clear-cache，否则旧缓存可能让require仍走原源
为什么有时改了还是走 packagist.org？
常见原因不是命令写错，而是环境或权限干扰：
- 当前 shell 是 root 或通过
sudo composer运行的，实际改的是 root 用户的全局配置，而你日常用普通用户执行composer install，读的是普通用户的配置 - 项目根目录下有
composer.json且里面定义了repositories，会**优先覆盖全局镜像**（Composer 的合并逻辑：项目 > 全局 > 默认） - 某些 IDE（如 PHPStorm）内置 Composer，会使用自带的配置或缓存，重启 IDE 才能生效
- 公司网络策略拦截了镜像域名（比如
mirrors.aliyun.com被防火墙重定向），此时curl -I https://mirrors.aliyun.com/composer/packages.json应该能通，不通就得换源或联系运维
想临时切回官方源或禁用镜像怎么办
不需要删文件，用命令反向操作最干净：
- 删掉全局镜像配置：
composer config -g --unset repo.packagist - 或者强制本次命令走官方源：
composer install --repository=https://packagist.org（仅本次生效） - 注意：
--repository只影响当前命令的包发现阶段，不会改锁文件或 vendor 内容逻辑；如果已安装过包，update才会重新解析来源
真正麻烦的不是设镜像，而是不同终端、不同用户、不同 IDE 各自维护一套配置；一旦发现行为不一致，第一反应不该是重装 Composer，而是分别跑一遍 composer config -g repo.packagist 和 which composer 看清到底谁在执行哪个配置。
