最直接解法是php -d memory_limit=-1 composer install，因99%的allowed memory size exhausted错误源于php cli默认128m限制卡死在依赖解析阶段；需确认cli实际加载的php.ini路径，且composer_memory_limit仅控制composer内部逻辑，不突破php底层内存上限。
php -d memory_limit=-1 是最直接的解法
报 Allowed memory size exhausted 时，99% 的情况是 PHP CLI 进程被默认 memory_limit=128M 卡死——Composer 还没开始装包，就在解析 composer.json 和依赖树时崩了。不用改配置文件，加一个参数就能绕过：
-
php -d "memory_limit=-1" composer install（Windows PowerShell 必须带双引号，否则-1被当命令参数丢弃） -
php -d memory_limit=2G composer install（Linux/macOS 可省略引号；单位必须大写G，2g无效） - 如果用的是
composer.phar，写法一样：php -d memory_limit=2G composer.phar update
为什么改 php.ini 常常无效
你改了 Apache 或 Nginx 对应的 php.ini，但 Composer 是在 CLI 环境下运行的，它读的是另一份配置。验证当前 CLI 实际加载的配置路径：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行
php --ini，看 “Loaded Configuration File” 行输出的路径 - 或运行
php -i | findstr "memory_limit"（PowerShell）或php -i | grep "memory_limit"（Linux/macOS） - 若输出为空，说明 CLI 没加载任何
php.ini，此时改哪份 ini 都没用
COMPOSER_MEMORY_LIMIT 环境变量更轻量但有局限
这个变量由 Composer 自身识别，优先级高于 php.ini，但低于 php -d。适合脚本批量调用：
- Windows CMD：
set COMPOSER_MEMORY_LIMIT=2G && composer install - Linux/macOS：
COMPOSER_MEMORY_LIMIT=2G composer install - 它只影响 Composer 内部逻辑（如依赖解析），不改变 PHP 底层内存分配上限——如果 Composer 调用的某些插件或脚本本身吃内存，仍可能触发
Allowed memory size exhausted
容易被忽略的三类踩坑点
即使加了 -d 或环境变量，仍失败，大概率卡在这几个地方：
-
vendor/和composer.lock存在但过期：Composer 会尝试“兼容还原”，比全新安装更耗内存。先rm -rf vendor composer.lock（Windows 用rd /s /q vendor+ 手动删composer.lock） - 启用了
xdebug：开发机常开着，但它会让 Composer 内存占用翻倍。临时关掉：php -d zend_extension= -d xdebug.mode=off -d memory_limit=2G composer install - Docker 容器内存不足：PHP 层设了
-1，但容器被--memory=512m限制死了，照样被 OOM killer 杀。得同步调高容器内存限额
-d 参数——很多 CI 环境（比如 GitHub Actions 默认 7GB 总内存）里，PHP 进程能分到的远少于你本地，2G 是目前最稳的硬性阈值。
