直接配composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/可解决90%下载问题，但易静默失效：键名必须为单数repo.packagist、中间composer为必填type值、URL末尾必须带/；项目级repositories字段会完全覆盖全局配置；验证需执行composer config -g repo.packagist输出应为有效镜像地址。
直接配 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能解决 90% 的下载卡顿、超时、could not find package 问题——但这条命令极易静默失效，不是地址错了，而是三个细节没对齐。
为什么 composer config -g repo.packagist 总是“看起来生效，实际没用”
它不报错，也不提示失败，但 composer install 还是连 packagist.org。根本原因就三点：
-
repo.packagist键名必须一字不差：写成repos.packagist、repository.packagist或mirror全部无效 - 中间的
composer是 type 值，小写，不可省略——漏掉它，Composer 就当这行配置不存在 - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（部分 Composer 7.x 版本会 404）
验证是否真写进去了，别只信命令没报错，运行：composer config -g repo.packagist
输出应为完整 JSON 对象或至少是 URL 字符串；空、null、或仍是 https://packagist.org，说明根本没写成功。
项目里有 repositories 字段，全局镜像还管用吗
完全不管用。Composer 的仓库优先级是硬编码的：项目级 composer.json > 全局 ~/.composer/config.json > 默认源。只要项目根目录的 composer.json 里定义了 "repositories" 数组（哪怕只写了 []），全局配置就会被跳过。
立即学习“PHP免费学习笔记（深入）”；
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 想临时绕过项目配置验证镜像是否可用？加
--repository-url参数：composer update --repository-url=https://mirrors.aliyun.com/composer/ -
composer create-project不支持-r参数，CI 脚本中若要用镜像，必须先config -g再执行，不能靠临时参数 - 团队协作时，建议用项目级配置：进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/，它会自动追加到composer.json的repositories数组首位，不破坏已有私有源
composer config -g 报错或命令未找到，大概率是 PHP 环境拦住了
常见报错包括：proc_open(): fork failed、putenv() has been disabled、甚至直接 command not found（其实是 PHP CLI 模块加载失败）。这不是 Composer 的锅，是 PHP 配置在作祟：
- 检查
php.ini中的disable_functions，确保没禁用proc_open和putenv（多一个空格也会失效） - 改完
php.ini后必须重启 PHP-FPM / Apache / Nginx；CLI 模式下也要重开终端或执行hash -r - 验证函数是否可用：
php -r "echo proc_open('echo 1', [], $p) ? 'ok' : 'fail';"，输出ok才算过关
Windows 用户执行完还要关掉当前终端再重开，否则 shell 可能仍读取旧环境变量或缓存的配置。
换镜像后还是卡在 Resolving dependencies，和镜像无关
镜像只加速元数据拉取和 zip 包下载，不解决依赖解析阶段的卡顿。这个阶段慢，八成是以下原因：
- PHP 内存不足：默认 128M 不够，临时加
COMPOSER_MEMORY_LIMIT=-1再试 - Xdebug 启用中：会让解析慢 5–10 倍，用
php -d xdebug.mode=off $(which composer) install临时禁用 -
platform配置与实际 PHP 版本不匹配：比如"php": "7.4"却在 PHP 8.2 上运行，触发降级查找逻辑 - 项目
composer.json里写了太多dev-分支约束，强制 Composer 去遍历所有分支历史，极耗时
真正起效的验证方式不是看配置输出，而是抓包或看 composer diagnose 输出里的 Repo packagist.org: 后面是不是你设的镜像地址——不是，就说明被覆盖或没加载上。
