换镜像源只是起点，真正卡住你的大概率不是网络，而是本地依赖求解或缓存损坏；Composer 默认不复用 lock 文件中已验证的兼容关系，强制重算整个依赖图，尤其约束宽松时耗时指数增长。
换镜像源只是起点，真正卡住你的大概率不是网络，而是本地依赖求解或缓存损坏。 直接执行 composer update 卡在 “Resolving dependencies” 或反复请求 packages.json，基本可以确定问题不在下载带宽，而在 Composer 本地解析逻辑或配置失当。
为什么 composer update 总是重算整个依赖图
Composer 默认不复用 composer.lock 中已验证的兼容关系，哪怕你只改了 composer.json 里一个包的版本号，它也会强制重新跑一遍 SAT 求解器。尤其当约束宽松时，耗时呈指数增长：
-
"monolog/monolog": "^2.0 || ^3.0"→ 求解器要尝试所有 2.x 和 3.x 的组合可能 -
"php": ">=7.4"→ 需检查几百个包对 PHP 7.4–8.3 的全部兼容元数据 -
"minimum-stability": "dev"→ 候选版本数暴增，稳定版约束能砍掉 80% 求解时间
实操建议：
- 精准更新：用
composer update vendor/package-name，而非全量update - 连带升级子依赖？只在明确需要时加
--with-dependencies - CI/CD 中禁用
update，坚持用composer install --no-interaction --no-scripts
镜像源配置必须配对生效，单设 repo.packagist 无效
阿里云、腾讯云镜像必须配合 repos.packagist.type 和 repos.packagist.url 同时设置，否则 Composer 仍会 fallback 到官方源做校验——这是最常被忽略的坑。
正确命令（以阿里云为例）：
composer config -g repos.packagist.type composer composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/
注意：repo.packagist（少一个 s）是旧写法，Composer 2+ 已不识别；repos.packagist（带 s）才是当前有效键名。PHP Composer 官方镜像 https://packagist.phpcomposer.com 已于 2026 年初停用，别再用。
composer install 卡在 “Installing dependencies” 怎么办
这个阶段卡住，和依赖解析无关，基本是 I/O 或网络层问题：
- 缓存目录在机械硬盘或加密卷上 → 解压
.zip包时 I/O 瓶颈 - DNS 查询失败后默认 5 秒超时 → 每个包下载前白等
- 杀毒软件实时扫描
vendor/目录 → 大量小文件触发扫描阻塞
实操建议：
- 把缓存挪到 SSD：
composer config -g cache-dir /path/to/ssd/composer-cache - 临时绕过缓存校验（尤其怀疑缓存损坏时）：
composer update --no-cache - 禁用杀软对
vendor/和~/.composer/cache的实时监控 - 确认是否真卡下载：
composer update -v看最后输出的 URL，停在provider-2023类路径就是元数据拉取慢，不是安装慢
容易被忽略的性能开关
很多加速选项不显眼，但效果立竿见影：
-
--prefer-dist：强制走压缩包而非 Git 克隆（默认已启用，但显式写上更稳妥） -
--no-dev：跳过require-dev中所有包，省掉 30–60% 时间 -
--optimize-autoloader：生成优化类映射（注意不是--optimize，该参数已废弃） -
--classmap-authoritative：告诉自动加载器“找不到就真没有”，跳过 PSR-4 扫描 —— 仅限生产构建或 CI 使用，开发环境误用会导致新增类不被识别
CI 构建推荐组合：composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative。别漏掉 --no-dev，它是提速最简单粗暴的一环。
