composer install 卡在 resolving dependencies 是因新版默认 sat 求解器面对复杂版本约束时穷举组合导致指数级回溯；应禁用动态源、启用 lock 配置、使用 --prefer-dist 和 --optimize-autoloader 优化。
composer install 为什么慢？卡在 Resolving dependencies 是解析器在爆算
新版 Composer（7.4+）默认启用 SAT 求解器，面对数百个包、多版本约束（如 ^1.0 || ^2.0）、@dev 或 dev-master 标签时，依赖图回溯会指数级膨胀。这不是网络慢，是算法在穷举合法组合。
- 临时缓解：加
--no-suggest --no-progress减少输出干扰，但不改解析耗时 - 真正有效：在
composer.json顶层加"config": {"lock": true}，强制跳过因本地platform配置差异触发的重解析 - 更关键的是禁用动态源：运行
composer install --prefer-dist --optimize-autoloader，跳过源码安装和冗余 autoload 生成
怎么让 vendor 包体积变小？不是删文件，是关压缩开关
Composer 默认对 dist 包使用 zip 压缩，但部分镜像或私仓返回的 tar.gz 包未启用 gzip 最高压缩比；更大的问题是 autoload classmap 文件本身——dump 出来的 vendor/composer/autoload_classmap.php 可能超 10MB，纯文本无压缩。
- 生成权威类映射时顺带压缩：用
composer dump-autoload --classmap-authoritative --apcu，APCu 缓存类位置后，PHP 不再读取整个 classmap 文件 - 排除测试代码污染：在
composer.json中配置"autoload-dev": {"exclude-from-classmap": ["tests/", "Tests/"]} - 生产打包前清缓存：执行
composer clear-cache，避免旧版包残留影响新包压缩策略
composer update 改了一堆版本号？你没锁死，不是它乱来
composer.lock 才是真实安装依据。删掉它再跑 composer install，等于让 Composer 重跑一遍 SAT 求解——只要 composer.json 里有 ^2.0 这种松散约束，就会拉最新兼容版。
- 想“整齐”就别等事后整理：把调试类包（如
phpunit/phpunit）移到require-dev，避免污染主依赖树 - 核心包显式锁定小版本：
"symfony/http-kernel": "6.4.10"（不带符号），适合灰度发布或紧急修复 - CI 中只需校验一致性？用
composer update --lock，只更新 lock 文件时间戳和哈希，不动任何版本号
内存溢出（Allowed memory size exhausted）？别急着调 PHP ini
Composer 内存爆掉，往往不是 PHP 内存设小了，而是依赖图构建过程把所有候选版本元数据全加载进内存——尤其当你项目里有 monolog/monolog、symfony/* 这类高版本密度包时。
- 最直接生效：用
php -d memory_limit=-1 composer install绕过所有限制（Linux/macOS） - ThinkPHP/Laravel 等框架项目，务必加
--no-dev --no-plugins --no-scripts，dev 依赖和插件脚本是内存消耗主因 - 永远不要在根目录跑
composer update：改用composer update vendor/package-name --with-dependencies精准更新子树
压缩和打包的边界其实很窄：Composer 不做“合并依赖”，也不提供包内二进制压缩 API；所谓优化，本质是控制解析范围、裁剪 autoload 范围、关闭非必要加载路径。最容易被忽略的是——lock 文件一旦提交，所有人就绑定了同一套解析结果；但如果你的 composer.json 还留着 ^ 和 ~，下次有人手抖删了 lock，整棵树就重新长歪了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
