Composer 报 Allowed memory size exhausted 错误是因 PHP 内存限制过低，推荐用 php -d memory_limit=-1 composer install 临时提升内存，或设为 2G；需确认 CLI 使用的 php.ini 路径，Docker 环境还需同步增加容器内存限制。
composer install 或 update 报 Allowed memory size exhausted
这是 Composer 在解析依赖或下载包时 PHP 内存耗尽的典型错误，不是 Composer 本身的问题，而是 PHP 进程分配的内存上限太低。默认的 memory_limit（如 128M 或 256M）根本不够处理大型项目（比如 Laravel + 多个 dev 依赖 + lock 文件复杂时）。
临时提高 PHP 内存限制（推荐首选）
不改全局配置，只对当前命令生效，安全且立即起效。关键是绕过系统默认的 php.ini 限制：
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 用
-d memory_limit=-1彻底关闭限制（开发环境可用，生产慎用） - 或设一个足够大的值，如
-d memory_limit=2G（注意单位是G，不是GB） - 完整命令示例：
php -d memory_limit=-1 composer install
- 如果用的是
php composer.phar方式，同样加在php后：php -d memory_limit=2G composer.phar update
为什么不能只改 php.ini？
因为 Composer 可能被多个 PHP 环境调用（CLI、Apache、Docker 容器），而 CLI 的 php.ini 和 Web SAPI 的往往不同。你改了 Apache 的 php.ini，对终端执行的 composer 没影响。验证当前 CLI 使用的配置路径：
php -i | grep "Loaded Configuration File"。若输出为空或指向错误文件，说明 CLI 没加载你预期的配置。
其他有效但需谨慎的操作
这些方法能缓解，但各有副作用，别盲目套用：
- 删掉
vendor/和composer.lock后重装？可能触发更复杂的依赖解析，反而更吃内存 - 用
--no-dev跳过开发依赖？有效，但前提是确认当前不需要require-dev中的包（比如测试工具、代码生成器） - 升级 Composer 到最新版（
composer self-update）？新版有内存优化，但旧 PHP 版本（如 7.2）上效果有限 - Docker 环境下记得同时调大容器内存限制（
docker run --memory=4g），否则 PHP 层面再放开也没用
-d memory_limit=2G 是最稳的解法；但如果你在 CI 流水线里跑，建议固定为 1.5G 而非 -1，避免某次异常依赖爆炸拖垮整个构建节点。 
