直接换阿里云镜像源并执行composer clear-cache可解决90%的Composer安装慢问题；验证需运行composer config -g repo.packagist，输出必须为https://mirrors.aliyun.com/composer/，且composer install -vvv日志中出现对应路径才表明真正生效。
直接换阿里云镜像源，再清缓存，90% 的 Composer 安装慢问题当场解决；别信“调参数就能快”，没换源，其他操作基本白忙。
怎么确认当前用的是哪个镜像源
执行 composer config -g repo.packagist，输出必须是完整 URL，比如 https://mirrors.aliyun.com/composer/。如果显示 null、空值、或旧地址（如 packagist.phpcomposer.com），说明配置无效或已失效。
常见错误包括：repos.packagist（多写了个 s）拼错成 repo.packagist，导致配置被忽略；或者用了已停更的源（laravel-china.org 早在 2025 年底就下线了）。
验证是否真从国内拉取：跑一次 composer install -vvv，最后几行出现类似 Reading packages.json from cache at /home/user/.composer/cache/repo/https---mirrors-aliyun-com-composer/packages.json 才算真正生效。
换源后为什么还是慢
最常被忽略的一步：composer clear-cache 没执行。缓存里还存着旧的 packages.json 和包元数据，Composer 会优先读缓存，哪怕源已改，它仍试图从旧地址拉取校验信息，结果就是卡在 DNS 解析或 TLS 握手。
其他可能性：
- 公司内网拦截 HTTPS 重定向，需临时加
--secure-http=false（不推荐长期开） - 项目级
composer.json里写了"repositories"，覆盖了全局配置；执行composer config --list对比全局和项目配置 - 用了过时插件如
hirak/prestissimo，它在 Composer 2.2+ 中不仅无效，还会干扰parallel-downloads
哪些参数组合能真正提速
composer install 快不快，取决于三件事：能不能连上、要不要解压、要不要生成 autoload。生产或 CI 场景下，这组参数最稳：
-
--prefer-dist：强制下 ZIP 包，跳过 Git clone（尤其对只有dev-main分支的包，这是关键） -
--no-dev：跳过require-dev里的全部包（PHPUnit、PHPStan 等占体积和时间大头） -
--no-autoloader：不生成vendor/autoload.php（后续可单独composer dump-autoload --optimize） -
--no-scripts：阻止post-install-cmd执行（避免意外触发 npm 构建或数据库迁移）
注意：--no-autoloader 和 --no-scripts 不适用于本地开发——你刚 git pull 后想立刻跑起来，就得有 autoload 和 key 生成脚本。
为什么 vendor 目录存在，update 还巨慢
这不是网络问题，是 Composer 3.x 默认开启 classmap-authoritative 模式，每次 update 都强制重扫整个 vendor/ 目录生成 classmap，哪怕只更新一个包。I/O 和 PHP 解析开销远大于下载本身。
关掉它：composer config authorative false（注意拼写是 authorative，不是 authoritative）。或者删掉 composer.json 里的 "optimize-autoloader": true，改用手动触发：composer dump-autoload --optimize。
另一个隐藏坑：composer.json 里 "autoload" 配置太宽，比如把 tests/ 或 examples/ 目录也塞进 PSR-4，会导致 autoload_classmap.php 文件暴涨，dump 阶段更慢。
