镜像源不加速依赖解析，只加速元数据与包下载；resolving dependencies是本地sat求解器穷举版本组合的纯cpu计算，与网络无关，换任何镜像均无效，真正提速的是loading composer repositories和downloading xxx.zip两个网络环节。
镜像源不加速依赖解析，只加速元数据与包下载
Composer中文镜像对 Resolving dependencies 阶段完全没提速——这个阶段是本地 PHP 进行的纯逻辑计算，和网络无关。你看到卡在“Resolving dependencies”几十秒，换阿里云、清华或华为镜像都无效。真正被加速的是两个环节：Loading composer repositories（拉取 packagist 元数据）和 Downloading xxx.zip（下载 dist 包）。前者耗时取决于镜像同步延迟与 HTTPS 响应速度，后者取决于 CDN 带宽与并发能力。
为什么 composer update 还是慢？检查这三处本地配置
依赖树深度遍历慢，90% 是项目自身约束导致，不是镜像问题：
-
"php": "*"或"^7.4 || ^8.0 || ^8.1"这类宽泛版本约束，会让 Composer 尝试数百种组合路径 -
require-dev里塞了大量未锁定的工具包（如"phpunit/phpunit": "dev-main"），每换一个 dev 分支都要重新校验整个依赖图 - 启用了
xdebug或opcache.enable=0，直接拖垮 PHP 解析性能；memory_limit低于 2G 时，Composer 2.9.6 在大型项目中会频繁 GC，响应变钝
parallel-downloads 能否提升依赖安装整体耗时？
能，但仅限 composer install（不含 lock 文件变更时）。它控制 ZIP 包并行解压下载线程数，设为 8 或 10 后，下载阶段可提速 3–5 倍。但注意：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 该参数在 Composer 2.2+ 才生效；运行
composer --version确认不是 2.1.x 或更旧版本 - 必须搭配镜像生效才起作用：如果
composer config -g repo.packagist输出仍是https://packagist.org，parallel-downloads就是空转 - 并发过高（如设为 20）易触发
file_put_contents(/tmp/): failed to open stream，临时文件竞争失败后会自动降级为串行
验证镜像是否真生效，别信命令输出
执行 composer config -g repo.packagist 后，输出必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果返回空、null、报错，或仍是 https://packagist.org，说明配置静默失败。常见错误有三个：
- 把
repo.packagist写成repos.packagist（多一个 s） - 漏掉中间的
composer类型参数：正确是composer config -g repo.packagist composer https://... - URL 缺尾部斜杠：
https://mirrors.aliyun.com/composer❌ → 必须是https://mirrors.aliyun.com/composer/✅
最可靠验证方式是加 -vvv 运行一次 composer install -vvv，盯紧日志里出现的 URL：只要看到大量 GET https://mirrors.aliyun.com/composer/packages.json 和 Downloading xxx.zip from https://mirrors.aliyun.com/composer/，就说明镜像和并发设置全到位了。
