镜像对依赖解析完全无效，因“Resolving dependencies”是本地SAT求解器穷举版本组合的过程，不发网络请求；卡顿主因是宽泛PHP约束、dev分支启用、私有源超时或元数据延迟，非网络问题。
Composer中文镜像对依赖解析阶段（Resolving dependencies）完全无效，换源不会让卡顿变快，反而可能因元数据延迟导致解析更慢。
为什么“换了镜像还卡在 Resolving dependencies”
这个阶段根本没发网络请求——它是本地 SAT 求解器在穷举满足所有约束的版本组合。镜像只加速 Downloading packages，不参与解析逻辑。
- 常见诱因包括：
"php": "^7.4 || ^8.0 || ^8.1 || ^8.2"这类宽泛约束，让求解器尝试数百种 PHP + 包版本组合 -
"minimum-stability": "dev"强制拉取dev-main分支，候选版本数量指数级膨胀 - 私有源配置错误（如已下线的
repositories），Composer 会逐个 timeout 后才 fallback，拖长整体耗时 - 阿里云/腾讯云镜像的
packages.json元数据更新存在数小时延迟，Resolver 拿到过期信息后可能选错路径再回溯
如何验证镜像是否真生效
别信配置文件写对了就行，必须实测：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer config -g repo.packagist，输出必须是扁平 URL（如https://mirrors.aliyun.com/composer/），不能是嵌套结构或带s的repos.packagist - 执行
composer install -vvv，日志末尾必须出现镜像域名（如aliyun或tencent），否则配置未加载 - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致静默失效）
真正能提速依赖解析的 5 个动作
把时间花在刀刃上，而不是反复换源：
- 升级到
Composer 2.9.6：它优化了 SAT 求解算法，在大型项目中显著减少回溯轮次 - 收紧
php约束：把"php": "^8.1 || ^8.2"改成"php": "^8.1"，避免跨大版本兼容性试探 - 删掉
"minimum-stability": "dev"，改用"prefer-stable": true - 临时禁用 Xdebug：
php -d zend_extension= -d xdebug.mode=off composer install（Xdebug 会让求解器慢 3–5 倍） - 清理缓存：
composer clear-cache，损坏的 vendor hash 可能干扰解析路径选择
可视化依赖图比看日志更早发现问题
当 composer install -vvv 日志滚动上百行仍无进展，说明求解器已在深陷回溯——此时靠读日志效率极低。应立刻切到图：
- 装
kylekatarnls/composer-dependency-graph：composer require --dev kylekatarnls/composer-dependency-graph - 生成交互式 HTML：
./vendor/bin/composer-dependency-graph，打开graph.html可拖拽、悬停查版本、点开收起子树 - 图中若出现双向箭头闭环（A ↔ B），就是实锤循环依赖，得立刻检查
composer.json中哪两个包互相require - 注意：图基于
composer.lock快照，改完composer.json后必须先composer update，否则新依赖不会出现在图里
复杂依赖树下，镜像只是下载加速器，不是解析加速器；真正卡点永远在约束表达、环境一致性与 autoload 隐式耦合上——这些地方出问题，换十次源也没用。
