Composer下载慢的核心原因是默认直连海外packagist.org导致物理延迟、TLS握手和CDN未缓存三重卡顿；换阿里云镜像需正确配置URL、清缓存并避免Signature mismatch，同时须优化DNS解析、并发数及禁用CI/部署中冗余功能。
composer 下载慢，**核心原因不是你网差，而是默认直连海外 packagist.org，物理延迟 + TLS 握手 + CDN 未缓存三重卡顿**。换阿里云镜像源是见效最快、最稳的一步，但光改 URL 不够，配置错或没清缓存，照样卡在 0 B/s。
怎么安全切到阿里云镜像（别被 Signature mismatch 报错拦住）
Composer 2.x 对镜像签名验证更严格，随意配个旧镜像或拼错 URL 会直接报 Signature mismatch，不是网络问题，是校验失败。
- 用这条命令全局切换（推荐）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 切完立刻清缓存：
composer clear-cache（否则旧包仍从原源拉） - 验证是否生效：
composer config -g repo.packagist，输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 别用
composer config -g packagist.org false这类禁用操作——它会破坏私有包解析逻辑，尤其当你混用私有仓库时
为什么换了镜像还卡住？DNS 缓存和并发数才是隐形瓶颈
即使 URL 换对了，PHP 的 cURL 默认复用 DNS 缓存，可能导致域名仍解析到海外节点；而且 Composer 2.2+ 默认只开 3 个并发下载，远没榨干带宽。
- 强制绕过 DNS 缓存（Linux/macOS）：
export COMPOSER_NO_INTERACTION=1，再运行 install/update - 提高并行下载数（全局生效）：
composer config -g parallel-downloads 10（设 10 是多数机器上限，太高反而因 I/O 竞争报file_put_contents(/tmp/): failed to open stream） - 注意：
parallel-downloads只对composer install有效，composer update因要算依赖图，仍部分串行
CI/部署阶段必须关掉的三项默认行为
开发时需要 autoload、脚本、插件，但 CI 构建或上线部署时，它们全是冗余开销——尤其是含上百个包的项目，install 时间能省 30%+。
- 跳过 autoload 生成：
composer install --no-autoloader（后续用composer dump-autoload --optimize单独处理） - 跳过所有脚本（如 post-install-cmd）：
composer install --no-scripts（避免意外触发前端构建、缓存清理等重型操作） - 关插件自动加载：
composer install --no-plugins（尤其别留hirak/prestissimo，它在 Composer 2.x 已失效，还可能冲突）
生产环境必加的两个优化参数
autoload 生成慢？不是因为代码多，而是因为默认扫描全部 PSR-4 路径。权威类映射 + 优化器能砍掉 90% 的文件扫描开销。
- 强制只走压缩包（不 git clone）：
--prefer-dist（虽默认启用，显式写上更稳妥） - 启用类映射优化：
--optimize-autoloader（注意不是--optimize，后者已废弃） - 搭配权威模式（生产专用）：
--classmap-authoritative——告诉 autoloader “类不在 classmap 里就真没有”，彻底跳过文件扫描 - ⚠️ 别在开发环境用
--classmap-authoritative，新增类不会被识别，调试时会怀疑人生
