Composer中文镜像不加速依赖解析（Resolving dependencies），因其为本地SAT求解、无网络请求；卡顿主因是memory_limit过低、xdebug启用或版本约束过宽，需收紧约束、清理vendor/和composer.lock、正确配置镜像。
Composer依赖解析（Resolving dependencies）卡住，不是镜像能解决的——它压根不走网络，纯本地CPU密集型计算。
为什么composer update总卡在“Resolving dependencies…”
这个阶段 Composer 在跑 SAT 求解器（源码在 src/Composer/DependencyResolver/Solver.php），暴力尝试所有满足约束的版本组合。它不发任何 HTTP 请求，所以换镜像、加缓存、改 DNS 都没用。
- 典型表现：
composer update -vvv日志停在该行超 10 秒，后续无Loading composer repositories或Downloading输出 - 真实瓶颈常是：
memory_limit过低（默认 128M 不够）、启用了xdebug、或composer.json里写了太宽的约束（如"*"、"^1.0 || ^2.0"） - 验证内存是否瓶颈：临时运行
COMPOSER_MEMORY_LIMIT=-1 composer update，若明显变快，就确认是内存不足
真正有效的解析提速操作
依赖解析无法“加速”，只能“规避”或“减负”。核心思路是减少求解器要处理的变量数量和约束复杂度：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 永远提交
composer.lock——composer install直接按 lock 安装，跳过整个解析过程 - 删掉没用的
require-dev包（比如把phpunit/phpunit改成全局安装，而非项目级依赖） - 收紧版本约束：把
"*"换成"^4.2"，把"^1.0 || ^2.0"拆成明确需求，避免跨大版本求解 - 定期清理冗余依赖：
composer why-not some/package查清某个包为何被拉进来，再决定是否剔除 - 项目超过 300+ 包时，考虑拆分单体仓库 —— 解析时间非线性增长，单靠参数调优收效甚微
composer config repo.packagist 配镜像却无效？检查这三点
90% 的“配了还是慢”其实是配置根本没生效，因为命令写错又不报错：
- 键名必须是
repo.packagist（单数，repos.packagist多一个 s 就失败） - type 必须显式传
composer：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌ - 验证方式：
composer config -g repo.packagist输出应为完整 JSON 对象或至少是 URL 字符串
解析慢的本质是 PHP 在单核上做高复杂度逻辑推演，不是网络或磁盘问题。想快，就得让问题本身变小——锁死版本、精简依赖、关掉 xdebug、别迷信“加速插件”。
