ThinkPHP 6.0 解决 Composer 安装依赖时的内存限制【OOM】
在命令前加`php-dmemory_limit=-1`可绕过PHPCLI默认128MB限制,解决Composer安装ThinkPHP6.0时的内存溢出。注意CLI与Web的php.ini配置不同,还可配合`--no-dev`参数降低依赖解析内存峰值。
在命令前直接加上 php -d "memory_limit=-1",就能绕开 PHP CLI 默认的 128MB 内存墙。这是安装 ThinkPHP 6.0 时最常见,也确实最管用的解法。那个“Allowed memory size of 134217728 bytes exhausted”的报错,本质不是框架本身的问题,而是 Composer 在解析依赖树——尤其是处理大量 dev 包的时候——被内存限制当场拦住了。
遇到这个问题,先别急着改配置。得弄清楚命令行环境到底用的是哪个 php.ini 文件:
- 在 PowerShell 里跑 php --ini,看准 Loaded Configuration File 这一行指向的路径。
- 再执行一句 php -r "echo ini_get('memory_limit');",确认实际值。大部分情况下看到的是 128M 或 256M。
- 这里要特别提一下:Web 环境(比如 Apache、Nginx)的 php.ini 和 CLI 完全是两套配置,改错了地方什么用都没有。
如果不想动全局配置,尤其怕影响机器上其他脚本的运行,那每次安装时显式指定参数是最稳妥的路子:
- 执行 php -d "memory_limit=-1" composer create-project topthink/think tp6。注意在 PowerShell 中双引号不能省略,不然 -1 会被当成参数直接丢掉。
- 要是觉得无限制有点不踏实,给个具体值也行:php -d "memory_limit=2G" composer create-project topthink/think tp6。还有,单位一定要用大写的 G。
- 如果你执行 which composer 返回的是 /usr/bin/composer,说明这是一个系统级的 wrapper,这种情况下 -d 参数会被忽略掉。解决办法很直接:用 php -d "memory_limit=-1" /usr/bin/composer ... 来调用。
话说回来,光靠提升内存额度只是兜了个底。真正想省资源,还得从流程上做减法。

首先,把遗留文件清理干净:手动删除 vendor/ 目录和 composer.lock 文件。这一步能避免 Composer 为了兼容旧的锁文件,陷入更复杂的回溯逻辑,白白消耗内存。
其次,如果只是为了跑个示例,--no-dev 参数能直接跳过 PHPUnit、psr/log 这类开发依赖,内存峰值能降下来大约 50%。
最后,加上 --no-plugins --optimize-autoloader(可以简写为 -o),减少钩子触发和运行时扫描的开销,效果也很明显。
再来看看 CI/CD 或者 Docker 环境。自动化流程里没法靠人工敲命令,得把策略写死:
- 在 GitHub Actions 或 GitLab CI 里,直接在 run: 步骤中写 php -d memory_limit=-1 composer install --no-dev -o。
- Dockerfile 里则用 RUN php -d memory_limit=2G composer install --no-dev。Alpine 镜像因为 ZEND_MM_ALLOC 的关系,内存管理会更激进,所以给个具体数值更稳妥。
- 有一点值得注意:环境变量 COMPOSER_MEMORY_LIMIT 只能控制 Composer 自身的逻辑,绕不开 PHP 底层的限制,所以它没法替代 php -d 的作用。


































