composer install 内存耗尽根本原因是 php 默认 memory_limit 不足，应优先用 php -d memory_limit=-1 composer install 临时解决，长期高频使用才修改 php.ini，同时注意区分 cli 与 web 的配置差异。
Composer install 时提示 Allowed memory size exhausted
根本原因是 Composer 在解析依赖、下载包、生成 autoloader 时需要大量内存，而 PHP 默认的 memory_limit（通常是 128M 或 256M）不够用。这不是 Composer 本身有 bug，而是它对内存的“诚实”消耗暴露了 PHP 配置的保守性。
- 别急着改系统级
php.ini——临时项目里改composer install命令本身更安全、更快速 - 优先用
php -d memory_limit=-1 composer install：其中-1表示不限制，适合 CI/本地调试；但生产环境部署脚本里慎用 - 如果只想提得高一点（比如 2G），写成
php -d memory_limit=2G composer install，注意单位必须大写G，小写g会被忽略 - Windows 用户在 CMD 中可能遇到等号被截断的问题，建议改用 PowerShell 或直接双引号包裹：
php -d "memory_limit=-1" composer install
该不该动全局 php.ini？什么时候动？
动全局 php.ini 是治本办法，但只在你**长期高频使用 Composer 管理多个项目**时才值得——比如你是 PHP 包作者、内部组件平台维护者。否则，改一次影响所有 CLI 脚本，反而容易掩盖其他内存泄漏问题。
- 找到正在生效的
php.ini：运行php --ini，看 “Loaded Configuration File” 对应路径 - 编辑该文件，搜
memory_limit，改成memory_limit = 1G（不推荐设-1，CLI 下失控风险高） - 改完必须重启 PHP-FPM 或 Apache 才对 Web 请求生效；但 CLI 模式下只需重新开终端或运行
php --ini确认已加载 - 如果你用的是 XAMPP/MAMP/WAMP，它们自带的
php.ini很可能不是 CLI 实际读取的那个，务必以php --ini输出为准
还有哪些操作会触发内存爆掉？怎么绕开
除了 composer install，composer update 和 composer require 同样危险，尤其当锁文件过期、依赖树深度大、或用了 dev-master 这类不稳定版本时。
-
composer update比install更耗内存——它要重新计算整个依赖图谱。能用install就别用update - 加
--no-scripts --no-plugins参数可跳过 autoload 生成和插件执行，省下几百 MB 内存，适合紧急构建 - 删掉
vendor/和composer.lock后强行update是最烧内存的操作，除非真要重置依赖，否则避免 - 某些老旧 Composer 版本（如 1.x）在 PHP 8+ 下内存管理更差，升级到 Composer 2.5+ 能明显缓解，命令是
composer self-update
为什么有时调大内存也没用？
内存溢出不总等于“不够”，也可能是 Composer 卡死在某个低效环节：比如网络超时反复重试、递归解析冲突依赖、或插件无限循环。这时候光加内存只是拖延崩溃时间。
立即学习“PHP免费学习笔记（深入）”；
- 先加
-vvv看卡在哪一步：php -d memory_limit=2G composer install -vvv，观察最后几行输出是否停在某个包或 URL - 检查是否因国内网络导致
packagist.org响应慢，临时切镜像：composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意该镜像已停，应换为https://mirrors.aliyun.com/composer/） - 某些自定义插件（尤其是旧版
hirak/prestissimo）与新版 Composer 不兼容，会引发隐式内存泄漏，禁用测试：composer install --no-plugins - 极少数情况是 PHP 编译时没启用
--enable-opcache，导致 Composer 解析大量 JSON/YAML 时性能骤降，间接推高内存占用
php.ini 可能完全不同，连 php --ini 和 phpinfo() 输出都得分开查。 
