配置不生效的主因是键名错误、缺失type参数或url缺末尾斜杠；正确命令为composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，且需验证输出为json对象或纯url，再清缓存、删lock文件并重装。
composer config -g repo.packagist 为什么总不生效
它不报错，但composer install依然卡在 Downloading，根本没走国内镜像——不是网络慢，是配置压根没写进去。90% 的失败只因三处硬伤：
• 键名写成 repos.packagist（多一个 s 就静默忽略）
• 漏掉中间的 composer 类型参数：正确命令是 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，少掉 composer 这个词，Composer 就当没这回事
• URL 缺末尾斜杠：https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌（路径拼接错误导致 404 或 fallback）
验证唯一方式：composer config -g repo.packagist。输出必须是完整 JSON 对象（如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}）或纯 URL 字符串。空、null、或仍含 packagist.org，说明配置失败。
项目级配置比全局更可靠，尤其在 CI/CD 和宝塔中
全局配置写进 ~/.composer/config.json，但宝塔用 www 用户、GitHub Actions 用 runner、Docker 容器用 www-data，它们都读不到你本地 root 或个人账户下的配置。
进项目根目录后执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g）
这条命令会安全追加到 composer.json 的 repositories 字段，不覆盖已有私有源，且拉代码即生效。
注意：
• 若 composer.json 中 "repositories" 是空对象 {}，命令能自动转为数组并插入
• 若已是数组格式 []，命令会向末尾追加，但需确保格式合法，否则报错
• 别在 repositories 内部写 "packagist.org": false——这个字段应放在 composer.json 根层级，否则 ext-json 等基础扩展校验失败
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
换源后仍卡住？清缓存 + 删 lock 文件才是关键
镜像只加速下载，但旧缓存里存着 packagist.org 的元数据，Composer 会优先读缓存并尝试从旧地址校验——结果就是卡在 DNS 或 TLS 握手，根本没发请求到镜像站。
必须执行：
• composer clear-cache
• rm -rf vendor composer.lock
• 再跑 composer install --no-dev --no-scripts --no-autoloader --prefer-dist
其中：
• --no-dev 跳过 phpunit、phpstan 等大体积开发依赖
• --no-scripts 避免 post-autoload-dump 因权限失败中断
• --no-autoloader 延后生成 autoload，装完再单独跑 composer dump-autoload -o 更稳
CI/CD 中建议把这几项写成一行：composer clear-cache && rm -rf vendor composer.lock && composer install --no-dev --no-scripts --no-autoloader --prefer-dist
怎么确认镜像真在用？别信命令输出，要看实际请求
光看 composer config 成功没用，得亲眼看到请求发到了镜像域名。
加 -vvv 运行：composer install -vvv
盯紧输出里的关键词：
• 出现大量 GET https://mirrors.aliyun.com/composer/ → 镜像已生效
• 卡在 Resolving dependencies → 和镜像无关，可能是 PHP 内存不足、启用了 xdebug、composer.json 版本约束太宽（如 "*"）、或 config.platform.php 与实际 PHP 版本不匹配导致求解器爆炸
另外，CI 中别缓存 ~/.composer/ —— 不同项目的镜像配置可能互相干扰；只缓存 vendor/ 和 composer.lock 即可。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
