composer中文镜像不改变版本解析逻辑，install卡在“resolving dependencies”与镜像无关，本质是本地cpu穷举版本组合：宽泛约束（如"^7.4 || ^8.0"）、dev分支引用、require-dev工具冲突等导致求解器指数级爆炸，需收紧约束、删非必要dev依赖、优先使用composer install而非update。
Composer中文镜像本身不改变版本解析逻辑，composer install 卡在 Resolving dependencies 阶段，99% 和镜像无关，而是 composer.json 里版本约束写法或 PHP 环境配置导致的。
为什么换完阿里云镜像 still stuck at “Resolving dependencies”
镜像只加速包下载（Downloading），不参与依赖图计算。卡在这一步，说明 Composer 正在本地穷举满足条件的版本组合——和网络、镜像完全无关。
-
"php": "^7.4 || ^8.0"这类宽泛约束会让 Composer 尝试数百种 PHP + 包版本组合，尤其当 lock 文件缺失时 -
"monolog/monolog": "dev-main"或"^2.0@dev"这类 dev 分支引用，会强制刷新所有 provider 元数据，触发全量索引拉取（哪怕你用了镜像） -
require-dev里同时存在phpunit/phpunit、phpstan/phpstan、psalm/phar，三者对 PHP 版本、symfony 组件、doctrine 的约束常互相冲突，放大求解难度
composer.json 中 version 字段对依赖解析的实际影响
version 字段在 composer.json 里仅用于当前包自身标识，**不影响任何依赖解析行为**。它既不会被当作约束条件参与求解，也不会限制别人 require 你时的版本匹配逻辑。
- 如果你看到某包解析失败，错误信息里出现
myvendor/mypackage v1.2.3 requires php ^8.1，那个v1.2.3来自该包composer.json的version，但约束力来自它的require.php - 手动改自己项目的
version不会加快或减慢composer update，除非你把它写进require里（比如"myself": "self.version"，极少用） - 真正起约束作用的是
require和require-dev下每个包的版本字符串，比如"laravel/framework": "^10.0"
如何快速定位并缓解依赖解析慢
不用重装镜像、不用清缓存，先做三件事：
- 加
--profile参数跑一次：composer update --profile，看耗时最长的环节是resolving还是downloading—— 前者才需要改composer.json - 临时删掉
require-dev里非必要工具，只留phpunit/phpunit，再composer update，如果快了，说明是 dev 工具链冲突 - 把宽泛约束收紧：把
"php": "^7.4 || ^8.0"改成明确版本如"php": "^8.2"，把"symfony/console": "*"改成"^6.4" - 已有
composer.lock？直接composer install，它跳过解析，只下载；没 lock 才必须update解析
镜像源配得再准，也救不了一个写满 dev-master 和 * 的 composer.json。解析慢的本质是组合爆炸，不是网络延迟。
