Composer运行慢主因是本地配置与缓存策略不当：默认全量拉取packagist元数据、宽泛版本约束触发依赖求解爆炸、缓存目录I/O瓶颈及DNS延迟。应换阿里云镜像并正确配置源类型，收紧PHP与包版本约束，迁移缓存至SSD，禁用杀软扫描。
Composer 运行慢，90% 情况下不是网络问题，而是本地配置和缓存策略没对上。
为什么 composer install 卡在 “Resolving dependencies”
这不是解析逻辑慢，是默认启用了 packagist.org 的完整元数据同步（含所有历史版本），而国内直连又常被限速或 DNS 污染。更关键的是：Composer 3 默认开启 https://packagist.org/packages.json 全量索引拉取，哪怕你只装 3 个包。
- 确认是否真卡在这步：
composer install -v看最后输出的 URL，如果停在packages.json或provider-2023...类似路径，就是元数据瓶颈 - 临时绕过：加
--no-cache反而更快——因为跳过了本地缓存校验（尤其当~/.composer/cache损坏时） - 长期解法：用国内镜像 + 关闭自动元数据更新：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意：PHP Composer 镜像已停，改用https://mirrors.aliyun.com/composer/） - 别信“换源就快”——阿里云镜像必须配合
composer config -g repos.packagist.type composer和repos.packagist.url一起设，否则 Composer 仍会 fallback 到官方源做校验
composer update 每次都重算整个依赖图
Composer 默认不复用 lock 文件里的已解析结果，update 会强制重新走一遍 SAT 求解器，尤其项目依赖多、约束松（比如 "monolog/monolog": "^2.0 || ^3.0"）时，耗时指数级增长。
- 优先用
composer install而非update：只要composer.lock存在且没改composer.json，它直接装 lock 里锁定的版本，毫秒级 - 真要更新某包？用
composer update vendor/package-name，避免全量重算；加--with-dependencies仅当明确需要连带升级子依赖 - 检查
composer.json里有没有宽泛约束："*"、"dev-master"、"^1.0 || ^2.0"都会让求解器陷入组合爆炸——收紧到具体小版本范围（如"^2.9.0"）能立竿见影 - PHP 版本声明太松也拖慢：
"php": ">=7.4"比"php": "^8.1"多查几百个包的兼容性元数据
本地缓存和 DNS 导致的隐性延迟
Composer 缓存本身不慢，但默认缓存目录（~/.composer/cache）若在机械硬盘或加密卷上，解压 .zip 包时 I/O 成瓶颈；DNS 查询失败后 5 秒超时也会让每个包下载前白等。
- 把缓存挪到 SSD：运行
composer config -g cache-dir /path/to/ssd/composer-cache - 关掉 DNS 轮询干扰：
composer config -g github-protocols https（避免 ssh 协议 fallback） - 验证 DNS 是否拖累：
time curl -I https://mirrors.aliyun.com/composer/，如果 >300ms，就该换 DNS（如114.114.114.114或223.5.5.5） - 禁用防病毒软件实时扫描
~/.composer/cache目录——某些国产杀软会对每个.zip解压前全文件扫描，单包多耗 2–5 秒
最麻烦的其实是混合场景：私有 GitLab 包 + 国内镜像 + 自建 Satis 仓库，这时候 composer update 会按顺序逐个源试探，一个源超时就等 5 秒再下一个。这种链路没法靠单点优化解决，得用 composer config -g repos.xxx 显式声明各源类型和优先级，否则 Composer 永远猜不准你到底想先找谁。
