应临时用 php -d memory_limit=2G composer install 提高内存限制，因错误源于 PHP 的 memory_limit 配置不足；长期需修改 php.ini 中 memory_limit 为 2G，并确认 CLI 使用的配置文件路径。
composer
install 报
这是 Composer 在加载依赖图或执行脚本时，PHP 内存耗尽的典型错误。不是 Composer 本身限制了 1024M，而是当前 PHP 配置的
恰好设为
，而实际过程需要更多——比如项目含大量插件、递归 autoload、或用了
（旧版）等扩展。
临时提高内存：用
覆盖 PHP 配置
最直接有效的方式是启动时临时调大
，不改 php.ini，不影响其他命令：
Linux/macOS：
Windows cmd：
如果用
命令是 shell alias 或 bat 文件，确保它调用的是
而非
直接封装体（否则
可能被忽略）
是安全起点；若仍失败，可试
或
（不限制），但仅限调试，生产环境别用
为什么不用
？
这个环境变量确实存在，但它的作用被严重高估了：
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
它只影响 Composer 自身的内存预留逻辑（比如是否提前 abort），
不修改 PHP 的
设成
后仍报错？说明 PHP 层已触顶，该变量没用
只有当你确认 PHP 内存充足，但 Composer 主动因“预估超限”中止时，才需调整它（极少见）
验证方式：
—— 这个值才是关键
长期方案：别靠每次加参数，改对地方
频繁遇到这问题，说明开发环境配置不合理。优先检查并修正以下位置：
查当前生效的
：
，然后编辑对应文件，把
改成
（注意单位大小写，
要大写）
如果你用 XAMPP/MAMP/WAMP，它们常自带独立
，CLI 和 Web 版可能不同，
看清路径
Docker 用户：在
中设置，或 Dockerfile 里加
CI/CD（如 GitHub Actions）：在步骤中显式用
，别依赖全局配置
真正容易被忽略的是：有些 IDE（如 PHPStorm）内置终端会复用 GUI 环境的 PHP 配置，而 GUI 应用常被系统限制内存——这时候即使 CLI 下正常，IDE 终端里仍报错。换系统终端执行，或查 IDE 的 PHP 解释器路径是否指向了受限版本。
Allowed memory size of 1024M exhaustedmemory_limit1024Mhirak/prestissimo-dmemory_limitphp -d memory_limit=2G /usr/bin/composer installphp -d memory_limit=2G composer installcomposerphpphp.exe-d2G3G-1-1COMPOSER_MEMORY_LIMITmemory_limit2Gphp -r "echo ini_get('memory_limit');"php.iniphp --inimemory_limit = 1024M2GGphp.iniphp -i | grep 'Loaded Configuration File'php.iniRUN echo "memory_limit = 2G" >> /usr/local/etc/php/conf.d/memory.iniphp -d memory_limit=2G composer install