composer install --profile 可直观显示各步骤累计耗时与内存占用，重点监控 Resolving dependencies（超2秒说明CPU暴力穷举）、Downloading/Extracting（镜像失效或I/O慢）及Executing script（钩子脚本性能差）三类瓶颈；配合 -vvv 才能精确定位卡点，如停在 Reading packages.json 表示缓存损坏，停在 SAT 求解则需缩小版本约束或使用 --with-all-dependencies。
composer install --profile 能直接看到哪一步最慢
执行 composer install --profile 后，每行输出都带累计耗时和内存占用，比如：
[45.6ms] Read configuration<br>[120.3ms] Downloading dependencies<br>[2.1s] Resolving dependencies<br>[800ms] Executing script post-install-cmd
重点盯住三类高耗时环节：
-
Resolving dependencies超过 2 秒 → 本地 CPU 在暴力穷举版本组合，不是网络问题 -
Downloading或Extracting archive占比高 → 镜像失效、TLS 握手卡顿、磁盘 I/O 慢 - 某条
Executing script耗时突兀 → 钩子脚本（如Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache）本身有性能缺陷
为什么 -vvv 和 --profile 要一起用
-vvv 输出详细请求路径，--profile 给出时间锚点，合起来才能定位「卡在哪儿」。单独用 --profile 只知道「解析慢」，但不知道是卡在读 packages.json 还是卡在 SAT 求解器回溯。
典型线索包括：
- 最后一条日志是
Reading /packages.json from cache→ 缓存损坏或镜像 URL 已 404 - 长时间停在
Resolving dependencies through SAT→ 版本约束太宽（如"*"、"dev-master"）或私有包元数据响应超时 - 反复出现
Downloading https://xxx/vendor/package.zip且无后续 → TLS 握手失败或代理拦截
镜像源配置是否生效，必须手动验证
很多人改完 composer config -g repo.packagist 就以为搞定了，其实 Composer 会优先读本地 composer.json 的 repositories，其次才 fallback 到全局配置。更关键的是：镜像 URL 可能已下线。
验证步骤：
- 运行
composer config -g repos.packagist看当前值 - 用
curl -I https://mirrors.aliyun.com/composer/packages.json测试 HTTP 状态码（200 才算活） - 若返回 404，立即切到稳定可用的地址，例如：
composer config -g repo.packagist composer https://php.cnpkg.org - 切完立刻
composer clear-cache，否则旧缓存仍会尝试访问失效地址
依赖解析卡死时，别硬等，换策略
当 Resolving dependencies 停住超过 30 秒，基本可以判定 SAT 求解器陷入回溯风暴。这时候删缓存、换镜像都没用，得干预求解逻辑：
- 加
--with-all-dependencies跳过部分兼容性校验，快速生成 lock 文件（适合 CI 场景） - 临时降级约束：把
"^1.0 || ^2.0"改成"^2.3"，缩小搜索空间 - 用
composer why-not vendor/package:version直接揪出冲突源头，比干等强得多 - 确认没开启
opcache.enable_cli=1—— PHP 8.2+ 下它会让 Composer 自身加载变慢
真正难的不是装不上，而是你不知道 Composer 正在 CPU 上算什么；一旦看清它在算 SAT 还是在等 TLS 握手，优化方向就非常明确。
