Composer镜像配置失效主因是键名错（必须repo.packagist单数）、漏type值composer、URL末尾缺/，三者任一出错即静默回退官方源；验证需看config -g输出是否为完整JSON、diagnose域名匹配、-vvv日志请求URL正确。
配错一个字符，Composer 就会静默 fallback 到 packagist.org，不是慢，是根本没走镜像——国内 PHP 项目不配镜像，composer install 基本不可用。
为什么 composer config -g repo.packagist 总是不生效
这条命令不是“设个 URL”就行，它必须同时满足三个硬性条件，缺一即失效：
-
repo.packagist键名不能多写s（repos.packagist是 Composer 1.x 旧写法，2.x+ 完全忽略且不报错） - 第二参数必须显式写
composer，这是仓库类型声明，漏了就当没配 - URL 必须以
https://开头，且结尾带/（https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌ —— 少斜杠会导致路径拼接错误，返回 404）
验证是否真写入：运行 composer config -g repo.packagist，输出应为完整 JSON：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}。如果为空、null 或仍是 packagist.org，说明根本没生效。
宝塔、CI、Docker 里镜像配置失效的真相
这些环境默认以非登录用户运行（如 www、runner、www-data），而 composer config -g 只写当前 shell 用户（比如 root）的配置。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
立即学习“PHP免费学习笔记（深入）”；
- 确认实际运行用户：宝塔查 PHP 进程属主，CI 看
runner用户，Dockerfile 中基础镜像通常无全局配置目录，RUN composer config -g会静默失败 - 用对应用户重配：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本中别依赖全局配置，改用临时参数更可靠：
COMPOSER_MEMORY_LIMIT=-1 php -d xdebug.mode=off $(which composer) install --no-dev --prefer-dist --no-autoloader --no-scripts - Docker 构建推荐项目级配置：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g），写进composer.json才真正随代码生效
项目级 repositories 配置覆盖全局的陷阱
执行 composer config repo.packagist（不加 -g）会向 composer.json 的 repositories 数组追加一条 "packagist" 记录，但行为很微妙：
- 如果
composer.json已有"repositories": []且不含"packagist"条目，该命令会补上 - 但如果已有
"packagist"条目（哪怕 URL 写错），命令不会覆盖，而是静默失败 - 一旦
repositories数组存在，它就会完全屏蔽全局repo.packagist配置 - 千万别手动写
"packagist.org": false，这会导致基础扩展（如ext-json）校验失败
换源后首次安装若报 hash does not match 或 package is not installed，直接删掉 vendor/ 和 composer.lock 再 install——旧 lock 文件记录的是原源哈希，和镜像元数据不兼容。
最易被忽略的点：镜像只加速下载，不解决 Resolving dependencies 卡顿；那个阶段耗的是 CPU 和内存，跟网络无关。配完镜像，还得看日志里下载域名是不是已变成 mirrors.aliyun.com，否则所有优化都是白忙。
