Composer卡在Resolving dependencies是本地SAT求解器穷举版本组合所致，非网络问题；宽泛约束、dev分支、require-dev冲突及镜像配置失效（如项目级repositories屏蔽全局设置）是主因。
Composer 卡在 Updating dependencies 或 Resolving dependencies 阶段，和镜像源无关——换再快的镜像也解决不了，它压根还没开始下载。
为什么 composer update 一直卡在 Resolving dependencies？
这个阶段是 Composer 在本地解析依赖图、尝试满足所有 require 和 require-dev 的版本约束，全程不发任何网络请求。镜像只影响后续的 Downloading，对解析无任何加速作用。
- 常见诱因：
"php": "^7.4 || ^8.0"这类宽泛约束会让解析器穷举大量组合；dev-main、dev-develop等未锁定的开发分支也会显著拖慢速度 - 项目含大量
require-dev工具（如phpunit、phpstan、larastan），且彼此版本约束冲突时，解析可能卡住几十秒甚至数分钟 - Composer 2.2+ 启用了更严格的回溯算法，遇到矛盾约束时不会“随便选一个”，而是持续尝试直到超时或找到解
composer config -g repo.packagist 没生效的三个真实原因
命令敲对了，但依然走 packagist.org，大概率是以下情况之一：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 项目根目录
composer.json里存在"repositories"字段（哪怕只是空对象{}或{"packagist.org": false}），会直接屏蔽全局配置 - Windows 下用 Git Bash，
COMPOSER_HOME未生效，实际读取的是%APPDATA%\Composer\config.json，而你改的是~/.composer/config.json - 执行完配置后没运行
composer clear-cache，旧的packages.json元数据仍缓存在本地，解析时仍按旧源地址发起请求
项目级配置比全局更可靠，但写法必须精准
进项目根目录后执行命令，它会自动合并进 composer.json 的 "repositories" 字段，但有硬性要求：
- 命令必须去掉
-g：运行composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - key 必须是
"packagist"（不能是"aliyun"或"packagist.org"），否则 Composer 不识别 - 如果项目已有
"repositories"，且它是数组（如[{"type":"composer","url":"..."}]），该命令会报错；必须先确保它是对象（{}）才能安全追加
验证镜像是否真在用，只看三处输出
别信命令回显，要确认三点一致：
- 运行
composer config -g repo.packagist.url，输出应为https://mirrors.aliyun.com/composer/ - 运行
composer diagnose，找到Repo packagist.org:行，后面域名必须匹配你的镜像 - 加
-vvv跑一次composer show -p | head -3，第一行显示的源 URL 应含mirrors.aliyun.com或对应镜像域名
真正容易被忽略的是：项目级 repositories 字段一旦存在，全局配置就彻底失效，且没有任何警告。排查时第一反应不该是重装 Composer 或换网络，而是打开项目下的 composer.json，搜 "repositories" —— 它往往就静静躺在那里，挡住了所有优化。
