composer内存不足崩溃的根源是php cli默认内存限制过低，解决方法包括临时设置php -d memory_limit=-1、永久修改php.ini、ci中使用composer_memory_limit=-1环境变量，以及优化autoload配置。
composer install 内存不足直接崩溃
Composer 默认用 1.5GB 内存上限，大项目（尤其含 symfony/symfony 或大量插件）跑 composer install 时经常卡住或报 PHP Fatal error: Allowed memory size of XXX bytes exhausted。这不是配置错，是 PHP CLI 默认限制太低，而 Composer 在解析依赖图时会吃掉大量内存。
- 临时加内存：运行前加
php -d memory_limit=-1 /usr/bin/composer install（-1表示无限制，最直接有效） - 永久改 PHP CLI 配置：编辑
php.ini文件（不是 Apache 或 FPM 的那个），找到memory_limit行，改成memory_limit = 2G或更高 - 别碰
composer.json里的config.memory-limit—— 这个字段早被废弃，新版 Composer 完全忽略它
composer update 卡在 “Resolving dependencies” 不动
这阶段最耗内存，尤其当你本地有旧锁文件、又改过 require 版本范围时，Solver 会反复回溯尝试组合，CPU 占满但内存也很快打满。不是网络问题，也不是包源慢。
- 先删掉
vendor/和composer.lock（仅限开发环境），再跑composer install—— 比update快得多，也更省内存 - 如果真要
update，加--with-dependencies或缩小范围：composer update monolog/monolog，避免全量重算 - 禁用插件可减负：
composer update --no-plugins，某些插件（如hirak/prestissimo）在新版中反而引发内存异常
CI 环境里 composer install 总失败
GitHub Actions、GitLab CI 默认的 PHP runner 内存常只有 1~2GB，且无法改全局 php.ini。这时候靠本地调参没用，得换策略。
- 用
COMPOSER_MEMORY_LIMIT=-1环境变量（比改 php.ini 更可靠）：env COMPOSER_MEMORY_LIMIT=-1 composer install - 跳过 autoload 生成节省开销：
composer install --no-autoloader --no-scripts，等安装完再单独跑composer dump-autoload - 用
--prefer-dist强制走压缩包而非 Git 克隆，减少解压和临时文件压力
为什么加大内存后还是慢？可能卡在 autoload 生成
composer install 最后一步 Generating autoload files 本身不占内存，但若项目含大量 PSR-0/PSR-4 映射、或用了 classmap 扫描整个 src/，就会遍历成千上万个文件 —— 这步 CPU 密集，且无法并行，看着像卡死。
- 检查
composer.json的autoload段，删掉宽泛的"": ["src/"]这类 classmap 配置 - 把测试代码、文档、migration 文件夹从 autoload 扫描路径里排除（可用
exclude-from-classmap） - 生产环境用
composer install --optimize-autoloader --no-dev，它会生成静态映射表，后续加载快很多
install vs update）、不同环境（CLI vs CI）、甚至不同版本（2.2+ 对 Solver 做了优化，但某些插件反而拖后腿）—— 表现一样，根因可能完全不同。 
