Composer 在大项目下变慢主因是本地依赖求解器穷举版本组合、autoload 配置污染、缓存策略错配；需收紧版本约束、清理宽泛 autoload、清缓存并禁用 xdebug 与 opcache.cli。
Composer 在大项目下变慢，95% 不是网络或服务器性能问题，而是本地依赖求解器在穷举版本组合、autoload 配置污染、缓存策略错配这三件事上同时踩了坑。
为什么 composer install 卡在 “Resolving dependencies”
这不是在下载，是 Composer 用 SAT 求解器在本地暴力尝试所有可能的包版本组合。项目依赖越多、约束越宽（比如 "monolog/monolog": "^1.0 || ^2.0" 或 "php": ">=7.4"），耗时就从秒级跳到分钟级。
- 删掉
"minimum-stability": "dev"—— 它会让求解器把所有 dev 分支都纳入候选集 - 检查
composer.json里有没有"*"、"dev-master"、"^2.0 || ^3.0"这类宽泛约束，收紧到具体小版本（如"^2.9.0"） - 确认没启用 xdebug：它会让解析慢 5–10 倍；临时禁用命令是
php -d zend_extension= -d xdebug.mode=off /usr/bin/composer install - 避免
--with-all-dependencies和--ignore-platform-reqs—— 它们强制绕过缓存，触发全量重算
为什么 composer install 卡在 “Installing dependencies”
这个阶段卡住，基本是下载或解压问题，和依赖解析无关。常见于低内存容器、WSL2 挂载卷、或并发数设太高。
- 限制并发下载：
composer config -g parallel-downloads 4（默认 20，2GB 内存机器容易 OOM） - 换镜像源后必须清缓存：
composer clear-cache，否则旧缓存仍走 packagist.org - 禁用 CLI 模式下的
opcache.enable_cli=1（PHP 8.2+ 中它反而拖慢 Composer 自身加载） - 别在 Docker volume 挂载的
vendor/上运行 install —— 改为容器内本地执行，再同步
autoload 配置怎么写才不拖慢构建和运行
autoload 写得太“宽”，会导致 vendor/autoload.php 加载变慢、autoload_classmap.php 体积暴涨、甚至 CI 构建失败。
- 删掉
"tests/": ["tests/"]、"examples/": ["examples/"]这类配置 —— 它们会把 Mock 类、示例代码全扫进 classmap - 小工具函数改用
"files"显式加载："files": ["src/helpers.php"]，比 PSR-4 动态匹配快一个数量级 -
"classmap"只列真正需要预扫描的目录（如契约接口、异常类），别写["src/"] - 检查
vendor/composer/autoload_classmap.php文件大小 —— 超过 1MB 就说明被污染了
CI/CD 中漏掉这四个参数，composer install 就白优化一半
生产环境部署必须加，漏掉任意一个都可能让安装多花 30%–60% 时间。
-
--no-dev：跳过require-dev下所有包（如 phpunit、phpstan），也防止测试类污染 autoload -
--prefer-dist：强制走 ZIP 包而非 Git 克隆，避开 SSH 认证、分支切换等开销 -
--optimize-autoloader：生成静态类映射（注意：不是--optimize，后者已废弃） -
--classmap-authoritative：告诉 autoloader “查不到就真没有”，跳过 PSR-4 fallback；但前提是项目没用"files"加载全局函数，且命名空间路径严格匹配（比如"App\": "app/"必须带末尾反斜杠）
最常被忽略的是：换镜像源后不 clear-cache，以及在 PHP 8.2+ 环境下仍开着 opcache.enable_cli=1 —— 这两个操作单独看影响不大，合起来能让一次 install 多耗两倍时间。
