本质是SAT求解器递归展开依赖图谱，需将版本约束转为逻辑命题并暴力回溯求解，反复加载解析数百个composer.json文件，每层递归保留上下文快照致内存指数增长。
Composer依赖解析卡在Solver.php第223行，本质是SAT求解器递归展开图谱
不是包太多，而是 Composer 用 SAT（布尔可满足性）算法做版本兼容性推演——它要把所有composer.json里的约束（如"^3.0"、"dev-master"、"@dev"）转换成逻辑命题，再暴力回溯求解。这个过程会反复加载、解析、比对数百个包的元数据文件，每层递归都保留上下文快照，内存呈指数级增长。
常见诱因包括：
-
"require-dev"里塞了phpunit、phpstan、friendsofphp/php-cs-fixer等重型工具，它们自身又带几十个间接依赖 - 用了不带锁的版本约束，比如
"symfony/console": "^6.0"而非"symfony/console": "6.4.10"，导致每次都要重新查可用版本 - 引入已废弃包（如
symfony/class-loader），其composer.json格式不规范，触发额外校验分支 -
"prefer-source": true被激活，强制走git clone而非.zip下载，每个包多启一个子进程吃内存
为什么composer install比composer update省得多
composer install只按composer.lock逐条还原，跳过整个 SAT 求解阶段；而composer update必须从头构建依赖图、下载全部包的composer.json、执行语义冲突检测、尝试数百种组合路径——这是 CPU + 内存双密集型任务。
实测对比（中型 Laravel 项目）：
-
composer install：峰值内存 ≈ 300MB（有 lock 文件） -
composer update：峰值内存 ≈ 1.8GB（无 lock 或 lock 过期） -
composer update --dry-run：仍需 1.2GB —— 因为它照样跑完整求解流程，只是不写盘
COMPOSER_MEMORY_LIMIT=-1为什么经常失效
这个环境变量只影响 Composer 自身逻辑层的内存分配策略，**不修改 PHP 进程底层限制**。一旦 PHP 启动时已锁定memory_limit=128M，后续 Composer 即使想申请 2GB，也会在底层被截断并报Allowed memory size exhausted。
真正起效的只有：php -d memory_limit=-1 composer install。注意细节：
- 参数必须前置，
composer install -d memory_limit=-1是错的——-d被当成了composer子命令 - PowerShell 必须加引号：
php -d "memory_limit=-1" composer install，否则-1被截成空 - Docker 环境光设 PHP 无用，还得配
--memory=4g，否则内核 OOM killer 会直接杀进程
生产部署最稳的组合命令
别只盯着内存，要同时砍掉最耗资源的三块：求解、加载、扫描。
标准命令是：
php -d memory_limit=2G composer install --no-dev --optimize-autoloader -o
各参数作用：
-
--no-dev：跳过require-dev全量解析，降内存 40%~60% -
--optimize-autoloader（或-o）：生成扁平classmap，绕过 PSR-4 动态扫描，dump-autoload阶段内存直降 70% -
php -d memory_limit=2G：给 PHP 进程划够底线，单位必须是G（2g或2048M会被忽略）
CI/CD 中务必确保缓存 key 包含composer.lock的 hash，否则缓存未命中，install退化为update，前面所有优化都白搭。
