Composer依赖解析慢主因是composer.json配置不当：minimum-stability设为dev或留空、prefer-stable单独存在、fxp-asset和preferred-install干扰、repositories含失效源、autoload路径宽泛等，需针对性优化。
Composer 依赖解析慢，95% 不是网络问题，而是 composer.json 里几个关键配置写法直接拖垮 SAT 求解器——尤其在 monorepo 或含 path 仓库的项目中，错配一个字段就能让 “Resolving dependencies” 卡 3 分钟以上。
删掉 minimum-stability 字段或显式设为 "stable"
这个字段是解析爆炸的头号推手。设成 "dev" 或 "alpha" 会让 Composer 主动拉取所有不稳定分支，触发额外元数据探测和版本穷举；留空或设 "stable" 才能大幅收缩候选集。
- 不要写
"minimum-stability": "dev"—— 它会让每个包都尝试dev-master、dev-main等分支，校验成本翻倍 - 更别写
"prefer-stable": true单独存在：它只在minimum-stability非 stable 时起作用，纯属冗余 - 如果真需要某个包用 dev 版，用
"vendor/package": "dev-feature-branch as 1.2.0"显式锁定，不污染全局策略
禁用 fxp-asset 和关掉 preferred-install 的干扰逻辑
这两项在 monorepo 或含本地 path 仓库的项目中极易引发 I/O 风暴。Composer 会为每个 path 目录额外发起 HTTP 请求试探 Bower/NPM 包，或反复 clone Git 仓库来判断安装方式。
- 在根
composer.json的"config"段里加："fxp-asset": false—— 彻底跳过 asset 类型探测 - 同时加：
"preferred-install": "dist"—— 强制非path包走 ZIP 下载，避免 Git clone 占用解析线程（注意：该配置对path无效，但能减少干扰） - 别写进全局 config —— 这些是项目级行为控制，只在当前
composer.json中生效才有效
清理或重写 repositories 配置，避免私有源超时阻塞
卡在 “Loading composer repositories” 阶段？那基本不是镜像问题，而是 repositories 里写了已下线、DNS 不通或响应超时的私有源。Composer 会逐个尝试，每个超时默认等 10 秒，几十个源就卡死。
- 临时注释掉
repositories字段再跑composer install -vvv，如果明显变快，问题就出在这儿 - 删掉所有指向已停服地址的源（比如旧版
https://packagist.phpcomposer.com） - 若必须保留私有源，确保其
packages.json支持providers-url和provider-includes，否则 Composer 会 fallback 到全量元数据下载 - 验证真实生效源：运行
composer config --list和composer config --list --global对比，优先级是命令行 > 项目 > 全局
别让 autoload 成为解析负担
Composer 在解析阶段会扫描 autoload 声明的路径，尤其是 "files" 或宽泛的 "psr-4" 映射（如 "App\": "app/" 缺少末尾 /），可能触发大量文件系统遍历。
- 删掉测试/示例目录的 autoload 声明：
"tests/、"examples/、"docs/不该进生产 autoloader -
"psr-4"映射务必带末尾斜杠："App\": "app/"而不是"App\": "app"，否则 Composer 会多做一次 realpath 判断 - 开发环境慎用
"classmap-authoritative": true—— 它会让新增类不被识别，只应在 CI 或生产构建中启用
真正卡住的点往往藏在 repositories 和 config 的组合细节里，而不是镜像或缓存。改完一个字段，一定要用 composer install -vvv 观察日志里哪一行耗时最长——解析阶段的每一毫秒，都来自你写的那几行 JSON。
